June 2016 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Jun '16

02 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"d753ea2a546733cb29c2970232ac870023aee22f/ghc" d753ea2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d753ea2a546733cb29c2970232ac870023aee22f" Use UniqDSet for finding free names in the Linker This is not necessary for determinism, but it's a choice between making this deterministic and using `nonDetEltsUFM` and a comment explaining that it doesn't matter. Test Plan: ./validate Reviewers: austin, hvr, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2295 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Jun '16

02 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"be4708513fc04dd9c9c99fe652503866ecd85c15/ghc" be470851/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be4708513fc04dd9c9c99fe652503866ecd85c15" Kill nameSetElems in rnCmdTop This change isn't necessary for determinism. appAName, choiceAName, loopAName all have pre-allocated Uniques and their relative order can't change. I opted to use nameSetElemsStable here because: * the cost is negligible * it's less fragile than just documenting Test Plan: ./validate Reviewers: simonpj, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2292 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics
by GHC 02 Jun '16

02 Jun '16

#9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9043 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket serves to track the task of improving the meta-data representation in GHC.Generics as described in the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#A… I'm working on this in branch `wip/GenericsMetaData`, and I intend to have it in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64#
by GHC 02 Jun '16

02 Jun '16

#4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielDiaz): * cc: DanielDiaz (added) Comment: Yes, please! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4092#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Jun '16

02 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"d348acd527548fc71a59e239a963e982c69af1f8/ghc" d348acd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d348acd527548fc71a59e239a963e982c69af1f8" Serialize vParallelTyCons in a stable order nameSetElems can introduce nondeterminism and while I haven't observed this being a problem in practice (possibly because this is dead code) there's no downside to doing this. Test Plan: ./validate Reviewers: bgamari, austin, simonpj, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2296 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 02 Jun '16

02 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"cb9f635eae76c61f189b9b55af4ed7628ccafda1/ghc" cb9f635e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb9f635eae76c61f189b9b55af4ed7628ccafda1" Localize orphan-related nondeterminism chooseOrphanAnchor now takes a NameSet, relieving the callers from the burden of converting it to a list Test Plan: ./validate Reviewers: bgamari, ezyang, austin, simonmar, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2294 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12142: -Wredundant-constraints warns about constraints introduced via type synonyms.
by GHC 02 Jun '16

02 Jun '16

#12142: -Wredundant-constraints warns about constraints introduced via type synonyms. -------------------------------------+------------------------------------- Reporter: scshunt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I ran into this when using lens, here's a simplied example: {{{#!hs l :: Getter [a] Int l = to length }}} In this case, Getter introduces constraints (Functor f, Contravariant f), but the Functor constraint is not used. This leads to a warning from -Wredundant-constraints: {{{ <interactive>:1:6: warning: [-Wredundant-constraints] • Redundant constraint: Functor f • In the type signature for: l :: (Contravariant f, Functor f) => (Int -> f Int) -> [a] -> f [a] }}} This shouldn't warn, because the constraints were introduced by type synonym and so may well be opaque to the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 02 Jun '16

02 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akst): * cc: akst (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Implement TDNR (was: Implement Dot as Postfix Function Apply)
by GHC 02 Jun '16

02 Jun '16

#4479: Implement TDNR -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -2,2 +2,1 @@ - [https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordField… - Dot as Postfix Function Apply]. + [https://wiki.haskell.org/TypeDirectedNameResolution TDNR]. New description: A request to implement [https://wiki.haskell.org/TypeDirectedNameResolution TDNR]. -- Comment (by gidyn): Yes, Records/DeclaredOverloadedRecordFields/DotPostfix is orthogonal to type directed name resolution, although spj's original TDNR proposal included both. This ticked was originally about TDNR, then wondered into DotPostfix as an add-on to ORF. As the dot notation has attracted a fair amount of opposition, and ORF only gives TDNR for records, I've brought up a proposal for TDNR over any function but without syntax changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4479: Implement Dot as Postfix Function Apply
by GHC 02 Jun '16

02 Jun '16

#4479: Implement Dot as Postfix Function Apply -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): @gidyn, I don't see what that proposal has to do with dot as postfix function apply (?) This dot as ... idea is not the same as in TDNR -- despite spj's first comment 6 years ago. Dot as ... is purely syntactic sugar for function apply, with type-directed resolution as per standard class/instance semantics. There's already too many proposals for records (and related enablers), without mixing them up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0