From ghc-devs at haskell.org Sat Oct 1 04:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 04:24:18 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.584f3eeb5cda8e77adbe032b7cef9c92@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9e862765ffe161da8a4fd9cd67b0a600874feaa9/ghc" 9e862765/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e862765ffe161da8a4fd9cd67b0a600874feaa9" Implement deriving strategies Allows users to explicitly request which approach to `deriving` to use via keywords, e.g., ``` newtype Foo = Foo Bar deriving Eq deriving stock Ord deriving newtype Show ``` Fixes #10598. Updates haddock submodule. Test Plan: ./validate Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin, erikd, simonmar Reviewed By: alanz, bgamari, simonpj Subscribers: thomie, mpickering, oerjan Differential Revision: https://phabricator.haskell.org/D2280 GHC Trac Issues: #10598 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 04:36:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 04:36:35 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.b30c70657c1737ccd7649084a8cb33fe@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_run/T10598_bug Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_run/T10598_bug * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 04:44:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 04:44:45 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.11dec540acc1d3e7d284e6cd0e2bccd3@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 RyanGlScott): * owner: => RyanGlScott Comment: After #10598, GHC has been refactored to propagate information about which deriving mechanism was chosen further into the compiler, so fixing this issue properly (i.e., erroring on stock or newtype deriving, but not on anyclass deriving) is much easier now. I'll take this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 05:11:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 05:11:05 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.1f3ee3350ee5fd9947987647afc739a6@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 kjslag): I think the code below might be affected by the same issue. {{{#!hs data A data B class F a where f :: a -> B instance F A where f = undefined g :: (A, B) g = (x, f x) where -- x :: A x = undefined }}} With GHC 8.0.1, I get: {{{ test.hs:11:9: error: • Ambiguous type variable ‘a0’ arising from a use of ‘f’ prevents the constraint ‘(F a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instance exist: instance F A -- Defined at test.hs:7:10 • In the expression: f x In the expression: (x, f x) In an equation for ‘g’: g = (x, f x) where x = undefined }}} The code compiles fine if I uncomment the second to last line. However, it seems like GHC should be able to tell that `x` has type `A`. I haven't tested other versions of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 06:53:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 06:53:00 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.f7cc17f12780e0c8006fd65e217a18e7@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): Given that it didn't happen during this plane ride, I'm on it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 08:36:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 08:36:28 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.acf7f335e7b4e053f2e811d7ddad7d2b@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): > In the short term, would anything go wrong if we allowed an IPID anywhere in the stack to satisfy a dependency provided it was unique? And if a dependency is not unique, we resolve in the current way, using the DB ordering. OK, while I was implementing this, I discovered a fairly nasty edge case. Consider: * db1: p (depends on q) * db2: q (depends on r from db3) * db3: r * db4: r (shadows r from db3) A "proper" order to specify these databases is db3 db2 db1 db4, which would have the net effect of only bringing r into scope (since everything else gets killed with db3's r gets shadowed.) Alternately, db4 db3 db2 db1 would see just db4 be killed. What do you expect to happen if the databases are specified: `db1 db3 db4 db2`? Under the "non-duplicated package can be specified anywhere" rule, `db1` is OK because it refers to `q`, which indeed is only mentioned once. OK, now the nastiness begins. Remember that we still need to process shadowing in order. So we accept `db1`, process `db3` (fine), and then process `db4`, at which point there is a problem. The r from db4 needs to shadow the db3 r, and invalidate anything that depends on it. This *somehow* has to include db1 and db4, but we haven't even "gotten" to db4 to process it yet. A giant mess! I don't really care about trying hard to salvage the situation, if a user comes into it. But what I do care about is giving an easily interpretable explanation about whatever behavior we do. But it doesn't seem like there is reasonable "non-magical" semantics I can give for this case. Here's an alternative: what if we allow you to order your `-package-db` flags however you want, but ONLY if there is NO shadowing anywhere in the stack? In that case, matters are simple. I am only a little less enthusiastic about this because you only need to have one case of irrelevant shadowing and boom your command line stops working. Guidance requested! What do you care about? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 13:56:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 13:56:04 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies In-Reply-To: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> References: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> Message-ID: <066.d94a76fa67fb06d73d8c0c209c1c21ab@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: | FunctionalDependencies 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 goldfire): Functional dependencies, as implemented in GHC, are used purely for disambiguating otherwise-ambiguous variables. That's it! In particular, a "given" fundep goes unused. There is much room for improvement here, but it would take a dedicated soul, and quite likely an update to the core language, with proofs and possibly a paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 13:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 13:58:24 -0000 Subject: [GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas In-Reply-To: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> References: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> Message-ID: <061.b7d1ab0437d4b95ac6772ae0db868c14@haskell.org> #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): Ooh. :) +1 But shouldn't this go through ghc-proposals? It's a user-facing feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 15:22:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 15:22:19 -0000 Subject: [GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas In-Reply-To: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> References: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> Message-ID: <061.d5104098502f2e0db39d9189663f1916@haskell.org> #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): > But shouldn't this go through ghc-proposals? It's a user-facing feature. Of course, but I just needed someplace to jot down the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 16:20:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 16:20:56 -0000 Subject: [GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas In-Reply-To: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> References: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> Message-ID: <061.c4402281a99988ddbf5422a94c0d4957@haskell.org> #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 bgamari): See proposal [https://github.com/ghc-proposals/ghc-proposals/pull/15|PR #15]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 19:47:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 19:47:50 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.50534ea97a7c98f91c489200fb8dfde7@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2557 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 20:57:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 20:57:38 -0000 Subject: [GHC] #12650: Too many warnigns about consistentCafInfo Message-ID: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> #12650: Too many warnigns about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building GHC with debug on yiedls in many (97!) warnings of the form {{{ WARNING: file compiler/stgSyn/CoreToStg.hs, line 252 $fFunctorIOEnv True False }}} The code in question is {{{ -- Assertion helper: this checks that the CafInfo on the Id matches -- what CoreToStg has figured out about the binding's SRT. The -- CafInfo will be exact in all cases except when CorePrep has -- floated out a binding, in which case it will be approximate. consistentCafInfo :: Id -> GenStgBinding Var Id -> Bool consistentCafInfo id bind = WARN( not (exact || is_sat_thing) , ppr id <+> ppr id_marked_caffy <+> ppr binding_is_caffy ) safe where safe = id_marked_caffy || not binding_is_caffy exact = id_marked_caffy == binding_is_caffy id_marked_caffy = mayHaveCafRefs (idCafInfo id) binding_is_caffy = topStgBindHasCafRefs bind is_sat_thing = occNameFS (nameOccName (idName id)) == fsLit "sat" }}} It would be nice to have less warnings, to make them more useful. I don’t know if the warning is not right, or if there is something that can be fixed about the thing it is warning about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:07:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:07:19 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.45f78beb345ad43ecbde36922c32f8ba@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2558 Comment: At least, I thought deriving strategies would come into play, but it turns out a different check already present in GHC gives a pretty reasonable error message for this scenario already. So now the code above gives the error message: {{{ • Can't make a derived instance of ‘SC (Serializable (MyList a))’: ‘SC’ is not a stock derivable class (Eq, Show, etc.) Try enabling DeriveAnyClass • In the stand-alone deriving instance for ‘(Typeable a, SC (Serializable a)) => SC (Serializable (MyList a))’ }}} `DeriveAnyClass` technically can't be used derive instances of kind `a -> Constraint` right now, but they will be able to once #12144 is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.f8d0c6704e97a23526941f804fc8338f@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11792 | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b61b7c2462b919de7eb4c373e2e2145c6d78d04c/ghc" b61b7c24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b61b7c2462b919de7eb4c373e2e2145c6d78d04c" CodeGen X86: fix unsafe foreign calls wrt inlining Foreign calls (unsafe and safe) interact badly with inlining and register passing ABIs (see #11792 and #12614): the inlined code to compute a parameter of the call may overwrite a register already set to pass a preceding parameter. With this patch, we compute all parameters which are not simple expressions before assigning them to fixed registers required by the ABI. Test Plan: - Add test (test both reg and stack parameters) - Validate Reviewers: osa1, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2263 GHC Trac Issues: #11792, #12614 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #11792: Optimised unsafe FFI call can get wrong argument In-Reply-To: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> References: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> Message-ID: <060.19e427b0849285b03e962a0539198101@haskell.org> #11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b61b7c2462b919de7eb4c373e2e2145c6d78d04c/ghc" b61b7c24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b61b7c2462b919de7eb4c373e2e2145c6d78d04c" CodeGen X86: fix unsafe foreign calls wrt inlining Foreign calls (unsafe and safe) interact badly with inlining and register passing ABIs (see #11792 and #12614): the inlined code to compute a parameter of the call may overwrite a register already set to pass a preceding parameter. With this patch, we compute all parameters which are not simple expressions before assigning them to fixed registers required by the ABI. Test Plan: - Add test (test both reg and stack parameters) - Validate Reviewers: osa1, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2263 GHC Trac Issues: #11792, #12614 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.8625501f059af920e8e70aaee85b53dc@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3c1790546953b6db90fe7676e53b626722df8c61/ghc" 3c179054/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c1790546953b6db90fe7676e53b626722df8c61" Support more than 64 logical processors on Windows Windows support for more than 64 logical processors are implemented using processor groups. Essentially what it's doing is keeping the existing maximum of 64 processors and keeping the affinity mask a 64 bit value, but adds an hierarchy above that. This support was added to Windows 7 and so we need to at runtime detect if the APIs are still there due to our minimum supported version being Windows Vista. The Maximum number of groups supported at this time is 4, so 256 logical cores. The group indices are 0 based. One thread can have affinity with multiple groups. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms684251.aspx and particularly helpful is the whitepaper: 'Supporting Systems that have more than 64 processors' at https://msdn.microsoft.com/en-us/library/windows/hardware/dn653313.aspx Processor groups are not guaranteed to be uniformly distributed nor guaranteed to be filled before a next group is needed. The OS will assign processors to groups based on physical proximity and will never partially assign cores from one physical cpu to more than one group. If one has two 48 core CPUs then you'd end up with two groups of 48 logical cpus. Now add a 3rd CPU with 10 cores and the group it is assigned to depends where the socket is on the board. Test Plan: ./validate or make test -c . in the rts test folder. This tests for regressions, to test this particular functionality itself: +RTS -N -qa -RTS Test is detailed in description. Reviewers: bgamari, simonmar, austin, erikd Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2533 GHC Trac Issues: #11054 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.87e17ddddad9f5d5b9fb763747639a9b@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"59d7ee53906b9cee7f279c1f9567af7b930f8636/ghc" 59d7ee5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59d7ee53906b9cee7f279c1f9567af7b930f8636" GHCi: Don't remove shadowed bindings from typechecker scope. The shadowed out bindings are accessible via qualified names like Ghci1.foo. Since they are accessable in the renamer the typechecker should be able to see them too. As a consequence they show up in :show bindings. This fixes T11547 Test Plan: Fixed current tests to accomodate to new stuff in :show bindings Added a test that verifies that the typechecker doesn't crash Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2447 GHC Trac Issues: #11547 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.662789f9770a42a3fc9c1e62bd151889@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: tmcgilchrist Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2542 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"151edd89045c2aed20534c6826711db6a3f253c9/ghc" 151edd8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="151edd89045c2aed20534c6826711db6a3f253c9" Recognise US spelling for specialisation flags. The user guide says that we allow the user to use `specialise` or `specialize` interchangeably but this wasn't the case for the relevant flags. This patch adds aliases for the flags which control specialisation. Reviewers: erikd, austin, mpickering, bgamari Reviewed By: mpickering, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2542 GHC Trac Issues: #12575 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:50:31 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.33b51dfe3595a3f6c04db87992056fd9@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Phab:D2516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1b4fec12250e608ca8a863ba4ef911084c468ef/ghc" d1b4fec1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1b4fec12250e608ca8a863ba4ef911084c468ef" Mark T11978a as broken due to #12019 Test Plan: `validate --slow` Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2536 GHC Trac Issues: #12019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:51:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:51:03 -0000 Subject: [GHC] #11792: Optimised unsafe FFI call can get wrong argument In-Reply-To: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> References: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> Message-ID: <060.a1b5ce9ed1613688f12972abe22f190b@haskell.org> #11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:51:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:51:31 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.72559f83ddd621b8f065b1e2675c2ed3@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11792 | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:51:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:51:53 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.9c30c0473ea70671bccd961f1c93610e@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:52:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:52:18 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.05c776a903969e0274d93c43a551d662@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 21:53:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 21:53:16 -0000 Subject: [GHC] #12575: Support US spelling of `specialise` throughout In-Reply-To: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> References: <047.62bd9e4fc372a97395b7edd7c60b2038@haskell.org> Message-ID: <062.c52e0f36c6bbf4fc3552aa8c4879e901@haskell.org> #12575: Support US spelling of `specialise` throughout -------------------------------------+------------------------------------- Reporter: crockeea | Owner: tmcgilchrist Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2542 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks Tim! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:01:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:01:49 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.91ced5e10a06fc77157b78439f3febb4@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Phab:D2535 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"1e795a008da8ab2ae88cca04aca01c50967b4397/ghc" 1e795a00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e795a008da8ab2ae88cca04aca01c50967b4397" Use check stacking on Windows. Summary: #8870 added as a temporary work around a much higher initial reserve and committed stack space of 2mb. This is causing problems with other windows applications. The hack was supposed to be temporary untill we could emit `__chkstk` instructions. But GCC can emit stack checks automatically for us if `-fstack-check` is passed. This will then emit calls to `___chkstk_ms` before stack allocations. ``` 633de0: 48 83 e0 f0 and $0xfffffffffffffff0,%rax 633de4: e8 07 0c 0d 00 callq 7049f0 <___chkstk_ms> 633de9: 48 29 c4 sub %rax,%rsp ``` The hack is now no longer needed. Test Plan: ./validate Reviewers: austin, erikd, awson, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2535 GHC Trac Issues: #12186 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:01:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:01:49 -0000 Subject: [GHC] #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits In-Reply-To: <047.501c103c18990d0c768d860839513abc@haskell.org> References: <047.501c103c18990d0c768d860839513abc@haskell.org> Message-ID: <062.15eb33d73ac016c852555d10a4407538@haskell.org> #8870: GHC 7.8.0 RC2 fails when compiling a hello world program on Windows 7 32bits ---------------------------------------+--------------------------------- Reporter: facundoq | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #12186 | Differential Rev(s): Wiki Page: | ---------------------------------------+--------------------------------- Comment (by Tamar Christina ): In [changeset:"1e795a008da8ab2ae88cca04aca01c50967b4397/ghc" 1e795a00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e795a008da8ab2ae88cca04aca01c50967b4397" Use check stacking on Windows. Summary: #8870 added as a temporary work around a much higher initial reserve and committed stack space of 2mb. This is causing problems with other windows applications. The hack was supposed to be temporary untill we could emit `__chkstk` instructions. But GCC can emit stack checks automatically for us if `-fstack-check` is passed. This will then emit calls to `___chkstk_ms` before stack allocations. ``` 633de0: 48 83 e0 f0 and $0xfffffffffffffff0,%rax 633de4: e8 07 0c 0d 00 callq 7049f0 <___chkstk_ms> 633de9: 48 29 c4 sub %rax,%rsp ``` The hack is now no longer needed. Test Plan: ./validate Reviewers: austin, erikd, awson, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2535 GHC Trac Issues: #12186 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:02:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:02:28 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.bac6b921c100ade0a3a76b46f7cc9b3e@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Phab:D2535 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:07:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:07:08 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.4f78c05a45d219d5cf4966740eac288e@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The review was accepted so the commit was pushed it seems. Feel free to re-open it if it still doesn't work for you @varosi. Could you try with my simple test program? that should make 88 long lived threads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:07:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:07:54 -0000 Subject: [GHC] #12186: Windows linker stack commit setting causing issues In-Reply-To: <046.69b733e815c109488e9e5245a3102e67@haskell.org> References: <046.69b733e815c109488e9e5245a3102e67@haskell.org> Message-ID: <061.654df926d2175e621cea73fa61625ca1@haskell.org> #12186: Windows linker stack commit setting causing issues -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8870 | Differential Rev(s): Phab:D2535 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:20:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:20:10 -0000 Subject: [GHC] #12602: Add NUMA support to Windows In-Reply-To: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> References: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> Message-ID: <059.75d21035c81a16542fa5928d60925944@haskell.org> #12602: Add NUMA support to Windows -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11054 | Differential Rev(s): Phab:D2534 Wiki Page: | -----------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"c93813d96b1da53a2ebd9c9ac5af6cc3e3443c43/ghc" c93813d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c93813d96b1da53a2ebd9c9ac5af6cc3e3443c43" Add NUMA support for Windows Summary: NOTE: I have been able to do simple testing on emulated NUMA nodes. Real hardware would be needed for a proper test. D2199 Added NUMA support for Linux, I have just filled in the missing pieces following the description of the Linux APIs. Test Plan: Use `bcdedit.exe /set groupsize 2` to modify the kernel again (Similar to D2533). This generates some NUMA nodes: ``` Logical Processor to NUMA Node Map: NUMA Node 0: ** -- NUMA Node 1: -- ** Approximate Cross-NUMA Node Access Cost (relative to fastest): 00 01 00: 1.1 1.1 01: 1.0 1.0 ``` run ` ../test-numa.exe +RTS --numa -RTS` and check PerfMon for NUMA allocations. Reviewers: simonmar, erikd, bgamari, austin Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2534 GHC Trac Issues: #12602 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 1 22:21:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 01 Oct 2016 22:21:23 -0000 Subject: [GHC] #12602: Add NUMA support to Windows In-Reply-To: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> References: <044.a9aaa0ee9a22d5f215cbc7aae5f8a8e6@haskell.org> Message-ID: <059.156ef788e9ee9921a1b29ad473b2be6b@haskell.org> #12602: Add NUMA support to Windows -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11054 | Differential Rev(s): Phab:D2534 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.baf08a037118285521786e2e3409ef78@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d6642bd1956edf8b842c07d78e83c500246998a/ghc" 2d6642b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d6642bd1956edf8b842c07d78e83c500246998a" Fix interaction of record pattern synonyms and record wildcards We were missing an appropiate *ConLike lookup in the case when the pattern synonym was defined in a different module. Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2544 GHC Trac Issues: #11987 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit In-Reply-To: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> References: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> Message-ID: <062.a212f2e98eb3b6e2c7a0fc94ab809e54@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2547 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"ce3370e06165690e79a8eb22e5229b515157e00f/ghc" ce3370e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce3370e06165690e79a8eb22e5229b515157e00f" PPC/CodeGen: fix lwa instruction generation Opcode lwa is a 64-bit opcode and allows a DS-form only. This patch generates lwa opcodes only when the offset is a multiple of 4. Fixes #12621 Test Plan: validate Reviewers: erikd, hvr, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2547 GHC Trac Issues: #12621 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.e600bdd0a3c57a8411d7c8ed2181407f@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | overloadedrecflds/should_compile/T12609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2549 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"48ff0843eee29313cc2da14c04dc57f6589ab040/ghc" 48ff0843/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48ff0843eee29313cc2da14c04dc57f6589ab040" Do not warn about unused underscore-prefixed fields (fixes Trac #12609) When DuplicateRecordFields is enabled, the mangling of selector names was causing them to be reported as unused even if prefixed by an underscore. This corrects the OccName used by the check. Test Plan: New test overloadedrecflds/should_compile/T12609 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2549 GHC Trac Issues: #12609 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call In-Reply-To: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> References: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> Message-ID: <057.05b235b544c6ed92798089a64ca0ebcc@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0014fa56e9f2fe936da85627c92a288037c8c19b/ghc" 0014fa56/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0014fa56e9f2fe936da85627c92a288037c8c19b" ghc-pkg: Allow unregistering multiple packages in one call Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2550 GHC Trac Issues: #12637 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.09ba9cb25eea4e3f3517f57a307570b1@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b0d53a839da0149e0142da036b6ebf5a01b3216f/ghc" b0d53a83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0d53a839da0149e0142da036b6ebf5a01b3216f" Turn `__GLASGOW_HASKELL_LLVM__` into an integer again In GHC < 8.0.1, the value of `__GLASGOW_HASKELL_LLVM__`, exposed through the preprocessor when compiled with `-fllvm`, was an integer value, encoded according to some rules specified in the user guide. Due to an oversight, in GHC 8.0.1 the value of this define became a tuple, exposed as e.g. `(3, 7)`. This was an unintended regression. This patch turns the value of the `__GLASGOW_HASKELL_LLVM__` definition into a single integer again, but changes the formatting of said number slightly. Before, any LLVM version where the major or minor component >= 10 would cause ambiguous values for `__GLASGOW_HASKELL_LLVM__`. With this patch, the value is in line with `__GLASGOW_HASKELL__`, adding a padding `0` in-between major and minor component if applicable (we assume no minors >= 100 will ever exist). The documentation in the user guide is updated accordingly, and a reference is made in the 8.0.2 release notes. Test Plan: validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2552 GHC Trac Issues: #12628 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:56 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.29a5f8c7937c587a68a7f08a3fcc5bb1@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"23cf32da76fe6ed29fa141047749d390df763f94/ghc" 23cf32da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23cf32da76fe6ed29fa141047749d390df763f94" Disallow standalone deriving declarations involving unboxed tuples or sums There was an awful leak where GHC permitted standalone `deriving` declarations to create instances for unboxed sum or tuple types. This fortifies the checks that GHC performs to catch this scenario and give an appropriate error message. Fixes #11509. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2557 GHC Trac Issues: #11509 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:01:55 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.d2d49bd53f3e37adcd0e44ccc336e37a@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T12615 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2545 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1851349acd9e73f1c18d68f70d5cf7b46a843cb5/ghc" 1851349a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1851349acd9e73f1c18d68f70d5cf7b46a843cb5" Don't warn about name shadowing when renaming the patten in a PatSyn decl Previously the renamer assumed that *any* time we renamed a pattern, the pattern was introducing new binders. This isn't true in pattern synonym declarations where the pattern is used as part of a definition. We add a special case to not warn in this situation. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2545 GHC Trac Issues: #12615 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:03:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:03:55 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.7b2aea8b68508253fbaa575e36f51d84@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * version: 8.1 => 8.0.1 * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:04:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:04:23 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.626d26b4b7ce27c12b88d5d77d0df43a@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T12615 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:04:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:04:53 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit In-Reply-To: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> References: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> Message-ID: <062.614e0c643523e4fb160062123c8b8f0b@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2547 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.0.3 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:05:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:05:17 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.b2cbcb41ed9a3843c7d6eccf3bc9a546@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | overloadedrecflds/should_compile/T12609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:05:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:05:52 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.d5224252b19e82fadfd6d0f0cb9a3063@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | overloadedrecflds/should_compile/T12609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: 8.2.1 => 8.0.2 Comment: Second thoughts, perhaps we should try merging this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:06:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:06:25 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call In-Reply-To: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> References: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> Message-ID: <057.a486be6599b17809e8271233ffd89bef@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2550 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:06:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:06:47 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.106ed4dbe2805c16621150e59ee622a4@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:07:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:07:56 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.1309af4445a3692432f16b777c2cefee@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Unless others would prefer we merge this I think I will let this one slide until 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:09:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:09:18 -0000 Subject: [GHC] #12568: Release hsc2hs new version to Hackage In-Reply-To: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> References: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> Message-ID: <061.f08ceeb5d4cc3e50ca63b6b9c6725faf@haskell.org> #12568: Release hsc2hs new version to Hackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 bgamari): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:11:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:11:13 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.5f5508f2f92c46b19cc4444809f8dd35@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * owner: RyanGlScott => * resolution: fixed => Comment: Ack! I apologize Ben, I accidentally linked to the wrong Trac ticket number from the Diff description. Phab:D2557 was meant for #12512, not this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:11:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:11:31 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.c58b502141cf4e445ac839f981ac5819@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2467 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2467 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:12:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:12:42 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.1ce71d9059557103780fbaa43f16c794@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:13:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:13:35 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.e261778df547d31cefaf2eb301829352@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:13:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:13:49 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.16b511bc8aeeae3229a949b7aa7c2ca5@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8040 | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The `HsVersions.h` issue (#8040) has been resolved. Andrey, what is the status of removing the remaining build artifacts out of the tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:19:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:19:30 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.9d60c6991ae64fd3df1cbc6bd04e3db3@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: These were merged as 682518d410a4c522be5d10550c5c915b1f56084d and b20502997c0e1817b2360e3aaabcea31c1d7dedd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:21:01 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.d0f410b63d351316f34f5f6619133c31@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Bumped in 46dc8854b4ff2a8f1a9ca9aa2d0a8271d5bc4ff6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:58:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:58:17 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.8a4c40190b31ca9bcc931789b5a19c56@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 bgamari): The only real sticky spot in this task is `utils/mkUserGuideParts`. It is a utility compiled by stage1 which takes a Haskell data structure containing bits of ReST and outputs ReST sources for the manpage and flags table. Ideally we would have a Sphinx extension to handle this but my previous attempts at this have been thwarted by various annoying technical limitations of Sphinx. The alternative would be to simply build `mkUserGuideParts` with the stage0 compiler (either by default or with a build system setting). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 00:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 00:59:19 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.1080dbe4f358e25a5271d6f4a403db01@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,0 +3,3 @@ + + Moreover, this would make our [http://ghc.readthedocs.org/|readthedocs] + mirror significantly easier to maintain. New description: At HIW 2016 it was suggested that this would greatly reduce the friction to contributing users guide fixes. Moreover, this would make our [http://ghc.readthedocs.org/|readthedocs] mirror significantly easier to maintain. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:02:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:02:09 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.74318fa9d4c2fba25ee23a76c7dab921@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:06:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:06:14 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.51277aa6df6390dd1e100f56123c660a@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Phab:D2557 has been merged to `master` as 23cf32da/ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:10:37 -0000 Subject: [GHC] #11792: Optimised unsafe FFI call can get wrong argument In-Reply-To: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> References: <045.c2134c5a0111e06b4c39b9b8cba0b1db@haskell.org> Message-ID: <060.094accfbd7699a5a7c6c4cf6f0ead83b@haskell.org> #11792: Optimised unsafe FFI call can get wrong argument -------------------------------------+------------------------------------- Reporter: Szunti | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:14 merged as aec4a514857d051f5eeb15b9cbc8e6dd29850c5f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:11:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:11:26 -0000 Subject: [GHC] #12621: zeromq4-haskell fails on PowerPC 64-bit In-Reply-To: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> References: <047.90fa9e203fab82f69cfa3dc6d92dc8e5@haskell.org> Message-ID: <062.e3625b22552d7d221052814295e98ce7@haskell.org> #12621: zeromq4-haskell fails on PowerPC 64-bit ---------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2547 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:3 merged to `ghc-8.0` as aec4a514857d051f5eeb15b9cbc8e6dd29850c5f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:12:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:12:18 -0000 Subject: [GHC] #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled In-Reply-To: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> References: <042.57ea6305ad433132784d27827d80ed1f@haskell.org> Message-ID: <057.b24705f0665eb59070155c05a0841820@haskell.org> #12609: unused-top-binds wrongly warns about underscore-prefixed field names when DuplicateRecordFields enabled -------------------------------------+------------------------------------- Reporter: jml | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | overloadedrecflds/should_compile/T12609 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2549 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: comment:5 merged to `ghc-8.0` as 63ce9ba2f439f4e295ff0791d783eb2103d89843. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:12:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:12:56 -0000 Subject: [GHC] #11987: Allow record wildcards with pattern synonyms which are defined in GHCi In-Reply-To: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> References: <051.5d09bf2154726e8ef31bd08d9049caaa@haskell.org> Message-ID: <066.a794c753ff094e701da6a4483ca913f8@haskell.org> #11987: Allow record wildcards with pattern synonyms which are defined in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2544 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:12 merged to `ghc-8.0 ` as 50e7157b97bf9bd06508fec656836b92668a859c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:13:30 -0000 Subject: [GHC] #12595: Linker failure: multiple definition of In-Reply-To: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> References: <054.0cacd7054e432edce209cb0991fb8538@haskell.org> Message-ID: <069.132d00a83f07356aa81a9302c4ccf492@haskell.org> #12595: Linker failure: multiple definition of -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | deSugar/should_run/T12595 Blocked By: | Blocking: Related Tickets: #10531 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged to `ghc-8.0` as d2695b842dc8ba94fbfb8527f13c7fd14611facb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:14:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:14:47 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.5eb2aeb4599c296e029fc6ab6e6ad311@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: merge Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:6 merged to `ghc-8.0` as cb03d1ccd87a683cb7816a9d2d89a7722040c614. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:14:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:14:52 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.1a41f8dc0069219ab495f24d86223d2c@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:15:02 -0000 Subject: [GHC] #10807: PatternGuards and MultiWayIf layout rules In-Reply-To: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> References: <048.5f26fa8ef546300efdabaf52e9225195@haskell.org> Message-ID: <063.39368e6404ea50286ec7e04b87fb08cb@haskell.org> #10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #7783 | Differential Rev(s): Phab:D2524 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:26:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:26:10 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.66e8c802b41d2fea79654e5683723b5c@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): @darchon could you share any further Brain dump / background / design references either here and or shoot me an email? I'm willing to carve out some work time this week to see if I can help get the ball rolling, but I'd need at least a brain dump or light guidance. I'm not exactly familiar with linker shenanigans but I can probably get at least a skeleton of a patch together if you could orient me towards what pieces of ghc/cabal need tweaking and such. But i need a teeny bit of guidance to make sure it's a good jump start for you or such -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:42:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:42:59 -0000 Subject: [GHC] #12597: -Wmissing-signatures uses forall even when invalid in source In-Reply-To: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> References: <046.75814bd5010a32b1f4ef69cbd93e8718@haskell.org> Message-ID: <061.a109c177f5ecd8fc5570114838b14808@haskell.org> #12597: -Wmissing-signatures uses forall even when invalid in source -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T12597 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Comment:2 merged to `ghc-8.0` as 906ea0445deab65f4dfcba7473593db048cbacab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:44:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:44:01 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.2f5838c584ea9c11f0024d5c8a952192@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0 ` as c448d5513d68da7077b2b4d3adadda93120d8504. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 01:44:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 01:44:18 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.6087530a79ae45574370384be01b7acc@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 03:20:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 03:20:32 -0000 Subject: [GHC] #12651: Test suite should handle stage1 compiler Message-ID: <046.76ab69bf4559f779e818ba50506b7daa@haskell.org> #12651: Test suite should handle stage1 compiler -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sometimes it is useful to run the test suite on a stage1 compiler. But currently, the output is cluttered by many tests failing due to missing support for Template Haskell or interactive use. It would be good if the test suite queried the compiler once whether it has support for that, and then skips tests that use these features. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 03:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 03:22:18 -0000 Subject: [GHC] #12651: Test suite should handle stage1 compiler In-Reply-To: <046.76ab69bf4559f779e818ba50506b7daa@haskell.org> References: <046.76ab69bf4559f779e818ba50506b7daa@haskell.org> Message-ID: <061.808a919736e20464517bb30ed2fa83d0@haskell.org> #12651: Test suite should handle stage1 compiler -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 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 nomeata): Same for {{{ ghc-stage1: Most RTS options are disabled. Use hs_init_with_rtsopts() to enable them. }}} and {{{ T5550.hs:6:1: warning: Ignoring ANN annotation, because this is a stage-1 compiler or doesn't support GHCi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 05:12:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 05:12:02 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.279bb94d6d9b18755c1b8387be8cfaac@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dleuschner): * cc: dleuschner (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 05:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 05:53:29 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types Message-ID: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 08:49:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 08:49:37 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.93ea6f997dbd9d46343c64a8cf015fcd@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Thanks, I'll check it following working week when I have access to that machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 10:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 10:07:15 -0000 Subject: [GHC] #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap Message-ID: <045.54937ce05252b15889a7d80403561924@haskell.org> #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a pretty bad bug in Cabal 1.24's support for reexported modules (https://github.com/haskell/cabal/pull/3906) which means that, under some circumstances, Cabal library will output `reexported-modules` in a form that ghc-pkg will misinterpret. The particular instance I've seen is GHC's build system incorrectly concluding that GHC.Lexeme is provided by ghc- boot rather than ghc-boot-th (because the reexport wasn't parsed correctly). It does not actually seem possible to work around this given a GHC 8.0.1 bootstrap, because we need to register ghc-boot using the bootstrapping ghc-pkg, which will output the package configuration in mangled form. So my advice is: 1. Fix this bug for GHC 8.0.2, so that at least 8.0.2 bootstrap will work even if we have reexported modules in the bootstrap libraries 2. Stop using reexports in ghc-boot; they're not being used for any good reason and will help avoid the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 11:41:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 11:41:53 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.205d8eec41f41ed0d33a357b22ac6378@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): @carter, braindump as requested: * After reading @rwbarton's comment about a person wanting to pack up `dynlib`s for deployment in a single directory, I think I've changed my mind about installation layout. That is, I think the `install_name` of dynlibs should stay `@rpath/libname-x.y.z.dylib` as they are now. * This means that, upon installation, dynlibs should be copied to `$libdir/libname-x.y.z.dylib`, instead of the current `$libdir/libname-x.y.z/libname-x.y.z.dyblib`. * The `.hi` files should still be copied to the `$libdir/libname-x.y.z/` directory. * Perhaps the `a` static lib should also be copied to `$libdir/libname-x.y.z.ar`, for consistency with the `dynlib` dynamic lib. * Due to the use of `nub`, Cabal (in the case of `dynload deploy`) will then already make sure we only end up with a couple of `RPATH` equal to the `$libdir`s of the installed packages. * I'm not sure, but I think GHC also `nub`s the `RPATH`s (in the case of `dynload system`), this would have to be checked. * This plan doesn't involve mucking about with dynamic linking commands. So, if we go with the "put-all-the-dynlibs-in-single-directory" plan, which is what I now prefer, then we would need to do the following: * Add a `--libifacedir` setting to `Cabal`, which is, like `--libsubdir` implicitly prefixed by `$libdir`. `--libifacedir` determines where the `.hi` files go, and the default should be the same as `--libsubdir` (for all platforms) * Change the purpose of `--libsubdir` to mean the the location of the `.dylib`/`.so`/`.a` files. * For OSX only, change the default `libsubdir` to `.`, i.e. equal to `$libdir`. * Update `GHC`s Makefile, so that, on OS X, `make install` puts the `.dylib`/`.so`/`.a` in `$libdir`. Things that still need figuring out: * Do the above changes mean changes in the package database format? if so, what? * Do we need to update `stack` to use the new `--libifacedir` as well? or this it simply take over the default Cabal settings? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 12:49:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 12:49:06 -0000 Subject: [GHC] #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas In-Reply-To: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> References: <046.6861d16fcb9b2c0ec901511e865fc883@haskell.org> Message-ID: <061.c907b6566fec7ed11136aa2bd519efed@haskell.org> #12649: Allow TypeApplications syntax to be used to instantiate type variables in SPECIALISE pragmas -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): Replying to [comment:3 bgamari]: > See proposal [https://github.com/ghc-proposals/ghc-proposals/pull/15|PR #15]. Fixed link: [https://github.com/ghc-proposals/ghc-proposals/pull/15 #15]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 13:05:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 13:05:11 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies In-Reply-To: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> References: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> Message-ID: <066.3fd922debc600136e4e6ce95eadb05c6@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: | FunctionalDependencies 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 Iceland_jack): Thanks for the response! Interesting, since I'm maintaining [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 notes on type classes] what should I say about ''​instance improvement'', that it's not supported by the compiler or is it more complicated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 13:08:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 13:08:53 -0000 Subject: [GHC] #12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] Message-ID: <044.8881c715b9e25b31c2092eb734e27bc0@haskell.org> #12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] -------------------------------------+------------------------------------- Reporter: Kuros | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: ghci panic | Operating System: Windows mvar thread block | Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Full log below (it only interrupted about a minute after i pressed ctrl-C, and I pressed it several times since it didn't respond): *Main> foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] Interrupted. *Main> ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 14:29:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 14:29:31 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.ddedc94a73bea9d45e59611641457e9f@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Let the record show that darchon is ChristianB :) I'll ask you some more off line so I can better understand -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 15:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 15:40:35 -0000 Subject: [GHC] #12614: Integer division can overwrite other arguments to foreign call In-Reply-To: <046.8ed09565bce5acc57db433cace631df1@haskell.org> References: <046.8ed09565bce5acc57db433cace631df1@haskell.org> Message-ID: <061.a24b3e5e934ffb327fc2fdbd12af70ba@haskell.org> #12614: Integer division can overwrite other arguments to foreign call -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: integer | division Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11792 | Differential Rev(s): Phab:D2263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Comment:5 merged to `ghc-8.0` as aec4a514857d051f5eeb15b9cbc8e6dd29850c5f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 15:46:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 15:46:18 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.f7ec898434ade7bf899a5a9d29d40ec9@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => * milestone: => 8.0.2 Comment: Indeed this still seems to be broken on OS X. I can confirm the behavior seen by mpickering in comment:9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 16:05:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 16:05:54 -0000 Subject: [GHC] #12599: Add Hadrian build artifacts to gitignore In-Reply-To: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> References: <046.76d1d3362cf9536c216105dd4980909b@haskell.org> Message-ID: <061.e7c228067c837d3da1a63a42b88a642a@haskell.org> #12599: Add Hadrian build artifacts to gitignore -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8040 | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks Ben! I've moved generated includes outside of the tree. The remaining bits are: 1. Files produced by `ghc-cabal` (e.g. `package-data.mk`) 2. Package configuration folders such as `libraries/bootstrapping.conf` 3. Program binaries If I understand correctly, we can close this ticket after fixing (1), as the Make build system also builds (2) and (3) in the tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 16:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 16:10:37 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.b974112c6896fb3a5a1ec1bf66dc7dfd@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): * owner: => nomeata Comment: JFTR, I’m working on implementing this. Not sure if one week is enough, there seems to be an endless supplies of code paths that have a catch-all pattern match on `CoreExpr` and thus are not found by the compiler. My work is in `wip/T12618`. Stage 1 compiles, and seems to work mostly, but if I build ghc-stage2 with it, `ghc-stage2` crashes with an `internal error: evacuate(static): strange closure type 0`. If someone enjoys debugging these kind of problems, let me know... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 18:54:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 18:54:38 -0000 Subject: [GHC] #12593: ghci spins forever In-Reply-To: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> References: <051.e29334c249e21da5fb3951c3bd36247a@haskell.org> Message-ID: <066.62858c3221aa2940dfab22bad2a65b60@haskell.org> #12593: ghci spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T12593 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Comment:4 merged to `ghc-8.0` as 836f0e248b21c4f802b3dce1593f975296e56ba4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 18:55:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 18:55:15 -0000 Subject: [GHC] #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int In-Reply-To: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> References: <047.b7ad7b4e19ac04c794127f686108b95f@haskell.org> Message-ID: <062.409a524e35c8dd69d4d2e75b07a294de@haskell.org> #12628: __GLASGOW_HASKELL_LLVM__ is no longer an Int -------------------------------------+------------------------------------- Reporter: nicolast | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Driver | Version: 8.0.1 Resolution: fixed | Keywords: llvm cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged to `ghc-8.0` as 3b13a0426f59b47fb27646c694caf1df55a684e3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 19:17:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 19:17:16 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.0631195ab88a79f735bfebbab219001d@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3630ad355a5b7be0240d3071bb662fe710909cca/ghc" 3630ad3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3630ad355a5b7be0240d3071bb662fe710909cca" Mark #6132 as broken on OS X It currently fails with, =====> T6132(normal) 1 of 1 [0, 0, 0] cd "./runghc/T6132.run" && "/Users/bgamari/ghc/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output Compile failed (exit code 1) errors were: T6132.hs:1:2: error: parse error on input ‘#!/’ *** unexpected failure for T6132(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 19:17:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 19:17:16 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.c0122e3ed567ed66abdb68ad928bd829@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e9104d46eab0a2fbf7af9a299da3763bcf39f148/ghc" e9104d46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9104d46eab0a2fbf7af9a299da3763bcf39f148" DynFlags: Fix absolute import path to generated header Test Plan: Validate Reviewers: austin, snowleopard Reviewed By: snowleopard Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2559 GHC Trac Issues: #8040. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 19:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 19:17:17 -0000 Subject: [GHC] #12355: Invalid assembly in foreign prim In-Reply-To: <043.e628067e14a84102326ba14e6b406a11@haskell.org> References: <043.e628067e14a84102326ba14e6b406a11@haskell.org> Message-ID: <058.c3a1472727002a4f2f04eb974970a8d3@haskell.org> #12355: Invalid assembly in foreign prim -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 Ben Gamari ): In [changeset:"eda5a4ab6c2032ec13d9cd0aac258bb14f0b2ec9/ghc" eda5a4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eda5a4ab6c2032ec13d9cd0aac258bb14f0b2ec9" testsuite: Mark test for #12355 as unbroken on Darwin. Somehow this testcase works on Darwin but not on Linux. This deserves further investigation. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 19:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 19:23:22 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.01584ef5020195c0d7265395d8799a05@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 19:23:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 19:23:36 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.45acf430a7aa7768dda22736d0df141a@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => simonpj @@ -4,1 +4,1 @@ - {{{ + {{{#!hs New description: The following program (reduced from Cabal code that uses HasCallStack) typechecks in GHC 8.0, but not on HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module Foo where type T a = (?x :: Int) => a type M a = T (IO a) f :: T (T a -> a) f x = x g :: Int -> M () g = undefined h :: Int -> M () -- h x = f (g x) -- works on HEAD h = f . g -- fails on HEAD, works on GHC 8.0 }}} It's possible that this is just fall out from the recent impredicativity changes but I just wanted to make sure that this was on purpose. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 20:26:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 20:26:46 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.5e1c624abafd7ceeaa6c9482321d92e8@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 ezyang): Confirmed that b612da667fe8fa5277fc78e972a86d4b35f98364 is the regressing commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 23:22:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 23:22:57 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies In-Reply-To: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> References: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> Message-ID: <066.441611bf794db2b9a9a82dcc92c95cf1@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: | FunctionalDependencies 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 goldfire): Instance improvement happens only when you have a "wanted" constraint -- that is, when you're typechecking a function call of `f` where `f` has a class constraint with a functional dependency. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 2 23:51:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 02 Oct 2016 23:51:29 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.f1b50edbd76d280a0f7ee87d5630f8d2@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -13,3 +13,2 @@ - in a prefix way, thus: `(->) Int# Int#`. And this is unusual. - because they are never in scope in the source - }}} + in a prefix way, thus: `(->) Int# Int#`. And this is unusual because + they are never in scope in the source New description: Currently the `(->)` type constructor has kind `* -> * -> *` (with some magic to make infix work for unlifted types. To quote the comment attached to `TysPrim.funTyCon`, > You might think that `(->)` should have type `?? -> ? -> *`, and you'd be right. But if we do that we get kind errors when saying > {{{ > instance Control.Arrow (->) > }}} > because the expected kind is `* -> * -> *`. The trouble is that the expected/actual stuff in the unifier does not go contra-variant, whereas the kind sub-typing does. Sigh. It really only matters if you use `(->)` in a prefix way, thus: `(->) Int# Int#`. And this is unusual because they are never in scope in the source This seems to imply that the restrictive kind arose out of the old subkinding story. Now that we have a more principled way of dealing with non-lifted kinds it seems we allow prefix uses to be as polymorphic as infix uses. Something like, {{{#!hs (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). TYPE rep1 -> TYPE rep2 -> * }}} Not only would this be a win for consistency, but it may also address some of the Core Lint issues that I'm seeing in #11011. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 00:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 00:49:21 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.57dc598cd9701f60a3be1592401503b4@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 goldfire): The new behavior looks correct to me. `g`'s type expands to `Int -> (?x :: Int) => IO ()`, and it's critical that the `(?x :: Int)` bit does not get instantiated for this to type-check. Accordingly, the type parameters to `(.)` would have to be qualified types for this to work, so I say this is an improvement in behavior. Of course, it might just be time to extend the `($)` hack to work with `(.)`, too. Until we do so, though, we should reject the original program. Simon, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 01:42:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 01:42:39 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.404b63c4d17a9349e07b9368a12903bb@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): It seems I get `internal error: evacuate(static): strange closure type 0` only with a dynamically built GHC, not with a statically built (as it is the case on Travis). If that rings a bell with someone that could save me further debugging work, I’d be grateful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 05:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 05:29:19 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) Message-ID: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a bug in an old ghc (7.4.2), documenting it here mostly in case anybody else comes across it. If you try to compile http://hackage.haskell.org/package/bytestring-builder-0.10.8.1.0 /bytestring-builder-0.10.8.1.0.tar.gz , ghc fails with {{{ src/Data/ByteString/Builder/Prim.hs:553:13: Illegal bang-pattern (use -XBangPatterns): ! br' }}} However, that file contains a directive {{{#!hs {-# LANGUAGE CPP, BangPatterns, ScopedTypeVariables #-} }}} at the very top of the file, so we should not be getting this error message. Now here's the bizarre thing: if we compile with `cabal --builddir=foo`, compilation happens as normal! I ran ghc with `--keep- tmp-files`, and compared the output of CPP for both variations, and literally the ''only'' difference between the two that lines {{{ # 156 "./dist/build/autogen/cabal_macros.h" }}} in one are {{{ # 156 "./foo/build/autogen/cabal_macros.h" }}} in the other. It gets weirder. I replaced the output of `src/Data/ByteString/Builder/Prim.hs` with the output of `cpp`, and removed the `CPP` language directive. If I start with the version that has `dist` (i.e., the one that results in a compilation error), ''even adding or removing a single blank line in the header of the file made the parser error go away'' (where the "header" is the bit with lines such as {{{ # 134 "./dist/build/autogen/cabal_macros.h" }}} No idea what's going on here; probably not worth investigating further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 06:09:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 06:09:46 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) In-Reply-To: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> References: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> Message-ID: <059.89e03cdfdf620a43958e76492ab0108c@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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: | -------------------------------------+------------------------------------- Comment (by ezyang): It's a bug in the lexer that was subsequently fixed. See also https://github.com/haskell/cabal/issues/3739#issuecomment-244950926 and https://github.com/ghc/ghc/commit/c250f93bd38c7d8f6453dd79dd9951f9a02bf5a7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 06:25:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 06:25:19 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) In-Reply-To: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> References: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> Message-ID: <059.729e6c06c89482b3e2e0d9858b9d1375@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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: | -------------------------------------+------------------------------------- Comment (by edsko): Aha, I see. That makes sense. Do you have any suggested workarounds? Just found another package that suffers from the same problem: http://hackage.haskell.org/package/primitive-0.6.1.0/primitive-0.6.1.0.tar.gz . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 06:46:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 06:46:49 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) In-Reply-To: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> References: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> Message-ID: <059.22cfd89afea5e06cc74ab9970d550315@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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: | -------------------------------------+------------------------------------- Comment (by edsko): Hmmm {{{ package bytestring-builder ghc-options: -XBangPatterns package primitive ghc-options: -XMagicHash }}} is a work-around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 07:12:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 07:12:50 -0000 Subject: [GHC] #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) In-Reply-To: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> References: <044.6aa0c5a5e84a6a2a41bd4e78684bbb04@haskell.org> Message-ID: <059.b878dc12a03e64bc4b4aa195471fa207@haskell.org> #12655: Bizarre parser problem: "Illegal bang-pattern" (something to do with CPP?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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: | -------------------------------------+------------------------------------- Comment (by ezyang): Well, you can certainly jiggle around the preprocessor output until the lexer accepts it correctly, but the particular output depends a lot on system configuration so someone else might run into the issue. hvr has suggested that if you increase the default buffer size much larger, you're unlikely to run into the problem, but that requires a recompile of GHC. Another possibility is to put all the LANGUAGE flags in a single pragma so there is only one `{-` token to lex. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 07:50:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 07:50:16 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.70ade8739dbc93ebc0bb8f0873f78750@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See comment:119 on #6018 for a use-case example. I think the latest version of all this is in the main repo, on branch `wip/T10832-generalised-injectivity` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 08:08:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 08:08:53 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.edcb8dc499f422068f19d17c7dc48749@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): The case in comment:1 is behaving correctly. The type of `x` is generalised to `x :: forall a. a`. So the info from two uses of `x` in `(x, f x)` do not communicate with each other. Even `-XMonoLocalBinds` does not solve this, because with this flag GHC still generalises local bindings that have no free variables. I still need to look at the Description; but comment:1 looks fine to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 08:33:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 08:33:56 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.72a70411863ce2d2481f8e7cf5904c0f@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): For the Description, what is happening is this: * The ill-arity'd pattern `Whoops a -> ..` makes the typechecker emit an error message and fail with a hard error; rightly so. * Usually the typing constraints arising from the failing computation would be discarded. But as a short-cut for a common case, GHC does not begin a new implication constraint for the RHS of `foo`, because it has no tyvars and no given constraints. * So the `Monad a` constraint arising from the call of `return` is accumulated into the top-level constraints of the whole program; so after recovering from the error GHC tries to solve the constraint. Two possible solutions * Remove the special case. That looks OK, but it'd mean that we might solve `(Num Int)` repeatedly in different function definitions. CSE can common-up later, but it's just more work. * In the special case, accumulate constraints in a separate variable, and union them into the outer context only if the typecheck succeeds. Not hard to do; I think this is probably best. Thanks for the accurate report! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 08:46:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 08:46:06 -0000 Subject: [GHC] #12650: Too many warnigns about consistentCafInfo In-Reply-To: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> References: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> Message-ID: <061.a1fc34c9ce109fda97bc5e60981af671@haskell.org> #12650: Too many warnigns about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I agree. Potentially this a serious warning. Someone should look into it! It happens if * The info about CAF-hood predicted by `CorePrep` differ from... * the info about CAF-hood discovered by `CoreToStg` I can advise. As a systematic fix, I really want to get info about arity and CAF-hood from the `CoreToStg` pass, and NOT predict it in `CorePrep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 08:51:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 08:51:15 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.3a20b3d6ec6905846a8aca435c0397ef@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): Indeed! Why not ''always'' build `mkUserGuideParts` with stage0? It's just a utility, right? Absolutely no need to build it with stage1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 08:56:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 08:56:58 -0000 Subject: [GHC] #12355: Invalid assembly in foreign prim In-Reply-To: <043.e628067e14a84102326ba14e6b406a11@haskell.org> References: <043.e628067e14a84102326ba14e6b406a11@haskell.org> Message-ID: <058.3a1b31ca0bf39f3a746ac153718d96f8@haskell.org> #12355: Invalid assembly in foreign prim -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): 2563 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => 2563 Comment: The foreign symbol name is missing. With the "prim" calling convention, the empty entity string doesn't get replaced with the function name "f1" (while it does with the "ccall" convention). Hence the "jmp" without target in the generated asm. Proposed patch: https://phabricator.haskell.org/D2563 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 09:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 09:03:21 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.69bdb6f2a0b8e02fe458870b66e2f207@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by clinton: @@ -1,2 +1,5 @@ - I'm not sure if this is a bug or hanging the compiler is expected here. - This was the minimal example that causes GHC to hang: + There's a subtle issue going on with injective type families. Simply + reordering the arguments can cause an otherwise legal program to hang on + compile. Calling `f_bad` instead of `f_good` will cause the compiler to + hang, looping forever in the typechecker, but the only difference between + `TF_Good` and `TF_Bad` is that the argument order is swapped. @@ -5,1 +8,1 @@ - {-# LANGUAGE TypeFamilyDependencies #-} + {-# LANGUAGE TypeFamilyDependencies #-} @@ -7,1 +10,2 @@ - main = return $ f (Just 'c') + main = return $ f_good (Just 'c') + --main = return $ f_bad (Just 'c') @@ -9,2 +13,2 @@ - data D1 x - data D2 + type family TF x y = t | t -> x y + type instance TF Int Float = Char @@ -12,3 +16,2 @@ - type family TF x = t | t -> x - type instance TF (D1 x, a) = Maybe (TF (x, a)) - type instance TF (D2, ()) = Char + type family TF_Good x y = t | t -> x y + type instance TF_Good a (Maybe x) = Maybe (TF a x) @@ -16,2 +19,8 @@ - f :: TF (x, a) -> () - f _ = () + f_good :: TF_Good a x -> () + f_good _ = () + + type family TF_Bad x y = t | t -> x y + type instance TF_Bad (Maybe x) a = Maybe (TF a x) + + f_bad :: TF_Bad x a -> () + f_bad _ = () New description: There's a subtle issue going on with injective type families. Simply reordering the arguments can cause an otherwise legal program to hang on compile. Calling `f_bad` instead of `f_good` will cause the compiler to hang, looping forever in the typechecker, but the only difference between `TF_Good` and `TF_Bad` is that the argument order is swapped. {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} main = return $ f_good (Just 'c') --main = return $ f_bad (Just 'c') type family TF x y = t | t -> x y type instance TF Int Float = Char type family TF_Good x y = t | t -> x y type instance TF_Good a (Maybe x) = Maybe (TF a x) f_good :: TF_Good a x -> () f_good _ = () type family TF_Bad x y = t | t -> x y type instance TF_Bad (Maybe x) a = Maybe (TF a x) f_bad :: TF_Bad x a -> () f_bad _ = () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 09:06:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 09:06:05 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.cd1796c40df94ef96465b7c4a1b9a411@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 simonpj): Richard is right on all counts. This works {{{ h = (.) @(M ()) @(M ()) @Int f g }}} recalling that `(.)` has type {{{ (.) :: forall b c a. (b -> c) -> (a -> b) -> a -> c -- Defined in ‘GHC.Base’ }}} It seems to me that if a special case for `($)` is justified, then having one for `(.)` as well would make sense. Perhaps using it should require `-XImpredicativeTypes` though? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 09:57:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 09:57:34 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.c2203936eaf865d34b7e5281516d7aea@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): Modified example code again. A recursive definition is not required for the bug to occur, and the order of arguments matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 11:45:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 11:45:18 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.3f2c010cd1cc6bacd253b8a73b827f83@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 goldfire): I'm all for making `(.)` special in the type-checker, but I don't think it should require `ImpredicativeTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:42:02 -0000 Subject: [GHC] #12656: ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour Message-ID: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> #12656: ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program using `Data.Vector.unsafeThaw` and `-fno-cse`: {{{ {-# OPTIONS_GHC -fno-cse #-} import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM main :: IO () main = do foo 100000 foo 100000 foo :: Int -> IO () foo n = do indexVector <- V.unsafeThaw $ V.generate n id x <- VM.read indexVector 5 VM.write indexVector 5 (x * x) print x -- In GHCI, we get: -- -- > :set -fno-cse -- -- > foo 100000 -- 5 -- > foo 100000 -- 5 -- -- > let f = foo 100000 in f >> f -- 5 -- 25 }}} I would expect that {{{ > let f = foo 100000 in f >> f 5 5 }}} Shouldn't `-fno-cse` fix this? (Note: With `ghc` instead of `ghci`, we don't observe this behaviour.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:42:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:42:27 -0000 Subject: [GHC] #12656: ghci floats out constant despite -fno-cse (was: ghci floats out constant despite -fno-cse, resulting in very unintuitive behaviour) In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.d32bd6a8524ceefc9b2a8da2b0c609b5@haskell.org> #12656: ghci floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:45:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:45:51 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse (was: ghci floats out constant despite -fno-cse) In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.0d2baf96148b397dbde80f3e7063c94c@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nh2: @@ -13,0 +13,2 @@ + + let f = foo 100000 in f >> f @@ -47,1 +49,1 @@ - (Note: With `ghc` instead of `ghci`, we don't observe this behaviour.) + (Note: This also happens with `ghc` instead of `ghci`.) New description: Consider this program using `Data.Vector.unsafeThaw` and `-fno-cse`: {{{ {-# OPTIONS_GHC -fno-cse #-} import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM main :: IO () main = do foo 100000 foo 100000 let f = foo 100000 in f >> f foo :: Int -> IO () foo n = do indexVector <- V.unsafeThaw $ V.generate n id x <- VM.read indexVector 5 VM.write indexVector 5 (x * x) print x -- In GHCI, we get: -- -- > :set -fno-cse -- -- > foo 100000 -- 5 -- > foo 100000 -- 5 -- -- > let f = foo 100000 in f >> f -- 5 -- 25 }}} I would expect that {{{ > let f = foo 100000 in f >> f 5 5 }}} Shouldn't `-fno-cse` fix this? (Note: This also happens with `ghc` instead of `ghci`.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:47:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:47:56 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.a2f1e9d59a346c3eded0aebd83b6c4c4@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Note that `{-# OPTIONS_GHC -fno-full-laziness #-}` also doesn't help here; how could I prevent the floating-out so that the use of `unsafeThaw` is safe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:50:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:50:30 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.e55474aa9354251dd6a5606057e5c09f@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Another note, using `-O` fixes the problem with `-O`, `main` prints: {{{ 5 5 5 5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:52:34 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.8a888fc227df4dc4f9cf79529a428d29@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): This is using ghc `8.0.1` with `vector` from stackage `lts-7.1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 14:56:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 14:56:28 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.0bb257e57223aa1fac6362c5617f82eb@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Have you tried `{-# NOINLINE foo #-}`? With unsafe stuff, it is often important to keep this local. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 15:01:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 15:01:32 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.6a8452b5ba54d3e4227364ec6b50148a@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): I've verified that this happens with GHC 7.8 (lts-3) too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 15:04:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 15:04:34 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.598ed7c9b6a11baf219ac79493d5b385@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): nomeata: `NOINLINE` will prevent this behavior because there will be no opportunity for floating out the expression and eliminating it. However, we're trying to understand why `-fno-full-laziness -fno-cse` does not prevent this, since it seems like it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 15:07:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 15:07:32 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.00b953923ab0c303a92104437830fe9f@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): Actually I spoke too soon: this doesn't work even with `NOINLINE`! {{{ $ cat weird-float.hs import qualified Data.Vector as V import qualified Data.Vector.Mutable as VM main :: IO () main = do foo 100000 foo 100000 let f = foo 100000 in f >> f {-# NOINLINE foo #-} foo :: Int -> IO () foo n = do indexVector <- V.unsafeThaw $ V.generate n id x <- VM.read indexVector 5 VM.write indexVector 5 (x * x) print x $ stack exec --resolver lts-7 --package vector -- ghc -fforce-recomp -package vector -O0 -fno-full-laziness -fno-cse weird-float.hs -o weird- float-lts-7 Run from outside a project, using implicit global project config Using resolver: lts-7 specified on command line Selected resolver: lts-7.2 [1 of 1] Compiling Main ( weird-float.hs, weird-float.o ) Linking weird-float-lts-7 ... $ ./weird-float-lts-7 5 5 5 25 $ stack exec --resolver lts-7 --package vector -- ghc --version Run from outside a project, using implicit global project config Using resolver: lts-7 specified on command line Selected resolver: lts-7.2 The Glorious Glasgow Haskell Compilation System, version 8.0.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 17:20:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 17:20:46 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault Message-ID: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault ----------------------------------------+---------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- When compiling a package (cabal or stack doesn't matter) or launching GHCi while running a kernel with GrSec and PaX patches, GHC segfaults because GrSec denies an RWX mmap. Some packages do compile successfully, but others (such as optparse- applicative) don't. Launching GHCi always results in a segfault. Here's the output of ghc when compiling the optparse-applicative package: {{{ Building optparse-applicative-0.13.0.0... Preprocessing library optparse-applicative-0.13.0.0... [ 1 of 15] Compiling Options.Applicative.Help.Pretty ( Options/Applicative/Help/Pretty.hs, dist/build/Options/Applicative/Help/Pretty.o ) [ 2 of 15] Compiling Options.Applicative.Help.Chunk ( Options/Applicative/Help/Chunk.hs, dist/build/Options/Applicative/Help/Chunk.o ) [ 3 of 15] Compiling Options.Applicative.Help.Types ( Options/Applicative/Help/Types.hs, dist/build/Options/Applicative/Help/Types.o ) [ 4 of 15] Compiling Options.Applicative.Types ( Options/Applicative/Types.hs, dist/build/Options/Applicative/Types.o ) [ 5 of 15] Compiling Options.Applicative.Internal ( Options/Applicative/Internal.hs, dist/build/Options/Applicative/Internal.o ) [ 6 of 15] Compiling Options.Applicative.Common ( Options/Applicative/Common.hs, dist/build/Options/Applicative/Common.o ) [ 7 of 15] Compiling Options.Applicative.Help.Core ( Options/Applicative/Help/Core.hs, dist/build/Options/Applicative/Help/Core.o ) ghc: mmap 131072 bytes at (nil): Operation not permitted ghc: Try specifying an address with +RTS -xm -RTS Segmentation fault (core dumped) }}} GrSec log in dmesg: {{{ [15873.000867] grsec: denied RWX mmap of by /usr/lib/ghc-8.0.1/bin/ghc[ghc_worker:16494] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/cabal[cabal:16486] uid/euid:1000/1000 gid/egid:1000/1000 [15873.001018] ghc_worker[16494]: segfault at 0 ip 000003b6c3a7167f sp 000002b6c23d8e50 error 6 in libHSrts_thr-ghc8.0.1.so[3b6c3a4f000+62000] }}} And here's the one for ghci: {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help ghc: mmap 131072 bytes at (nil): Operation not permitted ghc: Try specifying an address with +RTS -xm -RTS Segmentation fault (core dumped) $ echo $? 139 }}} GrSec complained here with: {{{ [14756.354725] grsec: denied RWX mmap of by /usr/lib/ghc-8.0.1/bin/ghc[ghc:15883] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/xonsh[xonsh:15879] uid/euid:1000/1000 gid/egid:1000/1000 [14756.354875] ghc[15883]: segfault at 0 ip 00000379c0e0b67f sp 000003f0b7278ce0 error 6 in libHSrts_thr-ghc8.0.1.so[379c0de9000+62000] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 17:21:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 17:21:37 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.7eb250138368ad8abe25facba37d7d54@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -----------------------------------+-------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by PoroCYon): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 17:22:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 17:22:43 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.abbe618e5392d131b5c89968ba757695@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by PoroCYon): * keywords: => grsec, pax, mmap, rts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 17:27:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 17:27:47 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.ce7a932a6fa18b4210c7327383fd4e41@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by PoroCYon: @@ -7,0 +7,4 @@ + + I've tried mounting /tmp as executable (as described eg. + [http://stackoverflow.com/questions/6103510/ghc-cabal-install-hamlet- + fails-with-an-obscure-error here]), but that didn't do anything. New description: When compiling a package (cabal or stack doesn't matter) or launching GHCi while running a kernel with GrSec and PaX patches, GHC segfaults because GrSec denies an RWX mmap. Some packages do compile successfully, but others (such as optparse- applicative) don't. Launching GHCi always results in a segfault. I've tried mounting /tmp as executable (as described eg. [http://stackoverflow.com/questions/6103510/ghc-cabal-install-hamlet- fails-with-an-obscure-error here]), but that didn't do anything. Here's the output of ghc when compiling the optparse-applicative package: {{{ Building optparse-applicative-0.13.0.0... Preprocessing library optparse-applicative-0.13.0.0... [ 1 of 15] Compiling Options.Applicative.Help.Pretty ( Options/Applicative/Help/Pretty.hs, dist/build/Options/Applicative/Help/Pretty.o ) [ 2 of 15] Compiling Options.Applicative.Help.Chunk ( Options/Applicative/Help/Chunk.hs, dist/build/Options/Applicative/Help/Chunk.o ) [ 3 of 15] Compiling Options.Applicative.Help.Types ( Options/Applicative/Help/Types.hs, dist/build/Options/Applicative/Help/Types.o ) [ 4 of 15] Compiling Options.Applicative.Types ( Options/Applicative/Types.hs, dist/build/Options/Applicative/Types.o ) [ 5 of 15] Compiling Options.Applicative.Internal ( Options/Applicative/Internal.hs, dist/build/Options/Applicative/Internal.o ) [ 6 of 15] Compiling Options.Applicative.Common ( Options/Applicative/Common.hs, dist/build/Options/Applicative/Common.o ) [ 7 of 15] Compiling Options.Applicative.Help.Core ( Options/Applicative/Help/Core.hs, dist/build/Options/Applicative/Help/Core.o ) ghc: mmap 131072 bytes at (nil): Operation not permitted ghc: Try specifying an address with +RTS -xm -RTS Segmentation fault (core dumped) }}} GrSec log in dmesg: {{{ [15873.000867] grsec: denied RWX mmap of by /usr/lib/ghc-8.0.1/bin/ghc[ghc_worker:16494] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/cabal[cabal:16486] uid/euid:1000/1000 gid/egid:1000/1000 [15873.001018] ghc_worker[16494]: segfault at 0 ip 000003b6c3a7167f sp 000002b6c23d8e50 error 6 in libHSrts_thr-ghc8.0.1.so[3b6c3a4f000+62000] }}} And here's the one for ghci: {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help ghc: mmap 131072 bytes at (nil): Operation not permitted ghc: Try specifying an address with +RTS -xm -RTS Segmentation fault (core dumped) $ echo $? 139 }}} GrSec complained here with: {{{ [14756.354725] grsec: denied RWX mmap of by /usr/lib/ghc-8.0.1/bin/ghc[ghc:15883] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/xonsh[xonsh:15879] uid/euid:1000/1000 gid/egid:1000/1000 [14756.354875] ghc[15883]: segfault at 0 ip 00000379c0e0b67f sp 000003f0b7278ce0 error 6 in libHSrts_thr-ghc8.0.1.so[379c0de9000+62000] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 17:50:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 17:50:08 -0000 Subject: [GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 Message-ID: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 --------------------------------+--------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- This happened when building http-link-header. {{{ ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8ghc: internal error: scavenge: unimplemented/strange closure type 63270 @ 0xf36de0a8 (GHC version 7.10.3 for powerpc_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sometimes it segfaults instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 20:02:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 20:02:36 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.f7d82794644c44c3bb368c6799deb607@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): The program which you shared is the program that I use for tests already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 21:12:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 21:12:34 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.d71a92545c581272e9b82a48b8fe56d9@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I've ran '''synth.bash''' benchmark ('''ghc make -j +RTS -A256M''') on current '''ghc-HEAD''' on the following machines: - 4x2 HT desktop, speedup is '''3.9x''' compared to '''-j1''' case (best at -j8) - 12x2 HT haswell VM, speedup is '''12.7x''' compared to '''-j1''' case (best at -j24) - 8x4 HT Power Power7, speedup is '''8.1x''' compared to '''-j1''' case (best at -j12) Very similar speedup is achieved in multiprocess mode (via Makefile in comment:#65). A few facts: - Multiprocess run is ~10% faster than multithreaded. - Specifying N more than logical CPUs available (say, -j100) in '''ghc make -j''' does not lead to severe performance degradation at least on up to 12 core hardware. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 01:26:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 01:26:36 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.67e56d50be3fe8e3f49f0b35eeb3569e@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Given that the type-indexed Typeable rework will provide support for pulling the kind out of a `TypeRep` I'm going to close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 01:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 01:28:40 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.4ed739f93fd6c66ab4db65abbf4af4b8@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) Comment: Simon, I had meant to mention this ticket in our meeting today. Do you think you could have a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 04:42:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 04:42:01 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.b0b60a1fb396b049bda4ec1999502510@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Bisection points to 15fc52819c as the commit that fixed the issue in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 06:40:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 06:40:59 -0000 Subject: [GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 In-Reply-To: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> References: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> Message-ID: <059.72b418ffaf1e9610830084d5ef0a7e39@haskell.org> #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 ---------------------------------------+------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) Comment: Is this reproducable or intermittent? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 08:13:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 08:13:20 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.ea6663289ce2632ce18c8bf56002c8a0@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): In case any more motivation is needed here: we have had to stop using `deriving Generic` and find alternative methods due to this problem, so it's an actual blocker for some use cases of `deriving Generic`. Do we know what the problem is? Is it fixable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 08:42:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 08:42:31 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.3bf29ec17e3aa969fe87fddf5b722175@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We don't seem to have a well-characterised idea of what is actually going wrong here. As I said in comment:25 we need more info. It really just needs someone to pay a bit of time and attention to identify exactly what is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 11:23:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 11:23:35 -0000 Subject: [GHC] #12659: Unactionable core lint warning due to floating out Message-ID: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> #12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was looking through the build log to try and make it a bit less noisy by removing some warnings. There were quite a lot of core lint warnings which complain about INLINE progams on loop breakers. However, sometimes these bindings are not marked INLINE at the source level but by GHC itself. {{{ cmmDebugLink :: [Label] -> [DebugBlock] -> [DebugBlock] cmmDebugLink labels blocks = map link blocks where blockPos :: LabelMap Int blockPos = mapFromList $ flip zip [0..] labels link block = block { dblPosition = mapLookup (dblLabel block) blockPos , dblBlocks = map link (dblBlocks block) } }}} For example, in this function, `link` gets floated out to the top level and then marked as `INLINE` even though it is self-recursive. This causes the following warning: {{{ *** Core Lint warnings : in result of CorePrep *** 5170 : warning: 5171 [RHS of link_slxp :: DebugBlock -> DebugBlock] 5172 INLINE binder is (non-rule) loop breaker: link_slxp 5173 }}} But because it's generated by the compiler, there isn't a sensible way to suppress the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 13:09:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 13:09:29 -0000 Subject: [GHC] #12659: Unactionable core lint warning due to floating out In-Reply-To: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> References: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> Message-ID: <064.8e9b55db7f89fa4a6265088a1bceeae2@haskell.org> #12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 simonpj): That's odd. Can you identify where in the compiler this INLINE pragma is getting added? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 13:29:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 13:29:40 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot Message-ID: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current state of the `ghc-8.0` branch (a24092ff501028ca1245b508320493f394378495) apparently fails to compile the `singletons` library, yet 8.0.1 and `master` work fine. The compiler appears to loop. See https://github.com/goldfirere/singletons/issues/162#issuecomment-251272894. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 13:51:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 13:51:11 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.e9b515c0a981a7213a4baef91f1727a7@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): The work in #8472 to float primitive string literals to the top did fix the issue I described in https://phabricator.haskell.org/D1259#72921, but it turns out there's another issue leading to increased allocations elsewhere in nofib. I've minimized the `parstof` benchmark to {{{ module Foo where c_the_program=(++) "main ip =\n" ((++) " i2str (optim (myMain deciem))\n" ((++) ";\n" ((++) "\n" ((++) "TYPE tJobdef = [ JOBDEF, int, int, int, tJobdef, tJobdef ] ;\n" ((++) "TYPE tJobstat = [ JOBSTAT, int, int, int, int, tJobdef ] ;\n" ((++) "TYPE tTree = [ LEAF, int |\n" ((++) " TREE, tTree, tTree ] ;\n" ((++) "TYPE tProc = [ PROC, int, tJobstat ] ;\n" ((++) "\n" ((++) "\n" ((++) "\n" ((++) "emptyjobdef = [JOBDEF, 0 , 0 , 0, emptyjobdef, emptyjobdef] ;\n" "")))))))))))) }}} which is just a chain of appends (though the number of `(++)` seems to matter!). GHC HEAD optimizes this into a single string literal, whereas my patch gives {{{ -- RHS size: {terms: 1, types: 0, coercions: 0} Foo.c_the_program11 :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 120 0}] Foo.c_the_program11 = "main ip =\n\ \ i2str (optim (myMain deciem))\n\ \;\n"# -- RHS size: {terms: 1, types: 0, coercions: 0} Foo.c_the_program10 :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 620 0}] Foo.c_the_program10 = "TYPE tJobdef = [ JOBDEF, int, int, int, tJobdef, tJobdef ] ;\n\ \TYPE tJobstat = [ JOBSTAT, int, int, int, int, tJobdef ] ;\n\ \TYPE tTree = [ LEAF, int |\n\ \ TREE, tTree, tTree ] ;\n\ \TYPE tProc = [ PROC, int, tJobstat ] ;\n"# -- RHS size: {terms: 1, types: 0, coercions: 0} Foo.c_the_program7 :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 190 0}] Foo.c_the_program7 = "emptyjobdef = [JOBDEF, 0 , 0 , 0, emptyjobdef, emptyjobdef] ;\n"# -- RHS size: {terms: 2, types: 0, coercions: 0} Foo.c_the_program6 :: [Char] [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Foo.c_the_program6 = GHC.CString.unpackCString# Foo.c_the_program7 -- RHS size: {terms: 3, types: 1, coercions: 0} Foo.c_the_program5 :: [Char] [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] Foo.c_the_program5 = ++ @ Char Foo.c_the_program8 Foo.c_the_program6 ... }}} It's able to eliminate some of the `(++)` calls, but not all. I'm not yet sure why this is happening, but I imagine it involves a `(++)` term being floated out before we eliminate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 13:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 13:54:17 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.329f100b9ee42f0d054ce3acb7c820a9@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I'm not sure how much headway I'll make between now and the weekend, what pieces of this plan are / are not obvious? One issue that came up in the IRC chat with Duncan is cabal new build style needs treatment too? What are the low hanging action items , the easy ones, and the tricky bits? I have Sierra hardware now, so there's that At the very least I'll make sure I file a radar this week -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 14:12:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 14:12:09 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable In-Reply-To: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> References: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> Message-ID: <065.68e32446b926690ddb3685bc2e877b0a@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc3 Resolution: invalid | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Once the type-indexed `Typeable` work gets merged in (#11011), this ticket will no longer be relevant, since neither `typeRepArgs` nor `typeRepKinds` will exist anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 14:19:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 14:19:54 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.eeb4f9201be65da2c208768a62c7f39b@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 14:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 14:53:28 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.388382f6f1badeffadc62bd7e55addd9@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 14:55:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 14:55:46 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.e5f3770b6c6b2405931fd05b64906c8a@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 bgamari): I quickly built a new profiled compiler and built `singletons` which revealed, {{{ stack overflow: use +RTS -K to increase it *** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: GHC.defaultErrorHandler.\, called from TcCanonical.canEvVar, called from TcInteract.solve_loop, called from TcInteract.solveSimples, called from TcRnDriver.simplifyTop, called from TcRnDriver.tcRnSrcDecls, called from HscMain.Typecheck-Rename, called from GhcMake.upsweep_mod.compile_it, called from GhcMake.upsweep_mod, called from GhcMake.upsweep.upsweep', called from GhcMake.upsweep, called from GhcMake.load, called from GHC.withCleanupSession, called from GHC.runGhc, called from GHC.defaultErrorHandler }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:16:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:16:40 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.f3cc881780a03f68bd8e9bc88ec6ff4b@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 bgamari): `TcCanonical.canEvVar` calls `TcCanonical.canEvNC` which has no cost center but does have a `traceTcS`. Compiling `singletons` with `-ddump-tc- trace` shows that the compiler indeed seems to be looping in the typechecker, {{{ ... Following filled tyvar s_aov1[fuv:20] = n1_alUY[ssk] GHC.TypeLits.- n0_alUX[ssk] flattenTyVarFinal x2_alWb[sk] :: Nat Nat _N :: Nat ~ Nat flattenTyVar1 (x2_alWb[sk] :: Nat) _N :: Nat ~ Nat flattenTyVar2 n1_alUY[ssk] x2_alWb[sk] flattenTyVarFinal x1_alWa[sk] :: Nat Nat _N :: Nat ~ Nat flattenTyVar1 (x1_alWa[sk] :: Nat) _N :: Nat ~ Nat flattenTyVar2 n0_alUX[ssk] x1_alWa[sk] flatten/flat-cache hit GHC.TypeLits.- [x2_alWb[sk], x1_alWa[sk]] s_aov1[fuv:20] Following filled tyvar s_aov1[fuv:20] = n1_alUY[ssk] GHC.TypeLits.- n0_alUX[ssk] ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:28:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:28:04 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.48320bb5be1d11aa978639d04d6c9768@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): First note that `main` (and thus `-fno-cse`) is a red herring, since the behavior under consideration is that of `let f = foo 100000 in f >> f` which does not mention `main`. But this is just normal Haskell laziness in action, which becomes clear if you desugar `foo`. {{{ foo :: Int -> IO () foo n = (>>=) (V.unsafeThaw $ V.generate n id) (...) }}} If you bind `foo 100000` to a name `f`, then `f`'s subexpression `V.generate 100000 id` will only ever be evaluated once during the lifetime of `f`. Moral: `unsafeThaw` is unsafe. What's more mysterious is why you get the "expected" behavior from compiled code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:35:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:35:45 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.f2262f914278a51953cdbb0fbc966f1a@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > What's more mysterious is why you get the "expected" behavior from compiled code. That could be the effect of the state hack, turning foo n = (>>=) (V.unsafeThaw $ V.generate n id) (...) into foo n rw# = (>>=) (V.unsafeThaw $ V.generate n id) (...) rw# and hence making `foo 1000` a PAP where nothing is shared yet. (Did not look at the Core, though.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:36:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:36:48 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.c25756ca17f8149b9791757311fd2ced@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It's because clang's CPP inserts a space before the `#` and then GHC no longer recognizes it as a shebang line. See #10044 for a related clang whitespace oddity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:38:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:38:10 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.5c6c61d584ee09a858319f2beef3ed0b@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitonic): rwbarton: You're very right -- the fact that it "worked" compiling normally threw us in a loop. Thanks for clarifying! In light of this, I think we should warn people that `unsafeThaw` is way unsafer than the docs imply... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:40:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:40:01 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.fa01f6b67e7e5774d70f1d93e9572139@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh I misread some of the earlier comments; it's only with `-O` that you get the "expected" behavior, while `ghc` without optimization behaves the same as `ghci`. Then there is no mystery (and indeed `-fno-state-hack` restores the non-optimized behavior as nomeata guessed). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:43:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:43:36 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.f7c739e5e21b5bdf5012e56c2b4effd1@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:23 trommler]: > Replying to [comment:22 erikd]: > > @trommler Yes, that may well be worth while. > OK, I am working on it and will report back. So, I compiled all of Stackage 7.x on a POWER 8 LPAR instance with 8 CPUs, so no qemu involved and saw five packages fail with a panic in `mkFastStringWith`. A few more failed with segfaults in `Setup build -j8`. I used ghc 8.0.1 patched with the two patches in this ticket. My theory is that `lwsync` is not a strong enough barrier for a write barrier. So far I thought a write barrier is the same as a store-store barrier and hence `lwsync` is the right choice on PowerPC. I could put a `sync` and see what happens but I would like to know what I am doing when using that big a hammer. So what is the semantics of a write barrier with respect to other processors/cores? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 15:51:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 15:51:40 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.7c6ef0fb3323efd77f2361a2a17fcf2d@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Thanks for filing an issue. This was reported on IRC too (possibly by the same person?) Could you run one of these failing commands under gdb and provide the stack trace? (It will likely be short/strange but that's okay.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:02:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:02:05 -0000 Subject: [GHC] #12647: Can't capture improvement of functional dependencies In-Reply-To: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> References: <051.4f950f5c03a87c5e8fda36c69ee5b590@haskell.org> Message-ID: <066.de4d8636ebcec5a6ef92c47170517a10@haskell.org> #12647: Can't capture improvement of functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: | FunctionalDependencies 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 rwbarton): See related discussion at http://stackoverflow.com/questions/34645745/can-i-magic-up-type-equality- from-a-functional-dependency/, #11534, and various other Trac tickets linked from there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:04:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:04:12 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.50d4ebf9dc4d39fca121aca14a004a2f@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 bgamari): Reverting 2c3b77e44fd1f982a6416db5edc212f22c3dbcbf appears to allow `singletons` to build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:04:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:04:54 -0000 Subject: [GHC] #12637: ghc-pkg: Allow unregistering multiple packages in one call In-Reply-To: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> References: <042.e1ef6d72ea1e95ae24c3ca2748b1776e@haskell.org> Message-ID: <057.ab0f95b7614abafd6458de8d71dd9d35@haskell.org> #12637: ghc-pkg: Allow unregistering multiple packages in one call -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2550 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well okay, but I can't help but feel that the problem here is not in GHC, but in your infrastructure... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:05:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:05:37 -0000 Subject: [GHC] #12659: Unactionable core lint warning due to floating out In-Reply-To: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> References: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> Message-ID: <064.d6e916ac7e6e0da3713e7e9643f13300@haskell.org> #12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 mpickering): Do you have any ideas where to look? I had a brief search but it wasn't clear to me where that could happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:14:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:14:28 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.209886079096cb4359b44ba01b740689@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks Reid! Yet another reason to move to hpp, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:48:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:48:22 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.83398e6736b8989051df8e3ed22e6073@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): darchon said, > I'm not sure, but I think GHC also nubs the `RPATH`s (in the case of dynload system), this would have to be checked. For the record, I believe we compute the linker command line in `SysTools.linkDynLib`, which calls `collectLibraryPaths` to compute the set of needed `RPATH` directories. `collectLibraryPaths` indeed calls `nub`, but it does **not** `sort` before doing so, meaning that `nub` won't always remove all duplicates. This should be fixed. `Cabal` should also be checked for this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:51:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:51:22 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.9efbfcb8b03a96953d28195dd284b997@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oops, please excuse the cognitive malfunction above; `nub` does not require sorted input. It seems GHC is fine with respect to `RPATH` deduplication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 16:55:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 16:55:36 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.bb57588e0c5e52793bdc8694224db712@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): darchon said, > * For OSX only, change the default `--libsubdir` to `.`, i.e. equal to `$libdir`. > * Update GHCs `Makefile`, so that, on OS X, `make install` puts the .dylib/.so/.a in `$libdir`. I'm not sure we want to limit this to OS X. Having many `RPATH` directories is also a startup performance issue on Linux (and likely other platforms) since the dynamic linker does a linear search through every `RPATH` directory for every library it needs to load. This was noticed in #11587. The solution to this is to move all dynamic libraries into `$libdir`, as you suggest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 18:33:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 18:33:50 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows Message-ID: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> #12661: Testsuite driver fails on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I encountered the following failure in the testsuite driver while bringing up the new Windows build bot, {{{ PYTHON="python2" "python2" ../../driver/runtests.py -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno- debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=False -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=3 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../config"' -e 'config.platform="x86_64-unknown- mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/home/drydock/ghc/testsuite"' --config 'compiler="/home/drydock/ghc/inplace/bin/ghc-stage1.exe"' --config 'ghc_pkg="/home/drydock/ghc/inplace/bin/ghc-pkg.exe"' --config 'haddock="/home/drydock/ghc/inplace/bin/haddock.exe"' --config 'hp2ps="/home/drydock/ghc/inplace/bin/hp2ps.exe"' --config 'hpc="/home/drydock/ghc/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=1" --summary-file "../../../testsuite_summary_stage1.txt" --no-print-summary 1 \ \ \ \ \ \ \ Warning: Ignoring request to use threads as running on Windows Traceback (most recent call last): File "../../driver/runtests.py", line 174, in if mydll.kernel32.SetConsoleCP(65001) == 0: File "/usr/lib/python2.7/ctypes/__init__.py", line 435, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory }}} From the repl it indeed seems that `ctypes.cdll.kernel32` is broken, {{{ $ python >>> import ctypes >>> ctypes.cdll.kernel32 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/ctypes/__init__.py", line 421, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python3.4/ctypes/__init__.py", line 351, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory }}} Tamar, do you have any idea what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 19:10:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 19:10:06 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.63e4eff71b3bdf32f962e1195e6f0813@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 goldfire): I see what's going on, but I don't know why things are the way they are nor how to fix. The problem is, essentially, that we unflatten and then continue solving. Then, we have a fuv (flattening unification variable) that's filled in with the function it equals. So the flattener ends up bouncing between the function application and its fuv (as found in the flat-cache). The unflattening is happening in `TcInteract.solve_simple_wanteds`, as called from `solveSimpleWanteds`. But then the `go` loop in the latter goes around again. It does so in the same instance of the `TcS` monad, so that flat-cache is retained, even though unflattening has happened. And then we're in trouble. Questions: 1. Should the flat-cache be wiped every time we unflatten? 2. Should we even allow unflattening in the `TcS` monad? I always thought unflattening was about restoring nice-looking types for error messages and something that should happen just as we leave the `TcS` monad. But we shouldn't resume solving after unflattening, I think. I'm afraid I've reached the limit of what I can do with this ticket. Simon? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 19:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 19:47:20 -0000 Subject: [GHC] #12662: Investivate ListSetOps module Message-ID: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> #12662: Investivate ListSetOps module -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that the `ListSetOps` module is very inefficient and there are probably better ways to do what it does elsewhere in GHC. This is an open ended ticket to: 1. Investigate where functions from `ListSetOps` are used in GHC. 2. Investigate how easy it is to remove the usages of these functions. 3. Remove the module if it is feasible to do so. Seems like it might be good for a newcomer? Someone else can tag it so if they agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 19:47:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 19:47:27 -0000 Subject: [GHC] #12659: Unactionable core lint warning due to floating out In-Reply-To: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> References: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> Message-ID: <064.e89968038e3c94ae183eaa3198c5e343@haskell.org> #12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): * keywords: newcomer => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 19:49:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 19:49:10 -0000 Subject: [GHC] #12662: Investigate ListSetOps module (was: Investivate ListSetOps module) In-Reply-To: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> References: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> Message-ID: <064.4b1e42f4a567c37933da332046beb185@haskell.org> #12662: Investigate ListSetOps module -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 19:57:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 19:57:12 -0000 Subject: [GHC] #12650: Too many warnigns about consistentCafInfo In-Reply-To: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> References: <046.40ea905426dbe7661cf6e9cb791197a4@haskell.org> Message-ID: <061.2cdcf11c8771536b5602d33d48fab983@haskell.org> #12650: Too many warnigns about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 20:32:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 20:32:19 -0000 Subject: [GHC] #12659: Unactionable core lint warning due to floating out In-Reply-To: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> References: <049.54a78ea9a8119295b8ce2a0abddeca5b@haskell.org> Message-ID: <064.74888063bcc5eec83bc70ccac97a133e@haskell.org> #12659: Unactionable core lint warning due to floating out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Well I'd start with `-dverbose-core2core` and see which pass introduces the INLINE pragma. Try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 20:38:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 20:38:00 -0000 Subject: [GHC] #12656: ghc floats out constant despite -fno-cse In-Reply-To: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> References: <042.f54b1c5628c5120453d62c4cafc074e3@haskell.org> Message-ID: <057.a0269004b49e0ece116000bec2e63792@haskell.org> #12656: ghc floats out constant despite -fno-cse -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In light of this, I think we should warn people that unsafeThaw is way unsafer than the docs imply... Or at least that if you are going to use `unsafeThaw` then `-fno-state- hack` would be a good companion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 20:50:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 20:50:11 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.63f04c40ce57a8d46967caa0c8c3e039@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: duplicate | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433, 2725 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by avd): * status: new => closed * resolution: => duplicate * related: 12433 => 12433, 2725 Comment: This ticket is a duplicate of #2725. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 20:58:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 20:58:35 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.7e7513e2c11f25279834db5ca0d811dd@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by PoroCYon): Here's the backtrace of the compilation of hlint: {{{ poro at alphard:~ $ sudo coredumpctl gdb /usr/lib/ghc-8.0.1/bin/ghc PID: 6326 (ghc) UID: 1000 (poro) GID: 1000 (poro) Signal: 11 (SEGV) Command Line: /usr/lib/ghc-8.0.1/bin/ghc -B/usr/lib/ghc-8.0.1 --make -fbuilding-cabal-package -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi -outputdir .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build -odir .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build -hidir .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -stubdir .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -i -i.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -isrc -i.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen -I.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen -I.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -optP-include -optP.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/cabal_macros.h -this- unit-id hlint-1.9.35-10UG0p2vPBnEAFpFKv6Oh -hide-all-packages -no-user- package-db -package-db /home/poro/.stack/snapshots/x86_64-linux/lts-7.0/8.0.1/pkgdb -package-db .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/package.conf.inplace -package-id ansi-terminal-0.6.2.3-448ipfN5j28Ha0AgPiJmdI -package-id base-4.9.0.0 -package-id cmdargs-0.10.14-8WOlFWoK1XlCebTZE2edgd -package- id containers-0.5.7.1 -package-id cpphs-1.20.2-GpD5nXqQjzpAbSUhSdFgEv -package-id directory-1.2.6.2 -package-id extra-1.4.10-2LEZ2hBhlUuEhqffYmrH30 -package-id filepath-1.4.1.0 -package- id haskell-src-exts-1.17.1-CHFwoWxepXQKBbAz4YNlQX -package-id hscolour-1.24.1-H2EUF2muHY0JRKOYWigHLc -package-id process-1.4.2.0 -package-id refact-0.3.0.2-JBbxaqExt5tJMSfYCjPwkx -package-id transformers-0.5.2.0 -package-id uniplate-1.6.12-GlIXchq8eyU5fQlB5lQgci -XHaskell98 Language.Haskell.HLint Language.Haskell.HLint2 Language.Haskell.HLint3 Paths_hlint Apply CmdLine Grep HLint HsColour Idea Settings Report Util Parallel Refact HSE.All HSE.Bracket HSE.Evaluate HSE.FreeVars HSE.Match HSE.Scope HSE.Type HSE.Util Hint.All Hint.Bracket Hint.Comment Hint.Duplicate Hint.Extensions Hint.Import Hint.Lambda Hint.List Hint.ListRec Hint.Match Hint.Monad Hint.Naming Hint.Pattern Hint.Pragma Hint.Type Hint.Unsafe Hint.Util Test.All Test.Annotations Test.InputOutput Test.Proof Test.Translate Test.Util -ddump-hi -ddump-to- file Core was generated by `/usr/lib/ghc-8.0.1/bin/ghc -B/usr/lib/ghc-8.0.1 --make -fbuilding-cabal-package'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000003295de4567f in initLinker_ () from /usr/lib/ghc-8.0.1/bin/../rts/libHSrts_thr-ghc8.0.1.so [Current thread is 1 (Thread 0x32968f52700 (LWP 6326))] (gdb) bt #0 0x000003295de4567f in initLinker_ () from /usr/lib/ghc-8.0.1/bin/../rts/libHSrts_thr-ghc8.0.1.so #1 0x0000032961baf4cd in ghcizm8zi0zi1_GHCiziRun_run1_info () from /usr/lib/ghc-8.0.1/bin/../ghci-8.0.1/libHSghci-8.0.1-ghc8.0.1.so #2 0x0000000000000000 in ?? () }}} I wasn't on IRC, I'm^H was only lurking on #idris at the time of reporting this issue (Idris does compile btw). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 21:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 21:07:47 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.270366e3f5b475139914dcef0bef0bfe@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well the apppend-string rule is in `PrelRules.lhs`: {{{ match_append_lit :: [Expr CoreBndr] -> Maybe (Expr CoreBndr) match_append_lit [Type ty1, Lit (MachStr s1), c1, Var unpk `App` Type ty2 `App` Lit (MachStr s2) `App` c2 `App` n ] = ... }}} Notice that it maches only on actual literal strings. If they are floated to top level they'll be replaced by a `Var`. Probably an `Id` whose unfolding is the literal string, but still it won't match the above. Instead you probably need to use `exprIsLiteral_maybe` as in {{{ match_Word64ToInteger _ id_unf id [xl] | Just (MachWord64 x) <- exprIsLiteral_maybe id_unf xl = case splitFunTy_maybe (idType id) of }}} later in the same module. Try that? Indeed, ''every'' match on a `Lit` pattern in these rules should go via `exprIsLiteralMaybe`. See if this works and then maybe at least open a ticket for the others; preferably do them. Could be a big win! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 21:11:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 21:11:08 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.269a5651f571506c8238faf5bca499fd@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Ah yes, I was wondering about that built-in match. Thanks for the pointer to `exprIsLiteral_maybe`, I'll give it a try! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 22:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 22:02:12 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.c741daec124340787ab8f52cd09cd4e3@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Actually, that's not the problem (though it may well be a profitable change regardless). The problem can be illustrated even more simply. {{{ module Foo where str = "foo" ++ "\n" ++ "\n" }}} We would like GHC to optimize this into {{{ str = "foo\n\n" }}} but the pre-emptive lifting/cse that I've done during desugaring gives us {{{ foo = "foo" n = "\n" str = foo ++ n ++ n }}} At this point the simplifier is in a bind because in order to fully inline everything, it would have to '''duplicate''' the `"\n"` string, and GHC presumably knows this is generally a bad idea. Removing the pre-emptive CSE from the desugarer resolves this issue :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 4 23:06:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 04 Oct 2016 23:06:25 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.e832e7c49aa44d668c7036c6916ba39c@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I had a look. What is happening is this. We have a wanted constraint {{{ [W] TF (x_aDY, a_aJn) ~ s_aF4 FunEq }}} where `s_aF4` is a flatten-unification-variable; and in our mdel we have {{{ [D] s_aF4 ~ Maybe Char }}} We can't reduce the wanted constraint so we try irmpvoement. Now rightly or wrongly, "improvement" kicks in, by matching the constraint with the axiom {{{ type instance TF (D1 x, a) = Maybe (TF (x, a)) }}} In improvement we seem to use "pre-unification" from the paper, so that matching `Maybe Char` against `Maybe (TF (x,a))` succeeds. So we emit two new derived constraint {{{ [D] a_aJn ~ a_fresh1 [D] x_aDY ~ D1 x_fresh2 }}} The match on RHS is incomplete so we just get a "shape", with fresh unification variables. But that is bad. Now we take `[D] a_aJn ~ a_fresh1` as our next work item, unify `a_a7n := a_fresh`, kick out the TF FunEq, and now we are in an infinite loop. Question: why do we use pre-unification when matching the RHS in the injectivity-improvement step. That's what is causing the trouble. Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 03:01:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 03:01:41 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.fb220dd015ccc780b8cd4d9cb212183a@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): The more I think about this, the less convinced I am that a `nofloat` or even a local `noupdate` annotation really helps. The problem is: where do we put the annotation? The whole point of having such an annotation, as opposed to just disabling full laziness in the whole module, is to have more fine grained control over where full laziness applies and where it doesn't. This was easy in the example that this ticket started with {{{#!hs enum xs = zip (nofloat [1..]) xs }}} but it's far less obvious in larger examples. For example, consider the definition of a conduit that implements the HTTP protocol (Michael Snoyman's http-conduit package), or a conduit that does constant space type inference for large JSON documents (an example from the code base I am working on). Now how do we know what in these definitions to mark as `nofloat`? If we get it wrong, then full laziness might float something else out that we weren't expecting, and we might once again end up with a difficult to debug space leak. The only really workable solution would be to mark the whole body as `nofloat`, but now we've lost the advantage of fine granularity. I'm guessing @tomjaguarpaw will say at this point "see! the problem is full laziness itself" and to be honest, I'm starting to get more and more convinced by that point of view. However, I still believe that there is an alternative by means of the NOUPDATE annotation. But, having thought about it more, I don't think annotating the ''constructors'' is the right approach. @simonpj asks for a minimal example, so let's consider this one: {{{#!hs module Main (main) where import System.IO.Error data Sink = Await (Maybe Char -> Sink) | Done Int countFrom :: Int -> Sink countFrom n = Await $ \mi -> case mi of Nothing -> Done n Just _ -> countFrom $! n + 1 feedFrom :: Int -> Sink -> IO () feedFrom _ (Done n) = print n feedFrom 0 (Await f) = feedFrom 0 (f $ Nothing) feedFrom n (Await f) = feedFrom (n - 1) (f $ Just 'A') retry :: IO a -> IO a retry io = catchIOError io (\_ -> retry io) main :: IO () main = retry $ feedFrom 1000000 (countFrom 0) }}} A `Sink` (a special kind of "conduit") is some kind of automaton that accepts (`Await`s) a bunch of inputs (in this case `Char`s) and at some point terminates (`Done`). Let's recap from the blog post why this has a space leak: 1. `feedFrom 1000000 (countFrom 0)` is a PAP (waiting for its `State# RealWorld` argument) 2. When `retry` executes the action, it maintains a reference to that PAP from the exception handler. 3. In the environment of the PAP is a thunk corresponding to `countFrom 0`. 4. Finally, and crucially, full laziness is turning the definition of `countFrom` to something more akin to {{{#!hs -- Full laziness turns countFrom into: countFrom :: Int -> Sink countFrom n = let k = countFrom $! n + 1 in Await $ \mi -> case mi of Nothing -> Done n Just _ -> k }}} (The example with the original definition of `countFrom` has a space leak when compiled with `-O` but no space leak with `-O -fno-full-laziness`; if we use this version of `countFrom`, we have a space leak with or without full laziness enabled.) (1)-(4) together means that there is a reference from the PAP's environment to the `countFrom 0` thunk, and as `feedFrom` evaluates that thunk we build up a long chain {{{ Await ---payload---> FUN ---environment---> Await ---payload---> ... }}} where every `Await` constructor has a function as its payload, and that function has a reference to the next `Await` constructor in its environment (closure) (section "Full laziness versus sinks" of http://www .well-typed.com/blog/2016/09/sharing-conduit/ has some pictures.). So what's the solution here? Perhaps one might argue that full laziness is the culprit here; it should not have floated out that continuation in `countFrom`. Like I said, I'm starting to have a lot of sympathy for that point of view; I will soon need to publish an erratum to my blog post because I was once again underestimating full laziness. BUT. We can ask a different question: do we really want to be thinking so hard about when and where things get allocated precisely? What if the user ''themselves'' wrote that alternative version of `countFrom` -- after all, it seems like an innocuous change. Should we really have to think so low- level when writing Haskell code? I would like to be able to answer "no" to that question. Here's the thing: conduits (and other structures like it) are data structures designed to drive computation; we _never_ expect them to be shared and built up in memory. (When we were discussing these matters at Well-Typed a comparison was drawn to data versus codata.) I think it would be great if we could express this, and `NOUPDATE`, I think, might allow us to do that. However, I now think annotating the constructors is not the right approach. In addition to Simon's probing questions, above, let's consider the example `countFrom`. What is the thunk that we don't want to be updateable? Well, `countFrom 0` really; and, if pressed for another one, the `Sink` in the environment of the continuation in countFrom (`countFrom $! n + 1`). ''Neither of those is the argument to a constructor.''. I think that instead we should annotate the ''type'': {{{#!hs {-# NOUPDATE Sink #-} data Sink = Await (Maybe Char -> Sink) | Done Int }}} Now questions such as "who created this thing? do we need spooky action at a distance?" are no longer relevant. It's simple and type directed. Any thunk of type `Sink` never gets updated. Some other minor bits and bobs: Replying to [comment:19 simonpj]: > I'm beginning to get glimmers of understanding about this no-update thing. Consider > {{{ > t1 = [1..n] > vs > t2 = \_ -> [1..n] > vs > t3 = let x = [1..n] in \_ -> x > }}} > Note that > > * If we use `t1` in a shared context like `sum t1 / length t1`, we'll end up materialising the whole list. > * For `t2`, we'd get `sum (t2 ()) / length (t2 ())`, and now the list is computed twice rather than duplicated. Note that `t1` and `t2` have different types of course. > * Then `t3` is the result of applying the full laziness transformation to `t2`, and its space behaviour is back to that of `t1`. > > Reflections: > > * I think that this "noupdate" pragma is intended to achieve an effect like `t2`, but more conveniently, without changing types. Correct? Exactly. If we had a list type that was marked as `NOUPDATE`, then `sum t1 / length t1` would not have a space leak (though the list would be evaluated twice). > * I think (but am not sure) that you intend to use this only for one- shot thunks, where (unlike the sum/count example) the thunk is evaluated only once. In which case it would often be discarded after being evaluated, in which case where does the leak come from. A small, concrete example would be jolly useful. No, I don't think that's necessarily the case. Marking something as `NOUPDATE` would imply that you're okay with it being evaluated more than once; indeed, that's what you want. In the minimal example I've been discussing in this comment, we ''want'' that conduit (sink) to be re- evaluated should the exception handler be run. > * Notice how important it is that in `t2` the lambda ''syntactically encloses'' the leaky computation. Otherwise you get `t3`. I think this is another reason to move to a type directed approach instead. Syntactic enclosure is too brittle and too prone to be affected by the optimizer. Replying to [comment:20 jpbernardy]: > As it turns out, we currently have a proposal on the table which is capable of expressing where sharing should not occur, in a principled way, by using types. > > This page sums up how it may play out in Edsko's example. > > https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Examples#Controllingsharingfulllaziness > Hmmm, I had not realized the connection to linearity, and I wasn't aware of this work. Must take a closer look (my PhD is on uniqueness typing :). I'm not sure however that linearity is what we want here. Do we want to reject a definition such as {{{#!hs someConduit = do x <- await case x of True -> do foo ; someConduit False -> do foo ; someConduit }}} If conduits can never be shared, this would be type incorrect. This would seem too restrictive. `NOUPDATE` in a way is kind of opposite to linearity: it's fine to share, just make sure that every time we access this value we recompute it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 03:25:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 03:25:38 -0000 Subject: [GHC] #8457: -ffull-laziness does more harm than good In-Reply-To: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> References: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> Message-ID: <059.9b17201b700a97689cdc49cbfe24fc8b@haskell.org> #8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #12620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): My blog post underestimated the perils of full laziness. Proposed erratum at https://www.reddit.com/r/haskell/comments/55xk4z/erratum_to_sharing_memory_leaks_and_conduit_and/ . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 04:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 04:48:04 -0000 Subject: [GHC] #12663: amazonka-ec2 fails to build with --split-objs Message-ID: <048.229708a11b5fa85980c94db5223a3842@haskell.org> #12663: amazonka-ec2 fails to build with --split-objs -------------------------------------+------------------------------------- Reporter: joehillen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've created a repo for reproducing this bug: https://github.com/joehillen/ec2-split-objs-bug The bug can appear as either: {{{ [189 of 207] Compiling Network.AWS.EC2.Waiters ( gen/Network/AWS/EC2/Waiters.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/Waiters.o ) [190 of 207] Compiling Network.AWS.EC2.DeleteVPNConnection ( gen/Network/AWS/EC2/DeleteVPNConnection.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/DeleteVPNConnection.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fFoldableFirst_$cfold’ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} or {{{ [189 of 207] Compiling Network.AWS.EC2.Waiters ( gen/Network/AWS/EC2/Waiters.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/Waiters.o ) [190 of 207] Compiling Network.AWS.EC2.DeleteVPNConnection ( gen/Network/AWS/EC2/DeleteVPNConnection.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Network/AWS/EC2/DeleteVPNConnection.o ) /tmp/stack11/amazonka- ec2-1.4.3/gen/Network/AWS/EC2/DeleteVPNConnection.hs:51:25: error: • Couldn't match expected type ‘Either a0 a10’ with actual type ‘a1 -> ShowS’ • Probable cause: ‘showsPrec’ is applied to too few arguments In the first argument of ‘GHC.Show.showList__’, namely ‘(showsPrec 0)’ In the expression: GHC.Show.showList__ (showsPrec 0) In an equation for ‘showList’: showList = GHC.Show.showList__ (showsPrec 0) When typechecking the code for ‘showList’ in a derived instance for ‘Show DeleteVPNConnection’: To see the code I am typechecking, use -ddump-deriv /tmp/stack11/amazonka- ec2-1.4.3/gen/Network/AWS/EC2/DeleteVPNConnection.hs:104:23: error: • Couldn't match expected type ‘Either a2 a3’ with actual type ‘a4 -> ShowS’ • Probable cause: ‘showsPrec’ is applied to too few arguments In the first argument of ‘GHC.Show.showList__’, namely ‘(showsPrec 0)’ In the expression: GHC.Show.showList__ (showsPrec 0) In an equation for ‘showList’: showList = GHC.Show.showList__ (showsPrec 0) When typechecking the code for ‘showList’ in a derived instance for ‘Show DeleteVPNConnectionResponse’: To see the code I am typechecking, use -ddump-deriv }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 05:24:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 05:24:05 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.a5806fd57719a5b3c22b547d093ec04b@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 06:12:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 06:12:51 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.1c0213b9c206c2dd53ec9d36e97db621@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jpbernardy): edsko: the above definition would be rejected only if the **data** inside the conduit would be linear (`x`), instead of the conduit itself. It is fine to make the conduit type linear and its contents shared. Incidentally, I have written a stream library based on this idea, and it's described here: https://jyp.github.io/pdf/Organ.pdf The paper goes into the implication that linearity has in this case, in quite depth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 09:59:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 09:59:10 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.b30ff75c1ffacf23ee4073e8f02404ac@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Related work: Joachim Breitner's (unpublished) paper "dup – Explicit un- sharing in Haskell" (https://arxiv.org/pdf/1207.2017v1.pdf). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 10:34:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 10:34:27 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.88da767d0121bc895be3b97d7a593bec@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > At this point the simplifier is in a bind because in order to fully inline everything, it would have to duplicate the "\n" string, and GHC presumably knows this is generally a bad idea. Yes, this is a key choice. Look at `CoreSubst.exprIsLiteral_maybe`. It calls `expandUnfolding_maybe`. Look at `CoreSyn.expandUnfolding_maybe`. It expands the unfolding if `uf_expandable` is True. That flag says if it's ok to expand an unfolding to make a RULE match. But in comment:20 I see "Expandable = True" for those top-level string literals. So they should be visible to the rule matcher. Some link in this chain isn't working. But I hope you can see the links now, so you can see what's not working? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 11:06:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 11:06:53 -0000 Subject: [GHC] #12664: System.Environment.withArgs and friends leak memory Message-ID: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> #12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ArgvLeak.hs`: {{{ import System.Environment main :: IO () main = withArgs ["a","b","c"] $ return () }}} repro: {{{ > ghc ArgvLeak.hs [1 of 1] Compiling Main ( ArgvLeak.hs, ArgvLeak.o ) Linking ArgvLeak ... > valgrind --leak-check=full ./ArgvLeak ==27227== Memcheck, a memory error detector ==27227== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==27227== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==27227== Command: ./ArgvLeak ==27227== ==27227== Warning: set address range perms: large range [0x200000000, 0x600100000) (noaccess) ==27227== ==27227== HEAP SUMMARY: ==27227== in use at exit: 107 bytes in 9 blocks ==27227== total heap usage: 62 allocs, 53 frees, 60,175 bytes allocated ==27227== ==27227== 55 (40 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 6 ==27227== at 0x4C2FB55: calloc (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==27227== by 0x470057: stgCallocBytes (RtsUtils.c:107) ==27227== by 0x4652C1: copyArgv (RtsFlags.c:1811) ==27227== by 0x465FAE: setProgArgv (RtsFlags.c:1877) ==27227== by 0x41CC4A: base_SystemziEnvironment_zdLr7BcsetProgArgv_info (in /home/smarlow/scratch/ArgvLeak) ==27227== ==27227== LEAK SUMMARY: ==27227== definitely lost: 40 bytes in 1 blocks ==27227== indirectly lost: 15 bytes in 4 blocks ==27227== possibly lost: 0 bytes in 0 blocks ==27227== still reachable: 52 bytes in 4 blocks ==27227== suppressed: 0 bytes in 0 blocks ==27227== Reachable blocks (those to which a pointer was found) are not shown. ==27227== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==27227== ==27227== For counts of detected and suppressed errors, rerun with: -v ==27227== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 11:13:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 11:13:16 -0000 Subject: [GHC] #12664: System.Environment.withArgs and friends leak memory In-Reply-To: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> References: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> Message-ID: <062.87975a636892848b1ef25491daa4a5ab@haskell.org> #12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 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 niteria): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 12:36:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 12:36:22 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.c049ff08820e68426879e394bbf28044@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by martinceresa): The second problem it is more tricky because the warning message for the deprecated flags is give to the 'EwM monad' with (correct me if I am wrong) the 'deprecate' function. So we need to delay this action until we know if we are in a "-Wno" situation,. We can add a new String argument to the wWarningFlagsDeps, and something like this: {{{#!hs wWarningFlagsDeps :: String -> [(Deprecation, FlagSpec WarningFlag)] ... depFlagSpec "missing-local-sigs" Opt_WarnMissingLocalSignatures "it is replaced by " ++ s ++ "missing-local-signatures" }}} And of course all the modifications implied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 12:49:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 12:49:06 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.bc21ab629c7656a19e851026820d7f1e@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The linker should mmap RW during linking and them remap RX when linking is complete. I think the new m32 allocator will make things a more difficult though, because it maintains partial pages of linked code, and we can't remap one of those pages from RX to RW since it might already be in use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 13:17:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 13:17:36 -0000 Subject: [GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 In-Reply-To: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> References: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> Message-ID: <059.ac7e11ea4a55acd911457511f053b4b4@haskell.org> #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 ---------------------------------------+------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------- Comment (by clint): On the buildds it is often a SIGABRT instead. I cannot reproduce it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 13:34:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 13:34:36 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.1ec898ee8fbad8b86e4a0ccd11bd3948@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by simonmar): If a `sync` fixes it then that would be a useful data point. If not, it means there are barriers missing elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 13:58:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 13:58:38 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.f22f2aaf2b1deeff7a7b9b9bebe811b3@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): With a very large `-A` like that you probably want to use nursery chunks: `-n4m`. It's also worth playing with `-qn`, e.g. on the 12x2 Haswell I suggest `-N24 -A128m -n4m -qn12` should work well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 15:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 15:18:51 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.11715ead906ac79f04e4ac31b36fa684@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Sorry for the confusion Simon, I had already fixed the problem by removing the pre-emptive CSE that I had added to the desugarer. This allows the simplifier to fully optimize the string operations and then common up any remaining literals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 15:36:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 15:36:50 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.5589020ab17e28b7e941f8e17a79f152@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, but it shoould work just as well if you ''do'' do pre-emptive CSE. If not, it exposes a fragility. Maybe we can find out why and fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 15:39:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 15:39:26 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.bf3461375ae9d102c22fcff370052f05@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 15:45:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 15:45:17 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.fb999278b153856b115bd08385112085@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Ah, I see your point now. In comment:24 you weren't necessarily suggesting that GHC '''should''' duplicate strings, just that in the example I posted, there's nothing to '''stop''' GHC from duplicating these strings because they're marked expandable. That does seem to be worth investigating then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 16:59:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 16:59:14 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.532f4ab2712f08a1a34771841eb01838@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The "expandable" thing means that it's ok to duplicate the let-bound thing if it makes a rule match. In this case it's the string-append rule -- and that rule is probably worth firing even if it does mean a bit of string duplication. (Of course it might also mean that the top-level binding ends up un-referenced in the end, so there's no duplication. But the worst-case is a bit of string duplication which is probably ok. I don't understand why that wasn't happening. And if it's not happening, maybe other similar Good Things are not happening, all unseen. So fixing this might fix other unreported bugs. Thanks for looking into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 17:59:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 17:59:15 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.3a10912379549bc13c5c84cd62f42236@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:25 simonmar]: > If a `sync` fixes it then that would be a useful data point. If not, it means there are barriers missing elsewhere. Using `sync` the situation improves a lot on my PowerMac G5 quad. `Setup build -j4` still segfaults randomly but only occasionally. With `lwsync` it almost always segfaulted. An improvement but not a fix. So I read the Power ISA specification again (especially Book II, Appendix B Programming Examples for Sharing Storage): It seems that even a `sync` on processor A is not sufficient to prevent reordering of loads on processor B. A load-load barrier is required when there is no data dependency between the two loads. I will look into that option over the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 18:24:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 18:24:32 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.0303aee8664edf12544a15ef23b0d177@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:11 simonpj]: > Question: why do we use pre-unification when matching the RHS > in the injectivity-improvement step. That's what is causing the > trouble. This all looks like reasonable behavior to me on a line-by-line basis. Obviously a loop is bad, but each step along the way is OK. We use pre-unification here because we want to match the pattern `Maybe (TF (x, a))` against `Maybe Char`. And indeed we should, because injectivity tells us that the equation `TF (D1 x, a) = Maybe (TF (x, a))` must be the one used to produce `Maybe Char`. (In fact, the solver should also generate `[W] TF (x, a) ~ Char`. Or maybe it should be Derived. Does it?) So I like the use of pre-unification here. What I find strange is that we're using the model when triggering improvement as we're looking at a Wanted. Doesn't the model (that is, all the Derived constraints) live off in its own world with minimal interaction with Wanteds? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 18:55:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 18:55:01 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast Message-ID: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At present, the `Read` instances for standard types are generally written ''as though'' `Read` were a typical parser for a programming language. However, it most assuredly is not. Specifically, we currently follow the pattern of lexing and then parsing. Lexing looks at the string and attempts to identify the next token, whatever it may be. But for `Read`, we don't need that. Thanks to the types, we have a very clear sense of what characters we expect to encounter. I've started to sketch out an improvement, which reads `Int` and `Word` around seven times as fast (9.5 times as fast with parentheses and negation), and will fail immediately on something like `read (fix ('a':)) :: Int` rather than going into an infinite loop. To begin with, modify the definition of `paren` thus: {{{#!hs expectP' :: Char -> ReadPrec () expectP' c = lift (expect c) {-# INLINE expectP' #-} paren :: ReadPrec a -> ReadPrec a -- ^ @(paren p)@ parses \"(P0)\" -- where @p@ parses \"P0\" in precedence context zero paren p = do expectP' '(' x <- reset p expectP' ')' return x }}} This allows fast failure when looking for parentheses, so we don't have to scan to the end of the first token (whatever it may be) before concluding that it is not `'('`. Now we can parse `Word` and `Int` very efficiently. I had to specialize earlier than I wanted to convince GHC that I don't want to convert through `Integer`. I'm not sure why the `fromIntegral` rule doesn't fire reliably around here. The code below (temporarily) uses the current definition for base 16, because that's a bit fussy; I'll rewrite it soon. {{{#!hs charDiff :: Char -> Char -> Word charDiff c1 c2 = fromIntegral (ord c1 - ord c2) {-# INLINE charDiff #-} readHexOct :: ReadP Word readHexOct = do _ <- ReadP.char '0' baseId <- lexBaseChar case baseId of Oct -> readBaseP 8 Hex -> L.readHexP {-# INLINE readHexOct #-} data BaseId = Oct | Hex lexBaseChar :: ReadP BaseId lexBaseChar = do { c <- ReadP.get; case c of 'o' -> pure Oct 'O' -> pure Oct 'x' -> pure Hex 'X' -> pure Hex _ -> ReadP.pfail } readWord :: ReadP Word readWord = readNumber (readHexOct ReadP.<++ readBaseP 10) readInt :: ReadP Int readInt = fromIntegral <$> readWord readBaseP :: Integral a => Word -> ReadP a readBaseP !base = do c <- ReadP.get let diff = charDiff c '0' if diff < base then readBaseP' base (fromIntegral diff) else ReadP.pfail {-# INLINE readBaseP #-} readBaseP' :: Integral a => Word -> a -> ReadP a readBaseP' !base !acc0 = ReadP.look >>= go acc0 where go !acc (c:cs) | diff < base = ReadP.get *> go (fromIntegral base * acc + fromIntegral diff) cs where diff = charDiff c '0' go !acc _ = pure acc {-# INLINE readBaseP' #-} readNumber :: Num a => ReadP.ReadP a -> ReadPrec a readNumber p = parens $ do cs <- lift skipSpaces *> look case cs of ('-': _) -> get *> lift (skipSpaces *> (negate <$> p)) _ -> lift $ skipSpaces *> p {-# INLINE readNumber #-} }}} Other `Word` and `Int`-like types can be built on top of that foundation. I haven't yet attempted to deal with other instances, but I think there are probably a lot of opportunities for similar improvements. WARNING: I know very little about parsing, and less about `ReadPrec`. It's conceivable that I've made some semantic errors here, although I don't think I have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:11:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:11:13 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.5cc20c8580d7ada1f928d8af18d18bc0@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -17,1 +17,1 @@ - expectP' c = lift (expect c) + expectP' c = lift (expect' c) @@ -19,0 +19,10 @@ + + expect' :: Char -> ReadP () + expect' c = do + ReadP.skipSpaces + thing <- ReadP.get + if thing == c + then pure () + else ReadP.pfail + {-# INLINE expect' #-} + New description: At present, the `Read` instances for standard types are generally written ''as though'' `Read` were a typical parser for a programming language. However, it most assuredly is not. Specifically, we currently follow the pattern of lexing and then parsing. Lexing looks at the string and attempts to identify the next token, whatever it may be. But for `Read`, we don't need that. Thanks to the types, we have a very clear sense of what characters we expect to encounter. I've started to sketch out an improvement, which reads `Int` and `Word` around seven times as fast (9.5 times as fast with parentheses and negation), and will fail immediately on something like `read (fix ('a':)) :: Int` rather than going into an infinite loop. To begin with, modify the definition of `paren` thus: {{{#!hs expectP' :: Char -> ReadPrec () expectP' c = lift (expect' c) {-# INLINE expectP' #-} expect' :: Char -> ReadP () expect' c = do ReadP.skipSpaces thing <- ReadP.get if thing == c then pure () else ReadP.pfail {-# INLINE expect' #-} paren :: ReadPrec a -> ReadPrec a -- ^ @(paren p)@ parses \"(P0)\" -- where @p@ parses \"P0\" in precedence context zero paren p = do expectP' '(' x <- reset p expectP' ')' return x }}} This allows fast failure when looking for parentheses, so we don't have to scan to the end of the first token (whatever it may be) before concluding that it is not `'('`. Now we can parse `Word` and `Int` very efficiently. I had to specialize earlier than I wanted to convince GHC that I don't want to convert through `Integer`. I'm not sure why the `fromIntegral` rule doesn't fire reliably around here. The code below (temporarily) uses the current definition for base 16, because that's a bit fussy; I'll rewrite it soon. {{{#!hs charDiff :: Char -> Char -> Word charDiff c1 c2 = fromIntegral (ord c1 - ord c2) {-# INLINE charDiff #-} readHexOct :: ReadP Word readHexOct = do _ <- ReadP.char '0' baseId <- lexBaseChar case baseId of Oct -> readBaseP 8 Hex -> L.readHexP {-# INLINE readHexOct #-} data BaseId = Oct | Hex lexBaseChar :: ReadP BaseId lexBaseChar = do { c <- ReadP.get; case c of 'o' -> pure Oct 'O' -> pure Oct 'x' -> pure Hex 'X' -> pure Hex _ -> ReadP.pfail } readWord :: ReadP Word readWord = readNumber (readHexOct ReadP.<++ readBaseP 10) readInt :: ReadP Int readInt = fromIntegral <$> readWord readBaseP :: Integral a => Word -> ReadP a readBaseP !base = do c <- ReadP.get let diff = charDiff c '0' if diff < base then readBaseP' base (fromIntegral diff) else ReadP.pfail {-# INLINE readBaseP #-} readBaseP' :: Integral a => Word -> a -> ReadP a readBaseP' !base !acc0 = ReadP.look >>= go acc0 where go !acc (c:cs) | diff < base = ReadP.get *> go (fromIntegral base * acc + fromIntegral diff) cs where diff = charDiff c '0' go !acc _ = pure acc {-# INLINE readBaseP' #-} readNumber :: Num a => ReadP.ReadP a -> ReadPrec a readNumber p = parens $ do cs <- lift skipSpaces *> look case cs of ('-': _) -> get *> lift (skipSpaces *> (negate <$> p)) _ -> lift $ skipSpaces *> p {-# INLINE readNumber #-} }}} Other `Word` and `Int`-like types can be built on top of that foundation. I haven't yet attempted to deal with other instances, but I think there are probably a lot of opportunities for similar improvements. WARNING: I know very little about parsing, and less about `ReadPrec`. It's conceivable that I've made some semantic errors here, although I don't think I have. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:13:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:13:24 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.1e5e321275bb4eeec1e467fc698fb097@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:24:18 -0000 Subject: [GHC] #12666: ApplicativeDo fails to sequence actions Message-ID: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> #12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following, {{{#!hs {-# LANGUAGE ApplicativeDo #-} module Fail where data P a = P instance Functor (P) where fmap _ P = P instance Applicative (P) where P <*> P = P pure _ = P action :: P Int action = P works :: P (Int, Int) works = do a <- action b <- action return (a,b) thisWorks :: P Int thisWorks = action *> action -- It seems like this should be equivalent to thisWorks. shouldThisWork :: P Int shouldThisWork = do action action }}} It seems to me that `thisWorks` and `shouldThisWork` are equivalent, yet the latter fails to typecheck. It seems that `ApplicativeDo` fails to catch this the fact that the result of the first `action` is unbound and therefore can be sequenced with `*>`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:36:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:36:53 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.950cca1ab7a0b07274e2a1f7b972f732@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): So I don't forget: when we improve `Read Integer` and `Read Natural`, we probably want to make the radix-doubling thing start out coarser. I think we basically want to start with base `10^19` for decimal, etc., so that we work with chunks that fit in a `Word`. Essentially, start by parsing to a list of `Word`s, each of which represents a base-`10^19` digit, and then apply an appropriate algorithm to combine these all into an `Integer` or `Natural`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:43:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:43:55 -0000 Subject: [GHC] #12667: Compiling haskell-stack crashes the compiler Message-ID: <044.67cdd6ce3acc15d08607a87f53e4f40c@haskell.org> #12667: Compiling haskell-stack crashes the compiler -------------------------------------+------------------------------------- Reporter: hudon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When upgrading haskell-stack using brew, I get: {{{ ==> Upgrading haskell-stack ==> Downloading https://github.com/commercialhaskell/stack/releases/download/v1.1.2/stack-1.1.2-sdist-2.tar.gz Already downloaded: /Users/hudon/Library/Caches/Homebrew/haskell- stack-1.1.2.tar.gz ==> cabal sandbox init ==> cabal update ==> cabal install --jobs=8 --max-backjumps=100000 Last 15 lines from /Users/hudon/Library/Logs/Homebrew/haskell- stack/03.cabal: [ 1 of 87] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/dist- sandbox-7d57129e/build/Stack/FileWatch.o ) [ 2 of 87] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/dist-sandbox- 7d57129e/build/System/Process/PagerEditor.o ) [ 3 of 87] Compiling System.Process.Log ( src/System/Process/Log.hs, dist /dist-sandbox-7d57129e/build/System/Process/Log.o ) [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-7d57129e/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/lc/jm4g8s190gl8977h7tz9j6tc0000gn/T/ghc18925_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/lc/jm4g8s190gl8977h7tz9j6tc0000gn/T/ghc18925_0/libghc_44.dylib: malformed mach-o: load commands size (40304) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 19:47:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 19:47:54 -0000 Subject: [GHC] #12667: Compiling haskell-stack crashes the compiler In-Reply-To: <044.67cdd6ce3acc15d08607a87f53e4f40c@haskell.org> References: <044.67cdd6ce3acc15d08607a87f53e4f40c@haskell.org> Message-ID: <059.c3869ff26d5f069547964676006c6191@haskell.org> #12667: Compiling haskell-stack crashes the compiler -------------------------------------+------------------------------------- Reporter: hudon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: See #12479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 20:15:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 20:15:40 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.16e67661e0c0589c92cf13e4ec450edd@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -4,8 +4,13 @@ - pattern of lexing and then parsing. Lexing looks at the string and - attempts to identify the next token, whatever it may be. But for `Read`, - we don't need that. Thanks to the types, we have a very clear sense of - what characters we expect to encounter. I've started to sketch out an - improvement, which reads `Int` and `Word` around seven times as fast (9.5 - times as fast with parentheses and negation), and will fail immediately on - something like `read (fix ('a':)) :: Int` rather than going into an - infinite loop. + pattern of lexing and then parsing. The first problem with that is that + while we follow that model, we don't actually get the big benefit of that + model; the class methods don't mention or respect token boundaries, so + lexing first doesn't prevent backtracking. More to the point, perhaps, + lexing looks at the string and attempts to identify the next token, + whatever it may be. But for `Read`, we don't need that. Thanks to the + types, we have a very clear sense of what characters we expect to + encounter. + + I've started to sketch out an improvement, which reads `Int` and `Word` + around seven times as fast (9.5 times as fast with parentheses and + negation), and will fail immediately on something like `read (fix ('a':)) + :: Int` rather than going into an infinite loop. New description: At present, the `Read` instances for standard types are generally written ''as though'' `Read` were a typical parser for a programming language. However, it most assuredly is not. Specifically, we currently follow the pattern of lexing and then parsing. The first problem with that is that while we follow that model, we don't actually get the big benefit of that model; the class methods don't mention or respect token boundaries, so lexing first doesn't prevent backtracking. More to the point, perhaps, lexing looks at the string and attempts to identify the next token, whatever it may be. But for `Read`, we don't need that. Thanks to the types, we have a very clear sense of what characters we expect to encounter. I've started to sketch out an improvement, which reads `Int` and `Word` around seven times as fast (9.5 times as fast with parentheses and negation), and will fail immediately on something like `read (fix ('a':)) :: Int` rather than going into an infinite loop. To begin with, modify the definition of `paren` thus: {{{#!hs expectP' :: Char -> ReadPrec () expectP' c = lift (expect' c) {-# INLINE expectP' #-} expect' :: Char -> ReadP () expect' c = do ReadP.skipSpaces thing <- ReadP.get if thing == c then pure () else ReadP.pfail {-# INLINE expect' #-} paren :: ReadPrec a -> ReadPrec a -- ^ @(paren p)@ parses \"(P0)\" -- where @p@ parses \"P0\" in precedence context zero paren p = do expectP' '(' x <- reset p expectP' ')' return x }}} This allows fast failure when looking for parentheses, so we don't have to scan to the end of the first token (whatever it may be) before concluding that it is not `'('`. Now we can parse `Word` and `Int` very efficiently. I had to specialize earlier than I wanted to convince GHC that I don't want to convert through `Integer`. I'm not sure why the `fromIntegral` rule doesn't fire reliably around here. The code below (temporarily) uses the current definition for base 16, because that's a bit fussy; I'll rewrite it soon. {{{#!hs charDiff :: Char -> Char -> Word charDiff c1 c2 = fromIntegral (ord c1 - ord c2) {-# INLINE charDiff #-} readHexOct :: ReadP Word readHexOct = do _ <- ReadP.char '0' baseId <- lexBaseChar case baseId of Oct -> readBaseP 8 Hex -> L.readHexP {-# INLINE readHexOct #-} data BaseId = Oct | Hex lexBaseChar :: ReadP BaseId lexBaseChar = do { c <- ReadP.get; case c of 'o' -> pure Oct 'O' -> pure Oct 'x' -> pure Hex 'X' -> pure Hex _ -> ReadP.pfail } readWord :: ReadP Word readWord = readNumber (readHexOct ReadP.<++ readBaseP 10) readInt :: ReadP Int readInt = fromIntegral <$> readWord readBaseP :: Integral a => Word -> ReadP a readBaseP !base = do c <- ReadP.get let diff = charDiff c '0' if diff < base then readBaseP' base (fromIntegral diff) else ReadP.pfail {-# INLINE readBaseP #-} readBaseP' :: Integral a => Word -> a -> ReadP a readBaseP' !base !acc0 = ReadP.look >>= go acc0 where go !acc (c:cs) | diff < base = ReadP.get *> go (fromIntegral base * acc + fromIntegral diff) cs where diff = charDiff c '0' go !acc _ = pure acc {-# INLINE readBaseP' #-} readNumber :: Num a => ReadP.ReadP a -> ReadPrec a readNumber p = parens $ do cs <- lift skipSpaces *> look case cs of ('-': _) -> get *> lift (skipSpaces *> (negate <$> p)) _ -> lift $ skipSpaces *> p {-# INLINE readNumber #-} }}} Other `Word` and `Int`-like types can be built on top of that foundation. I haven't yet attempted to deal with other instances, but I think there are probably a lot of opportunities for similar improvements. WARNING: I know very little about parsing, and less about `ReadPrec`. It's conceivable that I've made some semantic errors here, although I don't think I have. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 20:33:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 20:33:13 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.7f98fee16b51f94823910d0231dce72f@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ah ok, the first version (the one on the diff) spawns only 9 threads the one here 88 threads. In any case I'll add some more debugging info to the build and send a new one. Also how are you measuring this, just using task manager? When I was testing this I noticed task manager wasn't cpu group aware (at least for my test setup). Only resource monitor and Windows performance analyzer were able to give me accurate information. I assume the system is a production system which doesn't have Windows Performance analyzer? That would give an accurate view of what each thread is doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 20:34:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 20:34:18 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.05da9f6a8f14d1922ee5da62bf4a5cf3@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => * status: closed => new * resolution: fixed => Comment: The dump you've pasted does show that all 88 capabilities are assigned. Which is why I'm a bit confused. But I'll take a look none the less. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 20:41:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 20:41:31 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.31f23e95f6d1ddadc70dde7bff138083@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The code I gave does have a bug. If a string can be parsed as a fractional value, it seems it's not supposed to produce any results for integral types. I think we can fix this when we get to the end of the digits by looking ahead for `.` or `e` followed by a digit, and failing if we see one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:01:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:01:09 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.4655f4ea829aec7d9e71774e9777cbc2@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"465c6c5d15f8fb54afb78408f3a79e75e74d2cd4/ghc" 465c6c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="465c6c5d15f8fb54afb78408f3a79e75e74d2cd4" Improve error handling in TcRnMonad See Note [Constraints and errors] in TcRnMonad. This patch fixes Trac #12124 in quite a neat way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:03:57 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.2ff299cc5410df57198f3aa2d61af209@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12124 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T12124 Comment: All fixed. I'm not sure if it's worth pushing to 8.0.2, but I think it'd be safe to do so. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:05:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:05:44 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.d7a95c17ecd86988d86e1ac35c7ad5e0@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Let me take that back; I think my modified implementation actually does what Haskell98 says, whereas the current implementation does something else. I don't know for sure what should be considered the correct behavior. P.S., to match the current behavior, we'd need to accept `"122e-"` as an integer, but not `"122e-3"`, because the current implementation lexes `"122e-3"` as a fractional number and thus not an integer, whereas it lexes `"122e-"` as an integer followed by an identifier followed by a symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:07:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:07:50 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.47e948b26429bdbb3e962263e485d29a@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): The following is a lazier variant of `valInteger` that does a chunking pass on `Int`s. (Resulting from discussion on #haskell) {{{ -- Digits' represents a stream of digits where the last digit carries its own -- base. For example, in base 100, we could represent 12345 as either one of -- DCons 12 (DCons 34 (DNil 5 10)) or -- DCons 1 (DCons 23 (DCons 45 (DNil 0 1))) data Digits' = DCons !Integer Digits' | DNil !Integer Integer valInteger :: Int -> [Int] -> Integer valInteger _ [] = 0 valInteger b ds = go b1 (chunks 0 0 ds) where -- chunking pass: collect digits in base b^chunkSize chunkSize :: Int chunkSize = 7 -- b^chunkSize must fit into an Int b1 :: Integer b1 = fromIntegral (b^chunkSize) chunks :: Int -> Int -> [Int] -> Digits' chunks l d ds | l == chunkSize = DCons (fromIntegral d) (chunks 0 0 ds) chunks l d [] = DNil (fromIntegral d) (fromIntegral (b^l)) chunks l d (d' : ds) = chunks (l+1) (d*b + d') ds -- bottom-up combination pass, squaring the base in each pass go :: Integer -> Digits' -> Integer go _ (DNil d _) = d go _ (DCons d' (DNil d b)) = d'*b + d go b (DCons d' ds) = go (b*b) (combine b d' ds) combine :: Integer -> Integer -> Digits' -> Digits' combine b d (DNil d' b') = DNil (d*b' + d') (b * b') combine b d (DCons d' (ds at DNil{})) = DCons (d*b + d') ds combine b d (DCons d' (DCons d'' ds)) = DCons (d*b + d') (combine b d'' ds) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:12:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:12:45 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.412df0fe8401d169a3d98d960833ebcd@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 int-e]: > `chunkSize = 7 -- b^chunkSize must fit into an Int` Surely we should set the chunk size based on the actual word size, rather than assuming every machine is 32-bit or whatever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:22:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:22:52 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.61fbde301ce50623fc2e240e82d3c54f@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:8 dfeuer]: > Replying to [comment:7 int-e]: > > `chunkSize = 7 -- b^chunkSize must fit into an Int` > > Surely we should set the chunk size based on the actual word size, rather than assuming every machine is 32-bit or whatever. Yes, I intended to leave this as an exercise to the reader though, and instead focussed on streamlining the interesting bits of the algorithm. (In principle the chunk size could depend on the base as well, but only some serious benchmarking effort will show whether that is worthwhile.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:48:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:48:26 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.16e9225f3e49278a063987f204e5bfb3@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've re-read our Haskell Symposium '15 paper "Injective type families". It's rather good! Section 5.2 covers exactly the point at issue here. * You point out above that we can really also produce `[D] Char ~ TF (x_fresh2, a_fresh1)`. Very true! WE don't currently do that. Moreover, this idea is missing from Section 5.2 in the paper. In the example here we should add `[D] G beta ~ Int`, shouldn't we? Doing so could lead to more progress. Would you like to cook up an example that will only work if we do this? * How to avoid the loop? Well we basically emit `[D] (x_aDY, a_aJn) ~ (D x_fresh2, a_fresh1)`. When we boil this down to `a_aJn ~ a_fresh1` we really really want to unify `a_fresh1 := a_aJn`. If we do it the other way round we get the infinite loop. Or to put it another way, we don't want to invent more fresh variables than we need to. In this case, let's no invent `a_fresh1` at all; just re-use `a_aJn`. You might think of it as an optimisation, but acutally it's essential to avoid the loop. > What I find strange is that we're using the model when triggering improvement as we're looking at a Wanted. Doesn't the model (that is, all the Derived constraints) live off in its own world with minimal interaction with Wanteds? Every Wanted effectively has a "shadow Derived" behind it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 21:49:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 21:49:41 -0000 Subject: [GHC] #12666: ApplicativeDo fails to sequence actions In-Reply-To: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> References: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> Message-ID: <061.8539b09f90b4674eb246add62ed1e289@haskell.org> #12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 22:03:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 22:03:05 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.90b06b077e7685bf9acc895386c3e507@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Any thunk of type `Sink` never gets updated. That's extremely dodgy isn't it? What about {{{ let s1 :: Sink = ... s2 :: Sink = ... x :: Sink = if then s1 else s2 }}} If `x` is not updated, but is evaluated more than once, we'll evaluate `` more than once. Perhaps you mean something more like this: {{{ data Sink = Await (Maybe Char -o Sink) | Done Int }}} Notice the "`-o`", meaning a "one-shot function". The idea is that one- shot functions are called at most once. (Maybe exactly once, but I think at-most once is better.) So in your `countFrom` example, the continuation `k` would not be floated outside the lambda; and if it was written outside it'd be floated inside the lambda. GHC already has the notion of a one-shot lambda; it's just not dignified as part of the type system. Would that serve? I think that you do intend that the argujment of `Await` is called at most once, don't you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 5 22:13:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 05 Oct 2016 22:13:45 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.778a9a55d11621ae7944b09b9eabe45b@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 simonpj): Trying to reproduce this. But when I try `cabal install singletons` (with the HEAD ghc) I get {{{ [3 of 8] Compiling Language.Haskell.TH.Desugar.Core ( Language\Haskell\TH\Desugar\Core.hs, dist\build\Language\Haskell\TH\Desugar\Core.o ) Language\Haskell\TH\Desugar\Core.hs:713:21: error: Ambiguous occurrence Newtype It could refer to either Language.Haskell.TH.Syntax.Newtype , imported from Language.Haskell.TH.Syntax at Language\Haskell\TH\Desugar\Core.hs:18:1-47 or Language.Haskell.TH.Desugar.Core.Newtype , defined at Language\Haskell\TH\Desugar\Core.hs:108:18 Language\Haskell\TH\Desugar\Core.hs:764:25: error: Ambiguous occurrence Newtype It could refer to either Language.Haskell.TH.Syntax.Newtype , imported from Language.Haskell.TH.Syntax at Language\Haskell\TH\Desugar\Core.hs:18:1-47 or Language.Haskell.TH.Desugar.Core.Newtype , defined at Language\Haskell\TH\Desugar\Core.hs:108:18 }}} What am I doing wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 00:23:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 00:23:09 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.fb87eb4f45fafb9ae9dee9292a8f172b@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Replying to [comment:25 simonpj]: > > Any thunk of type `Sink` never gets updated. > Notice the "`-o`", meaning a "one-shot function". The idea is that one- shot functions are called at most once. (Maybe exactly once, but I think at-most once is better.) > > So in your `countFrom` example, the continuation `k` would not be floated outside the lambda; and if it was written outside it'd be floated inside the lambda. > > GHC already has the notion of a one-shot lambda; it's just not dignified as part of the type system. > > Would that serve? I think that you do intend that the argujment of `Await` is called at most once, don't you? Typically, yes, but not necessarily. After all, in the minimal example above, ''if'' the exception handler gets executed then the whole process starts over. Ideally it would start over with a newly constructed conduit, but if we cannot prevent sharing, it would start over with the same conduit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 00:54:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 00:54:43 -0000 Subject: [GHC] #12666: ApplicativeDo fails to sequence actions In-Reply-To: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> References: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> Message-ID: <061.2da589eb61c8fa3c933c6067f112555a@haskell.org> #12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -37,1 +37,1 @@ - catch this the fact that the result of the first `action` is unbound and + catch the fact that the result of the first `action` is not bound and New description: Consider the following, {{{#!hs {-# LANGUAGE ApplicativeDo #-} module Fail where data P a = P instance Functor (P) where fmap _ P = P instance Applicative (P) where P <*> P = P pure _ = P action :: P Int action = P works :: P (Int, Int) works = do a <- action b <- action return (a,b) thisWorks :: P Int thisWorks = action *> action -- It seems like this should be equivalent to thisWorks. shouldThisWork :: P Int shouldThisWork = do action action }}} It seems to me that `thisWorks` and `shouldThisWork` are equivalent, yet the latter fails to typecheck. It seems that `ApplicativeDo` fails to catch the fact that the result of the first `action` is not bound and therefore can be sequenced with `*>`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 01:18:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 01:18:23 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.5a763b6ceecda4677d11afe4d3828ddb@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: I haven't encountered it before but: File not Found will also be returned by the system loader when it couldn't find a dependency of a library it's trying to load. In this case I suspect you've set up the buildbot on a completely new Windows install. In which case you're probably missing the proper Microsoft C Runtime. (Windows update would eventually get to this). According to the docs : https://docs.python.org/3.4/using/windows.html Python 3.5 has a dependency on the VC2015 runtime https://www.microsoft.com/en-us/download/details.aspx?id=48145 and Python 3.4 on the VC2008 runtime https://www.microsoft.com/en- us/download/details.aspx?id=15336 The load is probably failing because ctypes loads a dll that needs the runtime. It should have recorded the missing dependency in the Windows Event Viewer as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 01:34:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 01:34:23 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.6dd0ed6e833be6ac13a822a8a9dde44a@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): I take your point re `` though. After it, it's common enough to have something like {{{#!hs x <- someConduit if then thisConduit else thatConduit }}} However, I still think we need something more compositional than `oneShot`. As michaelt_ points out on Reddit, {{{#!hs module Main (main) where import GHC.Magic data Sink = Await (Maybe Char -> Sink) | Done Int countFrom :: Int -> Sink countFrom n = let k = countFrom $! n + 1 in Await $ oneShot $ \mi -> case mi of Nothing -> Done n Just _ -> k feedFrom :: Int -> Sink -> IO () feedFrom _ (Done n) = print n feedFrom 0 (Await f) = feedFrom 0 (case f $ Nothing of a -> a) feedFrom n (Await f) = feedFrom (n - 1) (case f $ Just 'A' of a -> a) main :: IO () main = let a = feedFrom 10000000 (countFrom 0) in a >> a }}} doesn't have a space leak. If `oneShot` was compositional, that would be awesome; we could put the `oneShot` in the library and then forget about it. Sadly, though perhaps not unexpectedly, this variation _does_ have a space leak again: {{{#!hs module Main (main) where import GHC.Magic data Sink = Await (Maybe Char -> Sink) | Done Int await :: (Maybe Char -> Sink) -> Sink {-# NOINLINE await #-} await f = Await (oneShot f) countFrom :: Int -> Sink countFrom n = let k = countFrom $! n + 1 in await $ \mi -> case mi of Nothing -> Done n Just _ -> k feedFrom :: Int -> Sink -> IO () feedFrom _ (Done n) = print n feedFrom 0 (Await f) = feedFrom 0 (case f $ Nothing of a -> a) feedFrom n (Await f) = feedFrom (n - 1) (case f $ Just 'A' of a -> a) main :: IO () main = let a = feedFrom 10000000 (countFrom 0) in a >> a }}} Insisting that users write {{{#!hs await >>= oneShot (\mi -> ...) }}} instead of {{{#!hs do mi <- await ; ... }}} doesn't seem like a good solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 02:09:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 02:09:24 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.84262da6830d0813bc34a833bb38d91c@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:13 simonpj]: > I've re-read our Haskell Symposium '15 paper "Injective type families". It's rather good! Glad you like it. :) > Section 5.2 covers exactly the point at issue here. > > * You point out above that we can really also produce `[D] Char ~ TF (x_fresh2, a_fresh1)`. Very true! WE don't currently do that. But I wonder if we need to. The existing machinery for dealing with type functions should add that equality in short order once we do the partial improvement. Perhaps that's why we left this out of the paper. > * How to avoid the loop? Well we basically emit `[D] (x_aDY, a_aJn) ~ (D x_fresh2, a_fresh1)`. When we boil this down to `a_aJn ~ a_fresh1` we really really want to unify `a_fresh1 := a_aJn`. If we do it the other way round we get the infinite loop. > > Or to put it another way, we don't want to invent more fresh variables than we need to. In this case, let's no invent `a_fresh1` at all; just re-use `a_aJn`. You might think of it as an optimisation, but acutally it's essential to avoid the loop. I trust your judgment here, but it all looks rather fragile. What termination property does setting `a_aJn := a_fresh1` violate? Or, said differently, ''why'' does this fix the problem. You might say "you won't kick out the `FunEqCan`" and you'd be right, but that doesn't seem like a fundamental enough reason. But perhaps this is a battle for another day. > > > What I find strange is that we're using the model when triggering improvement as we're looking at a Wanted. Doesn't the model (that is, all the Derived constraints) live off in its own world with minimal interaction with Wanteds? > > Every Wanted effectively has a "shadow Derived" behind it. Yes, I suppose I knew that. But I thought these Deriveds only come into play when working with other Deriveds. Put another way: should we try improvement only when working with Deriveds? Given your statement above about shadow Deriveds, my new plan would seem to cover all cases where we try improvement now, but we would seemingly be saved from this loop. Am I missing anything? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 02:14:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 02:14:22 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.afa4781c849a682bb446e831a7afa051@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 goldfire): Note that the problem does not exist in HEAD -- the problem is in the 8.0 branch. But to get singletons to work with HEAD, you'll need the HEAD of `th- desugar`, from github.com/goldfirere/th-desugar. Clone from there and install; singletons should install on top of that without trouble (I think). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 06:58:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 06:58:14 -0000 Subject: [GHC] #12666: ApplicativeDo fails to sequence actions In-Reply-To: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> References: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> Message-ID: <061.2b81e04577388f689ea012ea4c8ef492@haskell.org> #12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | 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 simonmar): * status: new => closed * resolution: => duplicate Comment: I'm going to merge this into #10892 because it's basically the same thing - we don't handle `ExprStmt` in `ApplicativeDo` right now. I was a bit lazy and skipped this when I implemented `ApplicativeDo` because I didn't need it, sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 06:59:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 06:59:14 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.fd64afbe628ebd28b2c7ed83a2d1258d@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): See #12666 for another request with an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 07:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 07:02:40 -0000 Subject: [GHC] #12666: ApplicativeDo fails to sequence actions In-Reply-To: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> References: <046.bf07186993cfd1584f83e7ff7253ad2c@haskell.org> Message-ID: <061.8f2228a9cbf56df265c085cd70d5e73f@haskell.org> #12666: ApplicativeDo fails to sequence actions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | 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 simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 07:03:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 07:03:22 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.1c9fb04f693b628b2761462bad7e6150@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 07:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 07:45:00 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.235f55db53139dcb01d52d876b5bb5ea@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gidyn): Would it be possible for `-j` to select more suitable GC parameters by default, for the benefit of those who aren't experts at parallel GC tuning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 09:11:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 09:11:52 -0000 Subject: [GHC] #12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] In-Reply-To: <044.523b434f5130bcce5d2e71f45a4abdd5@haskell.org> References: <044.523b434f5130bcce5d2e71f45a4abdd5@haskell.org> Message-ID: <059.5ff0e66046e5c0393098dcfa5ec2cf52@haskell.org> #12130: ghc: panic! (the 'impossible' happened): find_tycon Block [] -------------------------------------+------------------------------------- Reporter: jeiea | Owner: adamgundry Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: | DisambiguateRecordFields Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12130 Blocked By: | Blocking: Related Tickets: #11228 | Differential Rev(s): Phab:D2321 Wiki Page: | -------------------------------------+------------------------------------- Comment (by spl): For others who happen upon this problem with GHC 8.0.1, I've used the following workaround. In each module where the error occurs, add ```{-# LANGUAGE NoDisambiguateRecordFields NoRecordWildCards #-}``` and remove all uses of disambiguated fields and record wildcards from that module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 09:18:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 09:18:22 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.99b06b1814f0ab3407bc6363e7df325d@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): But perhaps I misunderstood: yes, marking the ''function type'' as "oneshot" `Maybe Char -o Sink` would also do the trick. Although I'm not a fan of calling this "oneshot", or indeed the `-o` notation (borrowed from linearity). The whole point is that these functions _might_ be executed more than once; after all, if we were guaranteed that that wouldn't happen, we wouldn't be hanging on to them and there would be no memory leak. But marking that function as "noupdate" or whatever would seem to make sense; of course, now we can ask the same question as you asked above: what about {{{#!hs foo :: Maybe Char -> Sink {-# NOUPDATE foo #-} foo = if then f1 else f2 }}} but I guess this is far less likely to be a problem in practice; how often do we write something like {{{#!hs await >>= if then f1 else f2 }}} I think almost never; this is far more likely {{{#!hs await >>= \mi -> if then c1 else c2 }}} and that would be just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 11:11:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 11:11:49 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.e5b1c95644f812bbb06089d0e12a300a@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Task manager on Windows 10 shows NUMA nodes and logical cores separated. So both NUMA nodes are taken by 85-88%. On logical cores, there about 10 from 88 cores not used for some reason. They are near zero CPU usage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 11:12:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 11:12:57 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.6085407e41f029eab0f103dfe8985429@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Is it possible "-qa" option to be reversed, i.e. by default it to use all NUMA nodes and if someone wants for some special case to disable it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 13:09:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 13:09:03 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.c740d77e757e8e9d06da8f98f8ac052d@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michaelt): * Attachment "awaithack.hs" added. use `oneShot` and a rule for await to fight 'full laziness' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 13:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 13:13:30 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.a48ecb2f95f6d31edb5d40273fb90a25@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michaelt): If I add a monad instance, then I can give the customary definition `await = Await Done`. If I delay inlining, then the standard use of `await` works fine in the presence of this rule {{{ {-# RULES "await hack" forall f . await >>= f = Await (oneShot f) #-} }}} In a library for your `Sink` type, this would I think get rid of the problem. See the attached https://ghc.haskell.org/trac/ghc/attachment/ticket/12620/awaithack.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 13:36:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 13:36:22 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.51756d9890d86498344d3d94afe558a6@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michaelt): This hack seems to work fine, by the way, if I separate out the general material as a 'library', and then define the counting and feeding function in a separate 'user' module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 15:58:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 15:58:53 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.3c530b11ec6f441c1617792119777585@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): > In this case I suspect you've set up the buildbot on a completely new Windows install. In which case you're probably missing the proper Microsoft C Runtime. (Windows update would eventually get to this). Indeed you are right, this is a clean installation. Unfortunately the problem seems to persist after installing the VC2008 runtime (both 32- and 64-bit for good measure). Moreover, there is no sign of any relevant events in Event Viewer. Sadly my usual `strace` approach seems powerless on Windows: I can see an `open` system call for `ctypes/__init__.py` but nothing else interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 16:10:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 16:10:59 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.9bdd099d98898d323ffc17bfd3e8704a@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by Phyx-): * cc: Phyx (removed) * cc: Phyx- (added) * owner: Phyx- => Comment: Whoops, meant to correct the CC not assign it to myself. With 3.4 installed your python 3.4 example should work, can you try the repl again with the python 3.4? The 2.7 the testsuite is automatically detecting is a big more vague as it support multiple compilers https://docs.python.org/2.7/using/windows.html Typically on Windows the easiest way to debug such issues is using glfags https://msdn.microsoft.com/en- us/library/windows/hardware/ff549557(v=vs.85).aspx which has an option to "enable loader snaps" This will tell the kernel to display loader debug messages *only* when the process given is running in a debugger. But now that you have the VC2008 runtime try the 3.4 repl (unless that's the one you said still doesn't work?) I'll check the dependency chain when I get home. Usually the python installer takes care of all of this, but I guess because python was installed via pacman it can't pull in the MSVCRT dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 16:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 16:41:32 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.6958f2c5eaf38ceb70dc8112804ea525@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:25 simonmar]: > If a `sync` fixes it then that would be a useful data point. If not, it means there are barriers missing elsewhere. I had not seen your comment on moving the write barrier. If that was indeed the problem then there is a data dependency and we don't have to worry about a load-load barrier on PowerPC (and ARM). I'll do a test build on a PowerPC 970MP and a POWER8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 16:49:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 16:49:43 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly Message-ID: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking for a testcase for another unrelated compiler bug (see Phab:D2577) I had the pleasure of encountering this specimen, {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data Some r = Some (TYPE r -> TYPE r) doSomething :: forall (r :: RuntimeRep). forall (a :: TYPE r). () => Int -> (a -> Int) -> a -> a doSomething n f = case n of 1 -> error "hello" 3 -> error "hello" }}} GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 seems to let this program typecheck, but if you enable Core Lint it soon becomes clear that not all is well. Here's a sampling of the carnage, {{{ $ ghc hi.hs -fforce-recomp -dcore-lint -O0 [1 of 1] Compiling Hi ( hi.hs, hi.o ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the type ‘a_a2ON -> Int’ Ill-kinded argument in type or kind ‘a_a2ON -> Int’ type or kind ‘a_a2ON -> Int’ kind: TYPE r_a2OM : warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM : warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM : warning: In the expression: patError @ 'PtrRepLifted @ (a_a2ON -> a_a2ON) "hi.hs:(12,5)-(14,24)|case"# Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 16:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 16:50:31 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.d766af7bb724645f90bcec13df6cc2e9@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -21,3 +21,3 @@ - GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 seems to let this program - typecheck, but if you enable Core Lint it soon becomes clear that not all - is well. Here's a sampling of the carnage, + GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 and 8.0.1 seem to let this + program typecheck, but if you enable Core Lint it soon becomes clear that + not all is well. Here's a sampling of the carnage, New description: While looking for a testcase for another unrelated compiler bug (see Phab:D2577) I had the pleasure of encountering this specimen, {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data Some r = Some (TYPE r -> TYPE r) doSomething :: forall (r :: RuntimeRep). forall (a :: TYPE r). () => Int -> (a -> Int) -> a -> a doSomething n f = case n of 1 -> error "hello" 3 -> error "hello" }}} GHC 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 and 8.0.1 seem to let this program typecheck, but if you enable Core Lint it soon becomes clear that not all is well. Here's a sampling of the carnage, {{{ $ ghc hi.hs -fforce-recomp -dcore-lint -O0 [1 of 1] Compiling Hi ( hi.hs, hi.o ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the type ‘a_a2ON -> Int’ Ill-kinded argument in type or kind ‘a_a2ON -> Int’ type or kind ‘a_a2ON -> Int’ kind: TYPE r_a2OM : warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM : warning: In the type ‘a_a2ON -> a_a2ON’ Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM : warning: In the expression: patError @ 'PtrRepLifted @ (a_a2ON -> a_a2ON) "hi.hs:(12,5)-(14,24)|case"# Ill-kinded argument in type or kind ‘a_a2ON -> a_a2ON’ type or kind ‘a_a2ON -> a_a2ON’ kind: TYPE r_a2OM ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 17:12:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 17:12:28 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.00d75ac250c6a7f480039d8761615bcf@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 goldfire): What's wrong here? My first worry is that Core Lint is doing the wrong thing. And does your `Some` type enter the picture? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 17:32:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 17:32:17 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.e08d47beecb51ca0878846f63b9ffae5@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 bgamari): > What's wrong here? My first worry is that Core Lint is doing the wrong thing. I'm afraid I didn't look much farther; I was hoping I'd be able to quickly get the `typeable` branch rebased between builds on another project; sadly the yaks just keep piling up. > And does your Some type enter the picture? Indeed I suspect it doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 17:46:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 17:46:26 -0000 Subject: [GHC] #12669: Add some weird Kmettian tests to the test suite Message-ID: <045.51265cdb375454bf32c5460f73599b17@haskell.org> #12669: Add some weird Kmettian tests to the test suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `reflection` does some funny business essentially coercing between `->` and `=>`. `constraints` has some code that's very sensitive to superclass cycle detection. And there's some other package (`structures`?) that coerces between `*` and `#` to stick raw `MutArr#` pointers into arrays. I believe Kmett also uses `unsafeCoerce# reallyUnsafePtrEquality#` to compare pointers of kind `#` to others (of possibly different types). None of these things are anything like officially supported. However, breaking them could be expensive for the ecosystem. Dealing with breakage when someone discovers it months later can be very hard, so I think some of these things should probably be added to the GHC test suite. Failures shouldn't categorically prevent changes from being merged, but they would provide an early warning and get conversations started earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 17:47:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 17:47:51 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.3026dd4a201089fa46a2f6771ec6b26f@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Indeed 3.4.3 is the failing python version, {{{ $ strace -o log python Python 3.4.3 (default, Mar 4 2016, 10:23:36) [GCC 4.9.2] on msys Type "help", "copyright", "credits" or "license" for more information. p>>> import ctypes >>> ctypes.cdll.kernel32 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/ctypes/__init__.py", line 421, in __getattr__ dll = self._dlltype(name) File "/usr/lib/python3.4/ctypes/__init__.py", line 351, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:14:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:14:19 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict Message-ID: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4 GHC rejects this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} module Hi where import GHC.Exts data TypeRep (a :: k) where TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) }}} Claiming that it has inappropriate polymorphism over `RuntimeRep`, {{{ $ ghc hi2.hs [1 of 1] Compiling Hi ( hi2.hs, hi2.o ) hi2.hs:7:5: error: • A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r1 • In the definition of data constructor ‘TrFun’ In the data type declaration for ‘TypeRep’ }}} I suspect this check is unnecessarily strict since we never need to store a value of type `a` to represent `TypeRep a` at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:21:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:21:56 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.35e6cc19a7a45a45af7dbe5c1e069d58@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): @ezyang I have switched over to stack, and I'm still having this issue. My libraries are not installed in the global package index, but when I try to use GHCi (`stack exec ghci -- path/to/my/lib`), I get these errors. If you don't think this is a issue with GHC, please let me know where I should report it. Otherwise, I'd say that this issue affects multiple tools, and should be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:29:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:29:25 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.03df52966df2cf6792f9e08f5cdcc23b@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): What are the steps to reproduce using STack? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:30:39 -0000 Subject: [GHC] #12669: Add some weird Kmettian tests to the test suite In-Reply-To: <045.51265cdb375454bf32c5460f73599b17@haskell.org> References: <045.51265cdb375454bf32c5460f73599b17@haskell.org> Message-ID: <060.5f0ece2da1ff9d625d2ea9eee16455b0@haskell.org> #12669: Add some weird Kmettian tests to the test suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 simonpj): I'm all for it. But please make it clear in the tests what their provenance is, and the remarks in your Description above. Maybe just call them T12669a, T12669b, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:39:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:39:55 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.d4f49f564990fde9d7229e9181bdc9e2@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Phyx-): Right, so I see the problem... You're using the msys version of python, which doesn't correctly search for the SO name. {{{ 6ef8:5d44 @ 584664718 - LdrLoadDll - ENTER: DLL name: kernel32. 6ef8:5d44 @ 584664718 - LdrpLoadDllInternal - ENTER: DLL name: kernel32 6ef8:5d44 @ 584664718 - LdrpFindKnownDll - ENTER: DLL name: kernel32 6ef8:5d44 @ 584664718 - LdrpFindKnownDll - RETURN: Status: 0xc0000135 6ef8:5d44 @ 584664718 - LdrpSearchPath - ENTER: DLL name: kernel32 6ef8:5d44 @ 584664718 - LdrpComputeLazyDllPath - INFO: DLL search path computed: E:\ghc- dev\msys64\usr\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\system;C:\WINDOWS;.;E:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext\arcade;C:\ruby215\bin;C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\WIDCOMM\Bluetooth Software\;C:\Program Files\WIDCOMM\Bluetooth 6ef8:5d44 @ 584664718 - LdrpResolveDllName - ENTER: DLL name: E:\ghc- dev\msys64\usr\bin\kernel32 6ef8:5d44 @ 584664718 - LdrpResolveDllName - RETURN: Status: 0xc0000135 6ef8:5d44 @ 584664718 - LdrpResolveDllName - ENTER: DLL name: C:\WINDOWS\SYSTEM32\kernel32 6ef8:5d44 @ 584664718 - LdrpResolveDllName - RETURN: Status: 0xc0000135 6ef8:5d44 @ 584664718 - LdrpResolveDllName - ENTER: DLL name: C:\WINDOWS\system\kernel32 6ef8:5d44 @ 584664718 - LdrpResolveDllName - RETURN: Status: 0xc0000135 6ef8:5d44 @ 584664718 - LdrpResolveDllName - ENTER: DLL name: C:\WINDOWS\kernel32 }}} it doesn't add the ".dll" to it. so the loader doesn't find it. What you want, is the mingw-w64 version of python (which is also compiled with GCC so MSVC runtime not needed). {{{ pacman -S mingw-w64-$(uname -m)-python3 }}} Odd, the installation of Sphinx should have installed it as well. It would be python3.5. The msys python is a bit broken (which is unsurprising, the msys versions are usually the bare minimum to get the msys shell itself working). correct the link from python3 -> mingw python3.5 and you should be good to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 18:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 18:49:34 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.c2c8747f608d4b526c635b504cd47b8b@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Replying to [comment:39 varosi]: > Task manager on Windows 10 shows NUMA nodes and logical cores separated. So both NUMA nodes are taken by 85-88%. On logical cores, there about 10 from 88 cores not used for some reason. They are near zero CPU usage. A few setcapabilities failed. I need to take a look at the masks. I'll make a version which adds more debug output this weekend (I don't quite have the time today I'm araid..). I'll need it to know the masks it's computing. There's probably an off by one somewhere. But I am confused, if 78 cores out of 88 are busy, you should have gone passed the 50% mark since it went across CPU groups. Replying to [comment:40 varosi]: > Is it possible "-qa" option to be reversed, i.e. by default it to use all NUMA nodes and if someone wants for some special case to disable it? I don't see why not, but this won't just affect Windows and I don't know why the default is to default to user managed threading. To be clear, `-qa` isn't required to use all the nodes. The only thing `-qa` does is automatically schedule the affinities for you. The default is that you should schedule them yourself. The reason could be purely historic. This is a question best asked on the ghc-devs mailing list. If you prefer I could ask for you, or you can mail directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:00:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:00:52 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.fa8dbdd122a1fb7388ba7885de57f21f@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 goldfire): Yes, I suppose `checkForRepresentationPolymorphism` is a bit loose in its definition of what is representation polymorphic. It should look for the kind to be `TYPE blah` before proceeding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:06:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:06:43 -0000 Subject: [GHC] #12669: Add some weird Kmettian tests to the test suite In-Reply-To: <045.51265cdb375454bf32c5460f73599b17@haskell.org> References: <045.51265cdb375454bf32c5460f73599b17@haskell.org> Message-ID: <060.93f3116e19086fa00e35cd01cb8bc04e@haskell.org> #12669: Add some weird Kmettian tests to the test suite -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 goldfire): I'd go a step further than comment:1 and put these kinds of tests in their own directory within the `testsuite/tests` directory. Something like `unsupp` (or, if you're feeling verbose -- as I often do -- `would_be_nice`). Then, when I see a failure as I'm putting in a new feature, my level of disappointment at failing the testsuite will be immediately lowered. Do include a README in the folder describing its purpose. Ideally, each test case would also repeat the info that the behavior is unsupported. I do fully support the inclusion of these tests in the testsuite. Thanks for suggesting it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:23:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:23:44 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.3f8a2739ebec4eec7c4a8a3d229addea@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:35:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:35:55 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.1cb878e047403609b256116719c99fab@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "12395.tar.gz" added. example with stack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:39:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:39:46 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.1bf6e7d433d15b1c80df74e262760702@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): @ezyang The attached example demonstrates the problem: {{{ > stack test b > stack exec ghci -- b/Main.hs b/Main.hs:6:14: error: Ambiguous occurrence ‘str’ It could refer to either ‘A.str’, imported from ‘A’ at b/Main.hs:2:1-8 (and originally defined at a/A.hs:7:1-3) or ‘B.str’, imported from ‘B’ at b/Main.hs:3:1-8 (and originally defined in ‘A’) Failed, modules loaded: A. }}} The issue may be related to my .ghci file: I have `:set -ia`, but do not give a path to `b`. If I give paths to `a` and `b`, or neither, it appears to compile fine. Thanks for looking into this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 19:58:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 19:58:45 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.aa3114cafb3b3d9aac576714ad4bb3cf@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Replying to [comment:5 Phyx-]: > Right, so I see the problem... > > You're using the msys version of python, which doesn't correctly search for the SO name. > Indeed it looks like that is the issue. Great catch! > it doesn't add the ".dll" to it. so the loader doesn't find it. What you want, is the mingw-w64 version of python (which is also compiled with GCC so MSVC runtime not needed). > > {{{ > pacman -S mingw-w64-$(uname -m)-python3 > }}} > > Odd, the installation of Sphinx should have installed it as well. It would be python3.5. The msys python is a bit broken (which is unsurprising, the msys versions are usually the bare minimum to get the msys shell itself working). > Judging from the output from that `pacman` command I suspect that the correct python was already installed. However... > correct the link from python3 -> mingw python3.5 and you should be good to go. Ahh, I suspect this is what I missed. In fact, shouldn't it also be necessary to symlink `python` to `python3.5` as well to ensure that no references to the broken python leak through? This is a rather subtle step, do you think you could mention this on [[Building/Preparation/Windows]]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 20:07:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 20:07:12 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.09820534c603c0921e4c6906388d38e5@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): I'm actually quite confused. It looks like the testsuite driver will not run with python3. {{{ *** WARNING: running testsuite using Python 3. *** Python 3 support is experimental. See Trac #9184. Traceback (most recent call last): File "../driver/runtests.py", line 216, in for line in pkginfo.split('\n'): TypeError: a bytes-like object is required, not 'str' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 20:12:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 20:12:59 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.53bcd509371020e6a765d8eadc244c63@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed simply installing `mingw-w64-$(uname -m)-python2` seems to fix things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 20:13:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 20:13:10 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.19e1879cee81d4654caf824447beb151@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Thanks for your help Phyx! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 20:24:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 20:24:45 -0000 Subject: [GHC] #9547: Empty constraint tuples are mis-kinded In-Reply-To: <046.4a68986f8009faa587ff75cd38e6aeac@haskell.org> References: <046.4a68986f8009faa587ff75cd38e6aeac@haskell.org> Message-ID: <061.16794228c414c10b6e559d7987974228@haskell.org> #9547: Empty constraint tuples are mis-kinded -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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 Iceland_jack): For the record, works if annotated: {{{#!hs import GHC.Exts foo :: If True (() :: Constraint) (Eq a) => a -> a foo = error "urk" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 20:26:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 20:26:20 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.e53da7688da07e653c9fdbedbf8578c4@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Phyx-): Yes, though this advice of prefering the mingw packages over the msys ones doesn't just apply for `python`. I've amended the section at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows#ConfiguringMinGWproperly The way I always do it is to make sure in my profile that `/mingw64/bin` is the first thing on the `$PATH`. I need to make some time to re-evaluate that page, as I am not sure we need any of those msys versions of the tools we're telling people to install. They've bitten us quite a few times already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 21:19:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 21:19:04 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.e5c2f9be64853ab83ea78c4c8917b01c@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): more prototypes for conversion from digits to an integer can be found here: http://int-e.eu/~bf3/haskell/FromDigits.hs ... `valInteger'` is the most interesting one of the bunch, and according to some preliminary testing, also the most efficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 22:23:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 22:23:23 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.c7c8c6a4ff2d489873ad60b8161dd566@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): simonmar: I feel like the only option may be to do eager binding, and to always allocate groups of whole pages for each linked object file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 22:41:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 22:41:44 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.455ad19210c038312f28ed3201d9ba09@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): I'm not sure about that, it's possible that there would be more ''bang''-per-''buck'' in extending `LambdaCase` with `\case2`, `\case3`. Take an example of dictionary translation from [https://skillsmatter.com/skillscasts/8978-checking-and-translating-type- classes Checking and translating type classes]: {{{#!hs import Prelude hiding (Eq (..)) data Eq a = MkEq { (==) :: a -> a -> Bool , (/=) :: a -> a -> Bool } }}} {{{#!hs -- Default definition of (/=) neqDef :: Eq a -> a -> a -> Bool neqDef = not .:: (/=) where (.::) = fmap.fmap.fmap eqList :: forall a. Eq a -> Eq [a] eqList a = MkEq { (==) = aux , (/=) = neqDef (eqList a) } where aux :: [a] -> [a] -> Bool aux [] [] = True aux (x:xs) (y:ys) = (==) a x y && (==) (eqList a) xs ys aux _ _ = False }}} Now if we wanted to inline `aux` using this ticket, they would presumably translate into lambdas (single clause): {{{#!hs eqList a = MkEq { a == b = case (a, b) of ([], []) -> True (x:xs, y:ys) -> ... (_, _) -> False -- Translates into -- -- eqList a = MkEq -- { (==) = \a b -> ... }}} A hypothetical `\case2` may be better {{{#!hs eqList a = MkEq { (==) = \case2 ([], []) -> True (x:xs, y:ys) -> ... (_, _) -> False , (/=) = neqDef (eqList a) } }}} Given an extension that allows user to omit tuple parentheses when un- ambiguous (similar to Agda's `_,_` constructor which looks like `a , b` when applied to two arguments) this looks even better {{{#!hs eqList a = MkEq { (==) = \case2 [], [] -> True x:xs, y:ys -> ... _, _ -> False , (/=) = neqDef (eqList a) } }}} Should I create a ticket for these ideas or use the new [https://github.com/ghc-proposals/ghc-proposals GHC Proposals]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 23:41:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 23:41:18 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.c98dfd3a247b3354b89dcc005aeb1f9e@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 int-e]: > more prototypes for conversion from digits to an integer can be found here: http://int-e.eu/~bf3/haskell/FromDigits.hs ... `valInteger'` is the most interesting one of the bunch, and according to some preliminary testing, also the most efficient. There's an unfortunate problem with the memoized base list. Once GHC knows the base, it pulls the `bs` base list up to the top level. If someone parses a very large integer, I believe we could be stuck with its base list indefinitely. Now it turns out that `ReadP` is defined `newtype ReadP a = R (forall b . (a -> P b) -> P b)`. If `Text.ParserCombinators.ReadP` exposed the `R` constructor and the `P` type (which it does not) then we could almost certainly trick GHC into thinking that `bs` depends on the passed `a -> P b` function. Since it does not, we're in a bit of a pickle. I think the best approach is probably to add an "internal" module that exposes all these details. For experimental purposes, I guess I can just use `unsafeCoerce`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 6 23:45:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 06 Oct 2016 23:45:40 -0000 Subject: [GHC] #12671: enumFrom error thwarts checkOldIface's exception handling Message-ID: <045.982d441cbfb8057536c864e1cc7eeff7@haskell.org> #12671: enumFrom error thwarts checkOldIface's exception handling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug needs a bit of jiggery-pokery to reproduce. First, we need to create a malformed hi file that we will feed `checkOldIface`. First, have a fresh build of GHC. Apply the following diff to your tree: {{{ diff --git a/compiler/main/HscTypes.hs b/compiler/main/HscTypes.hs index 7a585f3..4e41887 100644 --- a/compiler/main/HscTypes.hs +++ b/compiler/main/HscTypes.hs @@ -1033,7 +1033,8 @@ instance Binary ModIface where put_ bh vect_info put_ bh hpc_info put_ bh trust - put_ bh trust_pkg + putByte bh 3 + -- put_ bh trust_pkg get bh = do mod <- get bh }}} Next, rebuild ONLY the stage 2 compiler using `cd ghc; make stage=2 -j12 fast`. Now, use the new stage2 compiler to compile some module (it can be empty): {{{ [ezyang at hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs [ezyang at hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161006 for x86_64-unknown-linux): Prelude.Enum.Bool.toEnum: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} With `-v3`, we see that this error occurred when checking the old interface: {{{ [ezyang at hs01 ghc-backpack]$ inplace/bin/ghc-stage2 -c A.hs -v3 Glasgow Haskell Compiler, Version 8.1.20161006, stage 2 booted by GHC version 8.0.1 Using binary package database: /home/hs01/ezyang/ghc- backpack/inplace/lib/package.conf.d/package.cache package flags [] loading package database /home/hs01/ezyang/ghc- backpack/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: *** Checking old interface for A: }}} Dastardly. We've choked checking the old interface! The problem seems to be that the `toEnum` exception is not an `IOException`, so we don't catch it in `tryMost` (which `readIface` uses to catch errors). Funnily enough, the comment above says precisely, `TODO: I'm not entirely sure if this is catching what we really want to catch`. But to catch these, we'll have to catch all `UserError`s (because that is what is being thrown in this case.) Maybe a bridge too far? Another possibilty is to use some home-baked `toEnum` which catches errors of this sort. Anyway, the fix should be simple, we just have to decide what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 00:37:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 00:37:15 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.7011235581f080347b28d3cf0e7b0c34@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Argh! I was stupid there. I figured out a way. Also, I managed to forget that we have arbitrary look-ahead, so if we ''prefer'' to work from a list, we actually can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 03:09:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 03:09:14 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.d8e8dab979bd807e6b6d19c48247e296@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 carter): Am I seeing copatterns here or is it just me? @icelandjack I have nontrivial examples involving gadts and such Could we collaborate on this? This winds up being intimately related to coinduction and modelling protocols and interesting examples of linear logic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 03:58:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 03:58:28 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.f05fc27f5d02b5e4293545e899cace00@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Replying to [comment:3 Iceland_jack]: > A hypothetical `\case2` may be better > > {{{#!hs > eqList a = MkEq > { (==) = \case2 > ([], []) -> True > (x:xs, y:ys) -> ... > (_, _) -> False > , (/=) = neqDef (eqList a) > } > }}} > > Given an extension that allows user to omit tuple parentheses when un- ambiguous (similar to Agda's `_,_` constructor which looks like `a , b` when applied to two arguments) this looks even better > > {{{#!hs > eqList a = MkEq > { (==) = \case2 > [], [] -> True > x:xs, y:ys -> ... > _, _ -> False > , (/=) = neqDef (eqList a) > } > }}} Why not go all the way and allow the full syntax of function definitions here, just as in a module scope, in an instance declaration, in a where clause or in a let clause: {{{#!hs eqList a = MkEq { [] == = True (x:xs) == (y:ys) = … _ == _ = False , (/=) = neqDef (eqList a) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 04:18:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 04:18:37 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.06150c393f56304a2624838197b269c5@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 rwbarton): This doesn't seem to work well with the layout rules. Given that you can't define a function by multiple equations in this way, the payoff here seems very low... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 04:52:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 04:52:50 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.87438ef4ab9fd7e9567847c8a0623937@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 ezyang): It's worth mentioning that you can almost directly simulate the desired syntax here using record wildcards: {{{ propertyMap :: (Monad m, Ord k) => v -> PropertyMap m k v propertyMap v0 = go v0 Map.empty where go v m = PropertyMap{..} where getP k = return $ maybe v id (Map.lookup k m) putP k v' = return $ go v (Map.insert k v' m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 08:33:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 08:33:44 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.235cd88d39784d5710745dc2547fc515@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2579 Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * differential: => D2579 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 10:07:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 10:07:32 -0000 Subject: [GHC] #12664: System.Environment.withArgs and friends leak memory In-Reply-To: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> References: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> Message-ID: <062.3c02d3f2a5b7859595a6db7646018ea1@haskell.org> #12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 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 Bartosz Nitka ): In [changeset:"e41b9c614984b63c4660018cecde682453e083e5/ghc" e41b9c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e41b9c614984b63c4660018cecde682453e083e5" Fix memory leak from #12664 This fixes the leak with `setProgArgv`. The problem was that `setProgArgv` would not free the objects pointed to by `prog_argc`, `prog_argv` when the globals were changed resulting in a leak. The only strictly necessary change is in `rts/RtsFlags.c`, but the code in `System.Environment` was a bit confusing and not exception safe, so I refactored it. Test Plan: ./validate Reviewers: simonmar, ezyang, austin, hvr, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2576 GHC Trac Issues: #12664 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 10:08:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 10:08:37 -0000 Subject: [GHC] #12664: System.Environment.withArgs and friends leak memory In-Reply-To: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> References: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> Message-ID: <062.d372a215859a5bc75f2000b1b403e322@haskell.org> #12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 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 niteria): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 10:21:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 10:21:09 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.dcb0088fd0aceff3fe8370d335559a4d@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'm not sure why this has surfaced again, it's an old problem, see #738. I'm actually not sure how the linker worked with SELinux before, as far as I can tell it has always mmapped with RWX permissions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 12:07:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 12:07:04 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.75b1387bc9c266b319b1c48593d4a5c8@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I think the RTS itself should auto-tune the parameters more than it does. The only reason it doesn't right now is because adding parameters is easy while automatically setting them to good values is hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 12:22:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 12:22:24 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.73c92c237a3f1fcd0de3ccea91a321c9@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): Well, I'm not quite sure that is sufficient; afterall the kind of `a` in the above example indeed has the form `TYPE blah`. Rather, it seems like we need some way of determining whether a particular `RuntimeRep` variable affects the runtime representation of a type. It would seem at first glance that given a function type, e.g. `a -> b`, we would want to check that the kinds of `a` and `b` both have no free `RuntimeRep` variables. I suspect this is the only check necessary. We can assume that applications of any other tycon to `RuntimeRep` variables is safe since the type has already been subject to the `checkForRepresentationPolymorphism` check. Consequently, we have already determined that none of the type's type arguments will affect its representation and therefore any well-kinded application is safe. Therefore, I propose that `checkForRepresentationPolymorphism` is simply the following, {{{#!hs checkForRepresentationPolymorphism :: SDoc -> Type -> TcM () checkForRepresentationPolymorphism extra ty | Just (tc, tys) <- splitTyConApp_maybe ty , isUnboxedTupleTyCon tc || isUnboxedSumTyCon tc = mapM_ (checkForRepresentationPolymorphism extra) (dropRuntimeRepArgs tys) | tuple_rep || sum_rep = {- fail -} | (args, res) <- splitFunTys ty , not $ all is_safe_arrow_argument (res:args) = {- fail -} | otherwise = return () where tuple_rep = runtime_rep `eqType` unboxedTupleRepDataConTy sum_rep = runtime_rep `eqType` unboxedSumRepDataConTy tuple_or_sum = text (if tuple_rep then "tuple" else "sum") ki = typeKind ty runtime_rep = getRuntimeRepFromKind "check_type" ki is_safe_arrow_argument = isEmptyVarSet . tyCoVarsOfType . getRuntimeRepFromKind "check_type" . typeKind }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 12:35:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 12:35:48 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.8020dc755c1e2cd925ce8c5689bcb8b9@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): what are some good "standard profiles"? those could still be semi parameterized, but we could have "for a workload like xyzlmnop, --batchoffflinethroughput is good" or something -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 12:53:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 12:53:23 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.f2a98a3deea33912759c779b63f8b1ae@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): Replying to [comment:7 ezyang]: > It's worth mentioning that you can almost directly simulate the desired syntax here using record wildcards: ... Indeed. This pattern is the one and only time I've made profitable use of record wildcards. In general, I think this one isn't quite worth its weight. But, @Iceland_jack, I encourage you to use the ghc-proposals process for ideas like this, as it's now the official place for the community to weigh in on new language ideas. Posting to Trac reaches a smaller subset of the community. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 13:45:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 13:45:50 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.3b6421eec7196d60c4a43e1b4735ebe0@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): It seems that the above validity check loosening would also require that the Core Linter be loosened a bit. Otherwise, we find that this program will typecheck yet then fail due to validity check errors, {{{#!hs{-# LANGUAGE TypeInType, PolyKinds, GADTs, RankNTypes #-} module Hi where import GHC.Exts data Fingerprint = Fingerprint data TyCon = TyCon data TypeRep (a :: k) where TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). Fingerprint -> TypeRep a -> TypeRep b -> TypeRep (a -> b) data AppResult (t :: k) where App :: TypeRep a -> TypeRep b -> AppResult (a b) splitApp :: TypeRep a -> Maybe (AppResult a) splitApp (TrFun _ _ _) = Nothing }}} The Core lint issues stem from the fact that we have number of (unused) coercion bindings in scope in the produced Core whose types fail the `okArrowArgKind` check performed by `lintArrow`. For instance, {{{#!hs splitApp :: forall k_a2Xm (a_a2VN :: k_a2Xm). TypeRep k_a2Xm a_a2VN -> Maybe (AppResult k_a2Xm a_a2VN) splitApp = \ (@ k_a2Xu) (@ (a_a2Xv :: k_a2Xu)) (ds_d37A :: TypeRep k_a2Xu a_a2Xv) -> case ds_d37A of wild_00 { TrFun @ r1_a2Xx @ r2_a2Xy @ a_a2Xz @ b_a2XA cobox_a2XB cobox_a2XC ds_d37Y ds_d37Z ds_d380 -> ... let { cobox_a2XU :: ((a_a2Xv |> cobox_a2XB) :: *) ~# ((a_a2Xz -> b_a2XA) :: *) cobox_a2XU = CO: _N |> cobox_a2XB ; cobox_a2XC } in ... }}} which produces, {{{ : warning: In the type ‘((a_a2Xv |> cobox_a2XB) :: *) ~# ((a_a2Xz -> b_a2XA) :: *)’ Ill-kinded argument in type or kind ‘a_a2Xz -> b_a2XA’ type or kind ‘a_a2Xz -> b_a2XA’ kind: TYPE r1_a2Xx }}} due to the fact that `a_a2Xz` has `RuntimeRep`-polymorphic kind `TYPE r1_a2Xx`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 14:20:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 14:20:46 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.bded73eace7480ecdc46dde91b036277@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"f3be304abed6407b5ef148d76e4679c88018c780/ghc" f3be304a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3be304abed6407b5ef148d76e4679c88018c780" Don't suggest deprecated flags in error messages When looking up flags, we make sure to lookup the non-deprecated flags first by ordering the list of flags. Reviewers: bgamari, austin, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2541 GHC Trac Issues: #12574 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 15:42:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 15:42:13 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.cdebfa232150944e298744df6815a9c4@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Thanks for amending the Wiki discussion, Tamar. That explanation clears things up nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 16:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 16:44:33 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.9224347d2fda1a9d3ff96a55c750bbad@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Phyx-): No problem, you might also hit #12554, haven't figured that one out yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 18:27:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 18:27:39 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.dd23b2479ecb2ae3dbfef0ffe8a47401@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:11 dfeuer]: > There's an unfortunate problem with the memoized base list. [...] One can also store the bases in the stack itself, see `valInteger''` in the (updated) http://int-e.eu/~bf3/haskell/FromDigits.hs file. This causes some extra allocations, so the code becomes slower, but almost imperceptibly so. In my crude measurements (code compiled with -O2, run by using the `test*` functions in `ghci`), converting a list of 10,000,000 digits in base 10 takes 8.1s with the code currently in base (`Data.Read.Lex.valInteger`), 2.0s with `valInteger'` and 2.1s with `valInteger''`. Converting 2^18^ 18 digit integers takes 0.47s with the original code, 0.23s with `valInteger'` and `valInteger''`. Note that no actual lexing is done by this code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 19:18:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 19:18:56 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.b40fb9aeed50d3ae0f1e39d2c6770555@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): While I make progress with getting the tree to compiler properly again, here is one question that will need to be answered. Consider this rule: {{{ "foldr/id" foldr (:) [] = \x -> x }}} Because we desugar constructor in source to the ''wrapper'' (especially if they are unsaturated), but the wrapper is a function that will be marked as inlineable, the compiler now gives this error message: {{{ libraries/base/GHC/Base.hs:855:1: warning: [-Winline-rule-shadowing] Rule "foldr/id" may never fire because ‘GHC.Types.$W:’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘GHC.Types.$W:’ }}} So at first I thought: Ok, no problem, I just force the inlining of data con wrappers after the desugaring of rule left-hand sides, and this might work for `[]`, but `(:)` is really used unsaturated here. What is the best way forward here? One way would be to disable this warning specifically for datacon workers, and then make the rule matcher smart enough to match both variants. Or alternatively, make the warning aware that an unsaturated use of a function with an unfolding will not inline, and it is thus ok to have something `INLINE` on the LHS of a rule, as long as it is unsaturated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 20:57:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 20:57:26 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.f678eccd5419038c54ffb0daeb39f211@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Actually this is already a problem today. It's just rendered more prominent now that even `(:)` has a wrapper. Consider {{{ data T = MkT {-# UNPACK #-} !Int {-# RULES "fT" f MkT = True "gT" forall x. g (MkT x) = x #-} f :: (Int -> T) -> Bool {-# NOINLINE f #-} f x = True g :: T -> Int {-# NOINLINE g #-} g (MkT x) = x+1 }}} yields {{{ Foo.hs:9:1: warning: [-Winline-rule-shadowing] Rule "fT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' Foo.hs:10:1: warning: [-Winline-rule-shadowing] Rule "gT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' }}} What to do? If we are to match these rules, we really must delay inlining the wrapper for `MkT` (after inlining we get a mess of unboxing etc). So either we must allow you to add a NOINLINE pragma to `MkT`; or we must add one automatically (e.g. `NOINLINE [1]`). Delaying all consructor-wrapper inlining to phase 1 is potentially quite drastic, because case-of-known-constructor wouldn't happen until the wrappers are inlined. Maybe that's ok; I'm not sure. Worth trying I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 21:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 21:15:19 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.22da73daf616b6fe4da95bf3594fc844@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Well, the whole point of this ticket is to have `ConApp` as soon as possible, and nesting tuples with `$W(,)` will have again the quadratic cost until we get rid of them, so I am not convinced. Also it feels wrong to fight against the inliner here… Would it be wrong for GHC to look a that rule, notice that something marked as `INLINE` occurs on the LHS, but then notice that it is used unsaturated, hence conclude that it will not have been inlined in the program where the rule needs to be matched, and omit the warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 7 23:48:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 07 Oct 2016 23:48:37 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.cefced3a25fbe3ec18a4c32c52d425b6@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:13 int-e]: > One can also store the bases in the stack itself, see `valInteger''` in the (updated) http://int-e.eu/~bf3/haskell/FromDigits.hs file. This causes some extra allocations, so the code becomes slower, but almost imperceptibly so. I wrote up something essentially equivalent to `Numeric.readDec` based on your latest code and the shape of the lexer: {{{#!hs decNat :: ReadP Natural decNat = valNat 10 19 $ \c -> let diff = charDiff c '0' in if diff < 10 then Just diff else Nothing valNat :: Word -> Word -> (Char -> Maybe Word) -> ReadP Natural valNat base chunkSize terp = do s <- ReadP.look valNat' base chunkSize terp s {-# INLINE valNat #-} data Stack = SNil | SSkip Natural !Stack | SCons Natural !Natural !Stack {-# INLINE valNat' #-} valNat' :: Word -> Word -> (Char -> Maybe Word) -> [Char] -> ReadP Natural valNat' base chunkSize terp cs0@(c0 : _) | Just _ <- terp c0 = goChunks SNil 0 0 cs0 where b1 :: Natural b1 = fromIntegral base * fromIntegral (base^(chunkSize-1)) goChunks :: Stack -> Word -> Word -> [Char] -> ReadP Natural goChunks !s !l !chunk !ds | l == chunkSize = goChunks (step s (fromIntegral chunk)) 0 0 ds goChunks !s !l !chunk (c:cs) | Just d <- terp c = ReadP.get *> goChunks s (l+1) (chunk*base+d) cs goChunks !s !l !chunk _ = pure $ fromStack (fromIntegral chunk) (fromIntegral (base^l)) s step :: Stack -> Natural -> Stack step SNil d = SCons b1 d SNil step (SSkip b s) d = SCons b d s step (SCons b d' s) d = SSkip b (step' b s (d + d'*b)) step' :: Natural -> Stack -> Natural -> Stack step' b SNil d = SCons (b*b) d SNil step' _ (SSkip b s) d = SCons b d s step' _ (SCons b d' s) d = SSkip b (step' b s (d + d' * b)) fromStack :: Natural -> Natural -> Stack -> Natural fromStack d' _ SNil = d' fromStack d' b' (SSkip b s) = fromStack d' b' s fromStack d' b' (SCons b d s) = fromStack (d*b'+d') (b*b') s valNat' _ _ _ _ = ReadP.pfail -- We could write a parser more precisely imitating GHC's current -- `Read` instance by using `valNat` and then performing a look-ahead -- to check for illegal termination sequences involving `.` or `e`, -- but I'm really not convinced that we should. }}} This seems to be very fast indeed when used for base 10 with a chunk size of 19 (on a 64-bit system). Oddly, `Numeric.readDec` is much, much slower than `read`, which looks likely to be a `RULES` issue. That makes it a bit hard to compare the algorithms fairly. I haven't yet wired your simpler version up in quite this fashion, and I'm not actually sure if it can be wired up so, but it would be worth checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 02:08:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 02:08:44 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.d4296af1ec9050e83c73332745f03a61@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I am also seeing this on the new Windows build bot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 09:08:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 09:08:34 -0000 Subject: [GHC] #11970: Simplify Parent for patten synonyms In-Reply-To: <046.99b58fbbe4691b1cc88a00dd47c4a70f@haskell.org> References: <046.99b58fbbe4691b1cc88a00dd47c4a70f@haskell.org> Message-ID: <061.9db15f066680a060b8cbe537a37df21f@haskell.org> #11970: Simplify Parent for patten synonyms -------------------------------------+------------------------------------- Reporter: simonpj | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2179 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"e660f4bf546e90fb6719ad268ca3daaecdce4b82/ghc" e660f4bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e660f4bf546e90fb6719ad268ca3daaecdce4b82" Rework renaming of children in export lists. The target of this patch is exports such as: ``` module Foo ( T(A, B, C) ) where ``` Essentially this patch makes sure that we use the correct lookup functions in order to lookup the names in parent-children export lists. This change highlighted the complexity of this small part of GHC which accounts for the scale. This change was motivated by wanting to remove the `PatternSynonym` constructor from `Parent`. As with all these things, it quickly spiraled out of control into a much larger refactor. Reviewers: simonpj, goldfire, bgamari, austin Subscribers: adamgundry, thomie Differential Revision: https://phabricator.haskell.org/D2179 GHC Trac Issues: #11970 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 09:45:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 09:45:08 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.c3682a24d3a4cab1b4fc076c82602dcb@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I'm still trying to get my head around this problem. Here's the algorithm I want to use: * for each package DB * add packages one by one to an accumulating `Map PackageId (Maybe Package)` * if we encounter a `PackageKey` that we already have: * If the ABIs are the same, replace the old one by the new one * If the ABIs are different, insert a `Nothing` entry in the map (and report an error with -v2) * If we already have a `Nothing` for this `PackageKey`, leave it as `Nothing` (and report an error with -v2) * Afterwards, remove any package from the DB with one or more missing dependencies, recursively until you can remove no more packages. (report what we're doing with -v2) Does anything go wrong with this? It's a slight variant of the algorithm that we used before `PackageKey`s I think. When we have dependencies that specify ABIs we can refine this to be more intelligent about what to throw away, but in the meantime I think this will be fine. It's very similar to what we used to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 12:18:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 12:18:00 -0000 Subject: [GHC] #7416: ghci "attempting to use module ... which is not loaded" after cabal install, in source dir In-Reply-To: <049.26ad752077d32869bb87183481c22fb8@haskell.org> References: <049.26ad752077d32869bb87183481c22fb8@haskell.org> Message-ID: <064.d9e6baf10496b598083ff418699b71d0@haskell.org> #7416: ghci "attempting to use module ... which is not loaded" after cabal install, in source dir -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: invalid | 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 phadej): A workaround which seems to work for hackage-security: First: write a .ghci file with: {{{ :load src/Prelude.hs import Prelude :set -XImplicitPrelude }}} As cabal doesn't give ability to pass /only/ ghci-flags atm use `cabal repl -v` or `cabal new-repl -v` to get a command line cabal uses: something like {{{ /opt/ghc/8.0.1/bin/ghc --interactive -fbuilding-cabal-package -O0 -outputdir ... }}} then add a `-XNoImplicitPrelude` there {{{ /opt/ghc/8.0.1/bin/ghc --interactive -XNoImplicitPrelude -fbuilding-cabal- package -O0 -outputdir ... }}} --- This works because - if `-XNoImplicitPrelude` is specified `ghci` doesn't implicitly load Prelude - after that `.ghci` file is loaded, where we load right `Prelude.hs` and import it, and turn implicit prelude on - loading of package proceeds It seems to work, but fragile it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 12:20:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 12:20:44 -0000 Subject: [GHC] #10920: ghci can't load local Prelude module In-Reply-To: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> References: <044.430737785a4f09b7817aca3e41ea1e80@haskell.org> Message-ID: <059.e52690d666d6af8f326eb2f9cc3adbdc@haskell.org> #10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 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 phadej): A workaround which seems to work for hackage-security: First: write a .ghci file with: {{{ :load src/Prelude.hs import Prelude :set -XImplicitPrelude }}} As cabal doesn't give ability to pass /only/ ghci-flags atm use `cabal repl -v` or `cabal new-repl -v` to get a command line cabal uses: something like {{{ /opt/ghc/8.0.1/bin/ghc --interactive -fbuilding-cabal-package -O0 -outputdir ... }}} then add a `-XNoImplicitPrelude` there {{{ /opt/ghc/8.0.1/bin/ghc --interactive -XNoImplicitPrelude -fbuilding-cabal- package -O0 -outputdir ... }}} --- This works because - if `-XNoImplicitPrelude` is specified `ghci` doesn't implicitly load Prelude - after that `.ghci` file is loaded, where we load right `Prelude.hs` and import it, and turn implicit prelude on - loading of package proceeds It seems to work, but fragile it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 14:41:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 14:41:45 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.6865c07cfb8051e38899bbaf27f96a52@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * cc: tjakway (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 16:47:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 16:47:19 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.c9febb4e69b8fcbd42c97f59f1242150@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Taking a look again, but my Python foo is weak.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 18:32:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 18:32:43 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description Message-ID: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: documentation | Operating System: Unknown/Multiple monad | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Control.Monad` documentation is missing the lambda in the documentation for the third monad law because it is not escaped with an additional `\`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 18:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 18:38:42 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.2c979652f533a9d97aadbae9ad5c38d1@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vaibhavsagar): * owner: => vaibhavsagar * differential: => D2583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:05:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:05:24 -0000 Subject: [GHC] #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin Message-ID: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Package | Version: 8.0.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `bkpcabal01` testcase introduced the by Backpack merge fails on Mac OS X with, {{{ =====> bkpcabal01(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print- directory bkpcabal01 CLEANUP=1 Actual stderr output differs from expected: --- /dev/null 2016-10-08 22:51:23.000000000 +0300 +++ ./backpack/cabal/bkpcabal01/bkpcabal01.run/bkpcabal01.run.stderr.normalised 2016-10-08 22:51:23.000000000 +0300 @@ -0,0 +1,4 @@ +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-36887/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-36936/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/p-0.1+FBOSaiWyMx9DR2UZVI6wQJ/objs-37078/libHSp-0.1+FBOSaiWyMx9DR2UZVI6wQJ.a(H.o) has no symbols +/Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-37123/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols *** unexpected failure for bkpcabal01(normal) }}} It seems that the problem is that `ar` produces a warning when producing an archive file containing an object file with no symbols, {{{ bkpcabal01 bgamari$ make SETUP="./Setup -v3" bkpcabal01 ... ("/usr/bin/ar",["-r","-s","-v","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o","dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o"]) ar: creating archive dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/Q.o a - dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/I.o /Applications/Xcode-7.2/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/q-0.1+70e5o6lPGfgGiochTG2tqQ/objs-39951/libHSq-0.1+70e5o6lPGfgGiochTG2tqQ.a(I.o) has no symbols }}} In general it would be best if we could avoid linking these empty object files to avoid these spurious warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:08:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:08:43 -0000 Subject: [GHC] #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin In-Reply-To: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> References: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> Message-ID: <061.65cfc33be6dc4bc75bf93a3619e6fa53@haskell.org> #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2584 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2584 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:09:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:09:06 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.ee0ee42db7c0ca4c68da92bee6e066c5@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): Under your scheme, if a unit id (package key in your comment) ever occurs twice in the database with different ABI, it is permanently "killed" and we never ever use it again. Other backwards incompatibility notwithstanding, I think this will break GHC bootstrapping itself. Here's the situation: 1. GHC builds and ships a pile of boot libraries and GHC with deterministically chosen unit ids; e.g., `transformers-0.5.2.0`. The primary reason for this is when you are compiling a development version of the compiler, you really want the symbol names of your libraries to stay fixed; otherwise, you'd have to recompile them every time you made a small edit. 2. When we start a GHC build, we build a few libraries and GHC using the bootstrapping compiler. When we compile these, we have to register these using the bootstrapping compiler. Now we have a shadowing situation! Because the unit ids are deterministically chosen, the boot libraries from the bootstrapping compiler will always have the same unit id as the boot libraries; the only way to get GHC to agree to it is to shadow (but the algorithm you gave above would just mark them as unusable.) But maybe this is the tail wagging the dog; what we should do is have the stage1 build have "stage1" appended to their unit ids so they don't shadow. The last time I looked at this (#11025) it seemed difficult to do. Maybe we should try again though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:17:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:17:38 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.7dea2298acae4109ccc6cd6f070c9ccd@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I wonder if the testsuite driver is attempting to run the same test in multiple ways at concurrently, therefore attempting to copy the same file into place more than once. thomie, does this ring any bells? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:20:20 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.1d348d9bb6982ece8f8a19475b913cee@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh, right, we disable threading on Windows. Never mind then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:22:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:22:58 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.d62453f714d6d6080685eb5d096bc0c2@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Well, my TeamCity runs patch the testrunner to run in parallel. The weird thing is, it doesn't happen on my old msys installes, with python 3.4.3, I don't know if this started because of a change in python or the msys runtime. Another odd thing is that I would expect the tests that trigger this to be pretty random. But according to my teamcity data of the past ~1 month, the tests that fail are pretty stable. +- 3-4 tests each run, but all in the same category. Mostly the TH tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:27:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:27:48 -0000 Subject: [GHC] #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin In-Reply-To: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> References: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> Message-ID: <061.7ace0610ae1d9592e94ff98b472f978e@haskell.org> #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2584 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This is actually a Cabal problem, see https://github.com/haskell/cabal/issues/2257 It seems fairly harmless though. Maybe we could put a symbol in `compileEmptyStub` to suppress the error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:57:25 -0000 Subject: [GHC] #5620: Dynamic linking and threading does not work on Windows In-Reply-To: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> References: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> Message-ID: <061.30476936164b933126dd46c4074f2083@haskell.org> #5620: Dynamic linking and threading does not work on Windows ---------------------------------------+----------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Linking) | Version: 7.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+----------------------------- Comment (by dobenour): Could we have the library we link to export stubs for the RTS functions, which then load the library at ''runtime'' using {{{LoadLibrary}}} and {{{GetProcAddress}}}? There are a lot of stubs to write, but are all virtually identical so could easily be generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 20:58:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 20:58:23 -0000 Subject: [GHC] #5786: Dynanmic way fails when GHC built with LLVM backend In-Reply-To: <045.cf3cb6a55862acaa776b11c224813e00@haskell.org> References: <045.cf3cb6a55862acaa776b11c224813e00@haskell.org> Message-ID: <060.985aac9f71c953fd2c984f3fcf129f76@haskell.org> #5786: Dynanmic way fails when GHC built with LLVM backend -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): That bug has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 21:05:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 21:05:03 -0000 Subject: [GHC] #5786: Dynanmic way fails when GHC built with LLVM backend In-Reply-To: <045.cf3cb6a55862acaa776b11c224813e00@haskell.org> References: <045.cf3cb6a55862acaa776b11c224813e00@haskell.org> Message-ID: <060.e053061bda61d6917c9ddc77bee75138@haskell.org> #5786: Dynanmic way fails when GHC built with LLVM backend -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.4.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 22:02:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 22:02:09 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.077a9e30fb9e13ad1de91e30c7e9b76f@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andreash): I think I may just have hit the same bug. I've extracted a small example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE TypeOperators #-} newtype I a = I a type family Curry (as :: [*]) b = f | f -> as b where Curry '[] b = I b Curry (a:as) b = a -> Curry as b data Uncurried (as :: [*]) b def :: Curry as b -> Uncurried as b def = undefined test :: Uncurried [Int, String] String test = def $ \n s -> I $ show n ++ s test2 :: Uncurried [Bool, Bool] Bool test2 = def $ \a b -> I $ a && b }}} Removing the type signatures from either `test`, or `test2` will hang ghc. If the type family is not defined as injective, then ghc doesn't hang, but instead gives an error message about ambiguous type variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 22:08:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 22:08:28 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly Message-ID: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 22:14:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 22:14:35 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.467715d3799f2d23394fd4b0b725a13c@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): You mean “even if `-a.hs` exists”? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 23:13:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 23:13:27 -0000 Subject: [GHC] #12675: Simplifier ticks exhausted Message-ID: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> #12675: Simplifier ticks exhausted --------------------------------------+--------------------------------- Reporter: davean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Works with "-fsimpl-tick-factor=102". Code is: ... import qualified Data.Vector.Unboxed as UV import qualified Data.Vector.Generic as VG import qualified Data.Vector.Algorithms.Tim as Tim ... ∀ v alphabet. (VG.Vector v alphabet, Ord (v alphabet)) ⇒ v alphabet → SA ... SA ∘ VG.modify (Tim.sortBy (lexSuffixCmp st)) ∘ UV.enumFromN 0 $ VG.length st+1 ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 23:14:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 23:14:16 -0000 Subject: [GHC] #12675: Simplifier ticks exhausted In-Reply-To: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> References: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> Message-ID: <060.ac5079060a03e4bf01cb4cc2588c0029@haskell.org> #12675: Simplifier ticks exhausted ---------------------------------+-------------------------------------- Reporter: davean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by davean): * Attachment "dump.stats" added. -ddump-simpl-stats -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 23:15:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 23:15:51 -0000 Subject: [GHC] #12675: Simplifier ticks exhausted In-Reply-To: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> References: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> Message-ID: <060.9ef151990223bdc31205e3f497ef6228@haskell.org> #12675: Simplifier ticks exhausted ---------------------------------+-------------------------------------- Reporter: davean | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by davean): * priority: normal => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 8 23:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 08 Oct 2016 23:16:46 -0000 Subject: [GHC] #12675: Simplifier ticks exhausted In-Reply-To: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> References: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> Message-ID: <060.e24f5ca76669c4a542c91b79833526cc@haskell.org> #12675: Simplifier ticks exhausted ---------------------------------+-------------------------------------- Reporter: davean | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by davean: @@ -4,1 +4,1 @@ - + {{{ @@ -14,0 +14,1 @@ + }}} New description: Works with "-fsimpl-tick-factor=102". Code is: {{{ ... import qualified Data.Vector.Unboxed as UV import qualified Data.Vector.Generic as VG import qualified Data.Vector.Algorithms.Tim as Tim ... ∀ v alphabet. (VG.Vector v alphabet, Ord (v alphabet)) ⇒ v alphabet → SA ... SA ∘ VG.modify (Tim.sortBy (lexSuffixCmp st)) ∘ UV.enumFromN 0 $ VG.length st+1 ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 08:53:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 08:53:42 -0000 Subject: [GHC] #11970: Simplify Parent for patten synonyms In-Reply-To: <046.99b58fbbe4691b1cc88a00dd47c4a70f@haskell.org> References: <046.99b58fbbe4691b1cc88a00dd47c4a70f@haskell.org> Message-ID: <061.dad7e88d165cdd84e4dd990460330405@haskell.org> #11970: Simplify Parent for patten synonyms -------------------------------------+------------------------------------- Reporter: simonpj | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2179 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 12:31:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 12:31:36 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.6ab039dce1ec4da56b83b9c3740ba9a1@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): Once https://github.com/haskell/cabal/pull/3955 is merged, and a new point-release of Cabal-v1.24 is made, I think this issue will be solved by including the new point release in GHC-8.0.2. I did a {{{cabal install stack --enable-executable-dynamic}}} on OS X Sierra, and the build succeeded, and the resulting {{{stack}}} executable worked as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 13:39:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 13:39:51 -0000 Subject: [GHC] #12206: No exposed API to get full text of ErrMsg In-Reply-To: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> References: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> Message-ID: <057.33c28f4e40a2983d37d1c944f48cb44f@haskell.org> #12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHC API | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2491 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bit): I haven't tested this yet, but I carefully inspected the patch and it looks great! Thanks so much! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 14:58:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 14:58:58 -0000 Subject: [GHC] #5467: Template Haskell: support for Haddock comments In-Reply-To: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> References: <046.e4a8d15ae2317226a67b074817a4dd39@haskell.org> Message-ID: <061.9b0c3a3794dda8d1344f082670b73210@haskell.org> #5467: Template Haskell: support for Haddock comments -------------------------------------+------------------------------------- Reporter: reinerp | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 18:15:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 18:15:01 -0000 Subject: [GHC] #5620: Dynamic linking and threading does not work on Windows In-Reply-To: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> References: <046.0549cfb6865d8f8da0c4dd410e165104@haskell.org> Message-ID: <061.ebdf7a1ffdc3cbc89a2f52ce224f3a1b@haskell.org> #5620: Dynamic linking and threading does not work on Windows -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10352 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * architecture: x86 => Unknown/Multiple * related: => #10352 * milestone: => 8.2.1 Comment: @dobenour, what you suggested is basically the same as what @rassilon suggested 4 years ago. The answer is it won't work, this redirect would break for references to const data. and GHC makes use of it a lot. Addresses of closures are usually extracted directly from the export table of the rts. Having the redirects would give you the address of the redirect and not the data. So it won't work unless significant rewrites are done. But I believe SxS assemblies does hold the answer. It will be fixed once #10352 is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 19:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 19:59:19 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.3f60afe6d7e7f27be869f2f6b5d7b83d@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Comment (by basvandijk): I fixed the error in haskell-opencv. Somebody at the Haskell eXchange mentioned it could have something to do with the recent [https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs hardening changes in NixOS-16.09]. It turned out that the `bindnow` feature was causing the problem. After [https://github.com/LumiGuide/haskell- opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4 disabling] the feature the library is building successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 19:59:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 19:59:59 -0000 Subject: [GHC] #11591: thread blocked indefinitely in an MVar operation In-Reply-To: <048.f80b00024c78ab63fc5ff7af29581599@haskell.org> References: <048.f80b00024c78ab63fc5ff7af29581599@haskell.org> Message-ID: <063.b899479583caeb538744c8aa389f4a26@haskell.org> #11591: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: PaulNibin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #10793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:00:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:00:27 -0000 Subject: [GHC] #12521: Thread blocked indefinitely in an MVar operation In-Reply-To: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> References: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> Message-ID: <068.b41b162eb1be00ef2b377dd5fdc8938c@haskell.org> #12521: Thread blocked indefinitely in an MVar operation -----------------------------------+-------------------------------------- Reporter: SwiftsNamesake | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10793 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => duplicate * related: => #10793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:02:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:02:06 -0000 Subject: [GHC] #12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] In-Reply-To: <044.8881c715b9e25b31c2092eb734e27bc0@haskell.org> References: <044.8881c715b9e25b31c2092eb734e27bc0@haskell.org> Message-ID: <059.b73c9a600b7a7e041f884efe3475f8a2@haskell.org> #12654: Panic on interrupting the evaluation of foldl (\x a -> if x > 100 then 100 else x+a) 0 [1..] -------------------------------------+------------------------------------- Reporter: Kuros | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: ghci panic | mvar thread block Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10793 #9940 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #10793 #9940 Comment: Thanks for the report! I believe this is a duplicate, so I'll close this one. feel free to add yourself to the cc of one of the other tickets if you want to be kept informed of changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:03:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:03:06 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code In-Reply-To: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> References: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> Message-ID: <059.2603cc330194ca8c79b002b96b2a8080@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code -------------------------------+---------------------------------- Reporter: lazac | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------- Changes (by Phyx-): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:07:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:07:29 -0000 Subject: [GHC] #12171: option to accept ISO C99... unsupported In-Reply-To: <047.3422b3804ba7edffe1760a7d3448370f@haskell.org> References: <047.3422b3804ba7edffe1760a7d3448370f@haskell.org> Message-ID: <062.cf0f873e91b2f556e8ef6b7ac1e02f86@haskell.org> #12171: option to accept ISO C99... unsupported ----------------------------------------+------------------------------ Reporter: wozgonon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #11005 | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by Phyx-): * status: new => closed * resolution: => duplicate Comment: Marking as a duplicate. Suggested workaround for now is not to use the HP to build. Install a ghc from tarball to a directory with no spaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:15:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:15:32 -0000 Subject: [GHC] #4520: startup code on Windows should use SetDllDirectory("") In-Reply-To: <045.de55fd062c967f225a99df4e00eb514e@haskell.org> References: <045.de55fd062c967f225a99df4e00eb514e@haskell.org> Message-ID: <060.b0c1ba19892f2e772c381b96ea52213d@haskell.org> #4520: startup code on Windows should use SetDllDirectory("") -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Runtime System | Version: 7.0.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => wontfix Comment: I believe the guidance is outdated and doesn't change anything at all. This guidance also predates UAC, which would prevent a non-admin user from writing to the current directory anyway. If the user has admin rights than very little can be done to stop interference. There are numerous other ways to accomplish the same thing without any extra effort. I don't think this change is worth the engineering effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:17:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:17:10 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again Message-ID: <046.654ae7ec185238832f995e60e758edd9@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #12634 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code {{{#!hs {-# LANGUAGE RankNTypes, TypeFamilies #-} module Panic where class C a where data T a panic :: (forall s . T a) -> () instance C () where data T () = T panic T = () }}} produces the output {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): piResultTys1 R:T() [Any] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:17:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:17:59 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.6845bdbe8628c13a63bbb68b73878dd1@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pjmagni): * Attachment "dcore-lint.txt" added. Output of ghc -dcore-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:20:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:20:04 -0000 Subject: [GHC] #7687: ghc panic on TH and deriveJSON In-Reply-To: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> References: <044.a32c208c745370fae93ea4e1da30c72b@haskell.org> Message-ID: <059.ac4ebf3965f98f3a23463a71d904af93@haskell.org> #7687: ghc panic on TH and deriveJSON -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: invalid | Keywords: TH Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: No information provided in 4 years. Also dynamic linker has been changed. This error case doesn't exist anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:28:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:28:31 -0000 Subject: [GHC] #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy In-Reply-To: <045.b8eb2c07dd94bd4b761d87f0dd3ec4bc@haskell.org> References: <045.b8eb2c07dd94bd4b761d87f0dd3ec4bc@haskell.org> Message-ID: <060.a4d143e07ee516b57a9fb3a4f96786e0@haskell.org> #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy --------------------------------------+------------------------------ Reporter: blippy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+------------------------------ Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: No information in 10 months. Closing ticket as not reproducable. The fact that cabal works indicates this is a stack issue. If this still happens in 8.0.1 report the bug to stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:31:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:31:26 -0000 Subject: [GHC] #10881: internal error: evacuate: strange closure type 5101248 In-Reply-To: <045.d8291d7d3474f8067bb2d61da8cd20dc@haskell.org> References: <045.d8291d7d3474f8067bb2d61da8cd20dc@haskell.org> Message-ID: <060.6b34e2ae39d21bd4075850b1ef53cbb4@haskell.org> #10881: internal error: evacuate: strange closure type 5101248 -------------------------------------+------------------------------------- Reporter: burbly | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: invalid | Keywords: strange | closure type 5101248 Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * cc: simonmar (added) * resolution: => invalid Comment: No answer, and no reproduction steps in 13 months. Closing issue as we can't fix it without being able to reproduce it. Feel free to re-open if a reproduction case is made. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 20:37:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 20:37:02 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.b5ae520606d8dff45bf8c65c8bfd59dc@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: This bug is quite old, and given that the GHC api has changed a lot in the meantime and that BuildWrapper is dead and unsupported we can't really reproduce this on the current GHC. I am therefore closing this ticket. But feel free to re-open if you have a simple repro on GHC 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:38:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:38:36 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.3318f978c37bf77748c23d72067ae38a@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can reproduce this with master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:40:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:40:42 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.8d1c914f29142f27c190dfc3b52dab73@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2579 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: D2579 => Phab:D2579 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:55:04 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.4dccd1ca03686f720554863a81291d8a@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2579 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8dc72f3c33b0e724ddb690c9d494969980c10afd/ghc" 8dc72f3c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8dc72f3c33b0e724ddb690c9d494969980c10afd" Cleanup PosixSource.h When trying to build arm64-apple-iso, the build fell over `strdup`, as the arm64-apple-ios build did not fall into `darwin_HOST_OS`, and would need `ios_HOST_OS`. This diff tries to clean up PosixSource.h, instead of layering another define on top. As we use `strnlen` in sources that include PosixSource.h, and `strnlen` is defined in POSIX.1-2008, the `_POSIX_C_SOURCE` and `_XOPEN_SOURCE` are increased accordingly. Furthermore the `_DARWIN_C_SOURCE` (required for `u_char`, etc. used in sysctl.h) define is moved into `OSThreads.h` alongside a similar ifdef for freebsd. Test Plan: Build on all supported platforms. Reviewers: austin, simonmar, erikd, kgardas, bgamari Reviewed By: simonmar, erikd, kgardas, bgamari Subscribers: Phyx, hvr, thomie Differential Revision: https://phabricator.haskell.org/D2579 GHC Trac Issues: #12624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:55:04 -0000 Subject: [GHC] #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin In-Reply-To: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> References: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> Message-ID: <061.30e552c14c4467a46d63644a2fd525c3@haskell.org> #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2584 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7b060e12efbfed2f29136fd605f76e8d6ca79f85/ghc" 7b060e12/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b060e12efbfed2f29136fd605f76e8d6ca79f85" Generate a unique symbol for signature object stub files, fixes #12673 Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2585 GHC Trac Issues: #12673 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:55:04 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.23b25b8176c7a45f3698097b549d55c7@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1a9705c32f6841be8bc6df3c1084a50dacba2730/ghc" 1a9705c3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a9705c32f6841be8bc6df3c1084a50dacba2730" Escape lambda. Test Plan: View updated documentation? Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2583 GHC Trac Issues: #12672 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:55:04 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.9c65c95f660324ac8b057fb2b886ec2c@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"85e81a850a3e79d965e18f267a0e0b1c4bc69fae/ghc" 85e81a8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85e81a850a3e79d965e18f267a0e0b1c4bc69fae" Turn on -n4m with -A16m or greater Nursery chunks help reduce the cost of GC when capabilities are unevenly loaded, by ensuring that we use more of the available nursery. The rationale for enabling this at -A16m is that any negative effects due to loss of cache locality are less likely to be an issue at -A16m and above. It's a conservative guess. If we had a lot of benchmark data we could probably do better. Results for nofib/parallel at -N4 -A32m with and without -n4m: ``` ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------ blackscholes 0.0% -9.5% -9.0% -15.0% -2.2% coins 0.0% -4.7% -3.6% -0.6% -13.6% mandel 0.0% -0.3% +7.7% +13.1% +0.1% matmult 0.0% +1.5% +10.0% +7.7% +0.1% nbody 0.0% -4.1% -2.9% 0.085 0.0% parfib 0.0% -1.4% +1.0% +1.5% +0.2% partree 0.0% -0.3% +0.8% +2.9% -0.8% prsa 0.0% -0.5% -2.1% -7.6% 0.0% queens 0.0% -3.2% -1.4% +2.2% +1.3% ray 0.0% -5.6% -14.5% -7.6% +0.8% sumeuler 0.0% -0.4% +2.4% +1.1% 0.0% ------------------------------------------------------------------------ Min 0.0% -9.5% -14.5% -15.0% -13.6% Max 0.0% +1.5% +10.0% +13.1% +1.3% Geometric Mean +0.0% -2.6% -1.3% -0.5% -1.4% ``` Not conclusive, but slightly better. This matters a lot more when you have more cores. Test Plan: validate, nofib/paralel Reviewers: niteria, ezyang, nh2, trofi, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2581 GHC Trac Issues: #9221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 22:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 22:55:04 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.0d8062c9ac0b27e056863d8320efdef1@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c47f2efa3f8f4639f375d34f54c01a60c9a1a82/ghc" 6c47f2ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c47f2efa3f8f4639f375d34f54c01a60c9a1a82" Default +RTS -qn to the number of cores Setting a -N value that is too large has a dramatic negative effect on performance, but the new -qn flag can mitigate the worst of the effects by limiting the number of GC threads. So now, if you don't explcitly set +RTS -qn, and you set -N larger than the number of cores (or use setNumCapabilities to do the same), we'll default -qn to the number of cores. These are the results from nofib/parallel on my 4-core (2 cores x 2 threads) i7 laptop, comparing -N8 before and after this change. ``` ------------------------------------------------------------------------ Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------ blackscholes +0.0% +0.0% -72.5% -72.0% +9.5% coins +0.0% -0.0% -73.7% -72.2% -0.8% mandel +0.0% +0.0% -76.4% -75.4% +3.3% matmult +0.0% +15.5% -26.8% -33.4% +1.0% nbody +0.0% +2.4% +0.7% 0.076 0.0% parfib +0.0% -8.5% -33.2% -31.5% +2.0% partree +0.0% -0.0% -60.4% -56.8% +5.7% prsa +0.0% -0.0% -65.4% -60.4% 0.0% queens +0.0% +0.2% -58.8% -58.8% -1.5% ray +0.0% -1.5% -88.7% -85.6% -3.6% sumeuler +0.0% -0.0% -47.8% -46.9% 0.0% ------------------------------------------------------------------------ Min +0.0% -8.5% -88.7% -85.6% -3.6% Max +0.0% +15.5% +0.7% -31.5% +9.5% Geometric Mean +0.0% +0.6% -61.4% -63.1% +1.4% ``` Test Plan: validate, nofib/parallel benchmarks Reviewers: niteria, ezyang, nh2, austin, erikd, trofi, bgamari Reviewed By: trofi, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2580 GHC Trac Issues: #9221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 23:06:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 23:06:16 -0000 Subject: [GHC] #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin In-Reply-To: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> References: <046.6403f7d55ebb57a2e66f14361514aaf0@haskell.org> Message-ID: <061.001a6aa1fbec3800c76d7e650077b4e7@haskell.org> #12673: bkpcabal01 testcase fails with spurious output on stderr on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Package system | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2584 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 23:06:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 23:06:53 -0000 Subject: [GHC] #12624: Un-revert PosixSource.h cleanup In-Reply-To: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> References: <046.93cae4ada83be2f494e9edb655402c64@haskell.org> Message-ID: <061.5ab1726fcb5921278c630feb772cc62a@haskell.org> #12624: Un-revert PosixSource.h cleanup -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2579 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 23:07:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 23:07:45 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.0ac52384ff296916cd9cc496251c42df@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 23:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 23:48:04 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.0914a1c76538d2496f01c0cbc65c4547@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Why not in terms of `>=>` {{{#!hs return >=> g = g }}} {{{#!hs g >=> return = g }}} {{{#!hs (f >=> g) >=> h = f >=> (g >=> h) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 9 23:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 09 Oct 2016 23:54:15 -0000 Subject: [GHC] #12677: Type equality in constraint not used? Message-ID: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data TyRep :: forall k. k -> Type where TyInt :: TyRep Int TyBool :: TyRep Bool TyMaybe :: TyRep Maybe TyApp :: TyRep f -> TyRep x -> TyRep (f x) }}} This is allowed: {{{#!hs zero :: TypeRep (a :: Type) -> a zero = undefined }}} but this is not {{{#!hs zero :: Type ~ k => TyRep (a :: k) -> a zero = undefined zero :: TyRep (a :: k) -> Type ~ k => a zero = undefined }}} {{{ tuHu.hs:20:35: error: … • Expected a type, but ‘a’ has kind ‘k’ • In the type signature: zero :: Type ~ k => R (a :: k) -> a Compilation failed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 00:23:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 00:23:48 -0000 Subject: [GHC] #12678: -threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC Message-ID: <045.d0b8945e0c1949136d7a483f9db43fd0@haskell.org> #12678: -threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi GHC folks. In section 6.1.2.2 of the user's guide it says "Only dynamic flags can be used in an OPTIONS_GHC pragma" and in section 6.6 it says `-threaded` is a dynamic flag. However, the following program compiles successfully but doesn't get linked with the threaded RTS unless I add the option on the command line: {{{#!hs {-# OPTIONS_GHC -threaded #-} main = return () }}} Running `./foo +RTS --info` reports `("RTS way", "rts_v")` when it should say `rts_thr`. Either `-threaded` should be settable in `OPTIONS_GHC` pragmas, or setting it should be an error that aborts compilation. The documentation should accurately state the rules regardless. This happens on 8.0.1, 7.10.3 and the `ghc-8.0` branch. I didn't check master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 00:36:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 00:36:51 -0000 Subject: [GHC] #12678: -threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC In-Reply-To: <045.d0b8945e0c1949136d7a483f9db43fd0@haskell.org> References: <045.d0b8945e0c1949136d7a483f9db43fd0@haskell.org> Message-ID: <060.2da5a07e0a2a1b4f1e206ee343c9c5b2@haskell.org> #12678: -threaded is listed as a dynamic flag but is silently ignored in OPTIONS_GHC -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the other rule is that `OPTIONS_GHC` only affects compile-time flags, not link-time flags. One could imagine that for an executable the main module's `OPTIONS_GHC` are used at link time but it doesn't work that way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 06:40:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 06:40:33 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * Message-ID: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a fascinating program that I would like to write, but cannot with Backpack today: {{{ unit p where signature Key where import GHC.Exts (Constraint) data Key k :: Constraint instance Key Bool signature Map where import Key data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a signature Keys where import Map module M where import Map import Key x = insert True "foo" empty }}} `data Key k :: Constraint` is implementable, because we can implement abstract data types using type synonyms in Backpack, and synonyms can have more kinds than just `*`. However, GHC chokes on this declaration, because it thinks that data types always have to have kind `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 06:40:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 06:40:50 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.a42509bcfe0b36790d2730476a9c08dd@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -16,2 +16,0 @@ - signature Keys where - import Map New description: Here is a fascinating program that I would like to write, but cannot with Backpack today: {{{ unit p where signature Key where import GHC.Exts (Constraint) data Key k :: Constraint instance Key Bool signature Map where import Key data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a module M where import Map import Key x = insert True "foo" empty }}} `data Key k :: Constraint` is implementable, because we can implement abstract data types using type synonyms in Backpack, and synonyms can have more kinds than just `*`. However, GHC chokes on this declaration, because it thinks that data types always have to have kind `*`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 06:41:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 06:41:41 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.30362bfa8706f6c4450e0276556ee202@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -22,0 +22,3 @@ + The point is to make the *constraint* for Map parametrizable, so that + HashMap can levy a different constraint (Hashable) than Map (Ord). + New description: Here is a fascinating program that I would like to write, but cannot with Backpack today: {{{ unit p where signature Key where import GHC.Exts (Constraint) data Key k :: Constraint instance Key Bool signature Map where import Key data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a module M where import Map import Key x = insert True "foo" empty }}} The point is to make the *constraint* for Map parametrizable, so that HashMap can levy a different constraint (Hashable) than Map (Ord). `data Key k :: Constraint` is implementable, because we can implement abstract data types using type synonyms in Backpack, and synonyms can have more kinds than just `*`. However, GHC chokes on this declaration, because it thinks that data types always have to have kind `*`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 06:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 06:46:04 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures Message-ID: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- David Christiansen requested this, and I want to record it so I don't forget. What he wants to be able to do is say things like this in signatures: {{{ signature A where data T data S type family F a instance T ~ S instance F Int ~ S }}} This is currently rejected by GHC because you are not allowed to define instances of type equality. But really all this is saying is that the type equality must hold when we eventually implement the module; easy to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 07:43:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 07:43:32 -0000 Subject: [GHC] #12677: Type equality in constraint not used? In-Reply-To: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> References: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> Message-ID: <066.2026fa0f412158bebb080b29ef5749f3@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by mpickering: @@ -2,0 +2,6 @@ + {-# LANGUAGE TypeInType #-} + {-# LANGUAGE GADTs #-} + {-# LANGUAGE RankNTypes #-} + + import Data.Kind + @@ -7,0 +13,3 @@ + + zero :: Type ~ k => TyRep (a :: k) -> a + zero = undefine @@ -9,1 +18,1 @@ - This is allowed: + fails with the error @@ -11,1 +20,9 @@ - {{{#!hs + {{{ + ttest.hs:13:39: error: + • Expected a type, but ‘a’ has kind ‘k’ + • In the type signature: zero :: Type ~ k => TyRep (a :: k) -> a + }}} + + But if you replace `zero` with + + {{{ @@ -16,17 +33,1 @@ - but this is not - - {{{#!hs - zero :: Type ~ k => TyRep (a :: k) -> a - zero = undefined - - zero :: TyRep (a :: k) -> Type ~ k => a - zero = undefined - }}} - - {{{ - tuHu.hs:20:35: error: … - • Expected a type, but ‘a’ has kind ‘k’ - • In the type signature: - zero :: Type ~ k => R (a :: k) -> a - Compilation failed. - }}} + then the program compiles. New description: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} import Data.Kind data TyRep :: forall k. k -> Type where TyInt :: TyRep Int TyBool :: TyRep Bool TyMaybe :: TyRep Maybe TyApp :: TyRep f -> TyRep x -> TyRep (f x) zero :: Type ~ k => TyRep (a :: k) -> a zero = undefine }}} fails with the error {{{ ttest.hs:13:39: error: • Expected a type, but ‘a’ has kind ‘k’ • In the type signature: zero :: Type ~ k => TyRep (a :: k) -> a }}} But if you replace `zero` with {{{ zero :: TypeRep (a :: Type) -> a zero = undefined }}} then the program compiles. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 07:45:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 07:45:13 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.8e16cac85767ad4bd3e88b382b391199@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Please open a new ticket if you think so! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 08:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 08:35:35 -0000 Subject: [GHC] #12681: Missing fields warning when qualified records are initialized with unqualified field names Message-ID: <044.c445f1fd9a044eeb249ef2fce7934ce3@haskell.org> #12681: Missing fields warning when qualified records are initialized with unqualified field names -------------------------------------+------------------------------------- Reporter: lyxia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code leads to a misleading warning. {{{#!hs -- A.hs module A where data A = A { a :: Int } -- B.hs module B where import qualified A x = A.A { a = 0 } }}} GHC warns {{{ A.hs:5:5: warning: [-Wmissing-fields] • Fields of ‘A.A’ not initialised: a • In the expression: A.A {a = 0} In an equation for ‘x’: x = A.A {a = 0} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 09:05:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 09:05:34 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.90f92692aa9cfe2e055efe009aedb4ef@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 simonpj): This is, I think, another example of the tension between `Constraint` and `*`. See #11715. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 09:19:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 09:19:36 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.72d494930814a68fd003b807ed82e92d@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Comment (by trommler): Replying to [comment:50 basvandijk]: > I fixed the error in haskell-opencv. Somebody at the Haskell eXchange mentioned it could have something to do with the recent [https://nixos.org/nixpkgs/manual/#sec-hardening-in-nixpkgs hardening changes in NixOS-16.09]. It turned out that the `bindnow` feature was causing the problem. After [https://github.com/LumiGuide/haskell- opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4 disabling] the feature the library is building successfully. OK, so the issue is caused by an additional linker flag and is not a duplicate of #11499 after all. Let's revisit this after #11238. Would you mind creating a new ticket and mark it blocked on #11238? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 09:59:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 09:59:36 -0000 Subject: [GHC] #12682: ASSERT failures in testsuite Message-ID: <046.d518698d1f920b614ada882990c78990@haskell.org> #12682: ASSERT failures in testsuite -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Joachim [https://mail.haskell.org/pipermail/ghc- devs/2016-October/013000.html writes]: our secondary CI infrastructure is in bad shape since a week. The first push that broke it was the one ending with commit fc4ef66 by SPJ: * fc4ef66 - Comments only (vor 7 Tagen) * b612da6 - Fix impredicativity (again) (vor 7 Tagen) * 3012c43 - Add Outputable Report in TcErrors (vor 7 Tagen) * 66a8c19 - Fix a bug in occurs checking (vor 7 Tagen) * 2fbfbca - Fix desugaring of pattern bindings (again) (vor 7 Tagen) * 0b533a2 - A bit of tracing about flattening (vor 7 Tagen) {{{ --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ /tmp/ghctest-gSX4vv/test spaces/./boxy/Base1.run/Base1.comp.stderr.normalised 2016-09-30 12:44:57.182659875 +0000 @@ -0,0 +1,18 @@ + +Base1.hs:20:13: + Couldn't match type ‘a0 -> a0’ with ‘forall a. a -> a’ + Expected type: MEither Sid b + Actual type: MEither (a0 -> a0) b + In the expression: MLeft fid + In an equation for ‘test1’: test1 fid = MLeft fid + +Base1.hs:25:39: + Couldn't match type ‘a1 -> a1’ with ‘forall a. a -> a’ + Expected type: Maybe (Sid, Sid) + Actual type: Maybe (a1 -> a1, a2 -> a2) + In the expression: Just (x, y) + In a case alternative: MRight y -> Just (x, y) + In the expression: + case m of { + MRight y -> Just (x, y) + _ -> Nothing } *** unexpected failure for Base1(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_aAI Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2Freportabug&data=01%7C01%7Csimonpj%40microsoft.com%7Cb15d11554ecf4f68173d08d3ee64ef42%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=eG%2F4%2FH6lhGUFjL1my3GUE5Ho1hP3C4j0tkEihKvddyQ%3D&reserved=0 *** unexpected failure for RaeBlogPost(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! m_awK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:979:47 in ghc:TcType Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2Freportabug&data=01%7C01%7Csimonpj%40microsoft.com%7Cb15d11554ecf4f68173d08d3ee64ef42%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=eG%2F4%2FH6lhGUFjL1my3GUE5Ho1hP3C4j0tkEihKvddyQ%3D&reserved=0 *** unexpected failure for TypeLevelVec(normal) }}} A subsequent commit by SPJ fixed the first one. It now compield without -DDEBUG again, but the other two failures (observable only with -DDEBUG) are still there. Since then, Travis has been reporting failures for the master branch. I only noticed now as I pushed something to master, and I got an email. Did you not get notifications about the breakage? If you did, was it unclear how to get to the log file? In any case: Simon, could you have a look and see if the ASSERT is pointing out a real bug introduced with your commits, or whether the ASSERT is wrong, so that we can build master with -DDEBUG again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 10:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 10:07:47 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.1caa1247c03c16d2547c7796a35b0cbe@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:27 trommler]: > Replying to [comment:25 simonmar]: > > If a `sync` fixes it then that would be a useful data point. If not, it means there are barriers missing elsewhere. > I had not seen your comment on moving the write barrier. > > If that was indeed the problem then there is a data dependency and we don't have to worry about a load-load barrier on PowerPC (and ARM). > > I'll do a test build on a PowerPC 970MP and a POWER8. On POWER8 I still see a few panics in `mkFastStringWith` and on build service (qemu on POWER8 hardware) one panic with `ARR_WORDS object entered`. A couple of packages fail with segfaults in `Setup build`. The PowerMac (PowerPC 970) build is still running. So far no panic but about the same number of packages as before fail in `Setup build`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 10:07:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 10:07:56 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.ff8b3569091fa0c6acce65a0ccf44b2d@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Does this still guarantee {{{ read "xxxx" == xxxx }}} for every {{{Fractional}}} literal {{{xxxx}}} that parses, for all built- in instances of `Fractional`? I believe we have that guarantee now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 10:51:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 10:51:21 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.9468a835137747c255fe5fa0e3c938ee@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b255ae7b555b4b63085a6de4a7a6bd742326b9c9/ghc" b255ae7b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b255ae7b555b4b63085a6de4a7a6bd742326b9c9" Orient improvement constraints better This patch fixes an infinite loop in the constraint solver, shown up by Trac #12522. The solution is /very/ simple: just reverse the orientation of the derived constraints arising from improvement using type-family injectivity. I'm not very proud of the fix --- it seems fragile --- but it has the very great merit of simplicity, and it works fine. See Note [Improvement orientation] in TcInteract, and some discussion on the Trac ticket. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 10:51:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 10:51:21 -0000 Subject: [GHC] #12682: ASSERT failures in testsuite In-Reply-To: <046.d518698d1f920b614ada882990c78990@haskell.org> References: <046.d518698d1f920b614ada882990c78990@haskell.org> Message-ID: <061.1930d93fc63a8292b7f9a5a7627064e6@haskell.org> #12682: ASSERT failures in testsuite -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"76a5477b86c66c52854d8d4fbabbd15ce128fa83/ghc" 76a5477b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="76a5477b86c66c52854d8d4fbabbd15ce128fa83" Move zonking out of tcFamTyPats In tcFamTyPats we were zonking from the TcType world to the Type world, ready to build the results into a CoAxiom (which should have no TcType stuff. But the 'thing_inside' for tcFamTyPats also must be zonked, and that zonking must have the ZonkEnv from the binders zonked tcFamTyPats. Ugh. This caused an assertion failure (with DEBUG on) in RaeBlobPost and TypeLevelVec, both in tests/dependent, as shown in Trac #12682. Why it hasn't shown up before now is obscure to me. So I moved the zonking stuff out of tcFamTyPats to its three call sites, where we can do it all together. Very slightly longer, but much more robust. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 10:56:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 10:56:03 -0000 Subject: [GHC] #12682: ASSERT failures in testsuite In-Reply-To: <046.d518698d1f920b614ada882990c78990@haskell.org> References: <046.d518698d1f920b614ada882990c78990@haskell.org> Message-ID: <061.daa5211d980528b52b725fb852d5345f@haskell.org> #12682: ASSERT failures in testsuite -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed Comment: I claim I've fixed these. Thanks Joachim. (Can you check?) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 11:55:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 11:55:35 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.085527747492a0235a2cab109c5fb7ee@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Iceland_Jack, personally I think it is probably best that we state the laws in terms of the typeclass methods although I do agree that the symmetry of the `>=>` formulation is compelling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 12:29:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 12:29:00 -0000 Subject: [GHC] #12683: Monad laws in terms of fishes (>=>) Message-ID: <051.f8447a3ab534fa323c41db69adf1fcce@haskell.org> #12683: Monad laws in terms of fishes (>=>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12672 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Present monad laws with Kleisli composition (fish operator) {{{#!hs return >=> g = g g >=> return = g (f >=> g) >=> h = f >=> (g >=> h) }}} instead of bind: {{{#!hs return a >>= k = k a m >>= return = m m >>= (\x -> k x >>= h) = (m >>= k) >>= h }}} Even though `>>=` is a method of `Monad` this is so much clearer that I think it's worth it, started as ticket:12672#comment:4 ---- Fun mention: [http://www.cse.chalmers.se/~jomoa/papers/quickspec2016.pdf QuickSpec] doesn't generate lambda terms so it will not discover `(xs >>= f) >>= g` = `xs >>= (\x -> f x >>= g)` so it needs to be in terms of `>=>`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 12:30:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 12:30:22 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.e822350e4419e63d88336267d6825744@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:6 bgamari]: I would normally agree but it is compelling, created #12683 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 12:46:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 12:46:28 -0000 Subject: [GHC] #12665: Make Read instances faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.8cef85501ce2d1d5b848868ccfb9f878@haskell.org> #12665: Make Read instances faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:15 YitzGale]: > Does this still guarantee > {{{ > read "xxxx" == xxxx > }}} > for every {{{Fractional}}} literal {{{xxxx}}} that parses, for all built-in instances of `Fractional`? I believe we have that guarantee now. Thanks to the type-directed nature of `Read`, it shouldn't affect them one bit. And if it does, we can certainly fix that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 12:48:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 12:48:20 -0000 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@haskell.org> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@haskell.org> Message-ID: <060.de688a4705d626a4c92cddfa896e37a0@haskell.org> #1969: enormous compile times -------------------------------------------------+------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12 | branch Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: | performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: T1969 -------------------------------------------------+------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cc5ca21b6595d550b27439699cc223c7b0ceab61/ghc" cc5ca21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc5ca21b6595d550b27439699cc223c7b0ceab61" Improved stats for Trac #1969 With my latest commits 76a5477 Move zonking out of tcFamTyPats b255ae7 Orient improvement constraints better perf has improved slightly for T1969: allocs: 733M -> 26M residency: 43M -> 41M I don't know exactly why, but hey, it's good }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 12:57:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 12:57:34 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.142bd1d8f2a754dc7015e537e1efee9c@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a6111b8cc14a5dc019e2613f6f634dec4eb57a8a/ghc" a6111b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6111b8cc14a5dc019e2613f6f634dec4eb57a8a" More tests for Trac #12522 These ones test the variations in coment:15 of the ticket }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 13:01:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 13:01:26 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.dcdd5562f4b9fa5528ff2058151a1bad@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Main bug is fixed, happily. Worth merging. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:01:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:01:09 -0000 Subject: [GHC] #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap In-Reply-To: <045.54937ce05252b15889a7d80403561924@haskell.org> References: <045.54937ce05252b15889a7d80403561924@haskell.org> Message-ID: <060.503c8403794b633ab6d15161ee92fba1@haskell.org> #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 bgamari): * status: new => merge Comment: Merged to `master` as 940ded858157173e75504e8cb0750f059ffd48b9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:01:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:01:57 -0000 Subject: [GHC] #11819: Full validation issues for 8.0.1 In-Reply-To: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> References: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> Message-ID: <061.1485395dff0b732bf07894a6c077e4d8@haskell.org> #11819: Full validation issues for 8.0.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 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 bgamari): The commit mentioned in comment:3 was merged to `ghc-8.0` as 5c01763e2fa7cd9bb5f08fad713cb03b97a07b7f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:02:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:02:35 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.ecf1d84b5906f6f53eaef5dbf67cb38d@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Yes, it is passing 50% (with -qa option and build you gave) so it uses both groups, but not fully still. Please, ask on mailing list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:02:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:02:37 -0000 Subject: [GHC] #12610: Emit tab warning promptly In-Reply-To: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> References: <045.62308f5d5f44e03725bacc3f54950ebc@haskell.org> Message-ID: <060.d3cc89448230d11d422cd809d346d22e@haskell.org> #12610: Emit tab warning promptly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: I don't think this will happen for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:03:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:03:03 -0000 Subject: [GHC] #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers In-Reply-To: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> References: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> Message-ID: <061.14a3c1dc35924d30cc647ec8b1ccca52@haskell.org> #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternSynonyms 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 bgamari): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:05:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:05:52 -0000 Subject: [GHC] #11990: Custom Type Error not getting triggered in the nested Type function call In-Reply-To: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> References: <047.cd64e02ac6207e6c5247bec38dfaa3ba@haskell.org> Message-ID: <062.daa9e966dd1c4bd726b6688e8db0d960@haskell.org> #11990: Custom Type Error not getting triggered in the nested Type function call -------------------------------------+------------------------------------- Reporter: magesh.b | Owner: diatchki Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed Comment: From comment:7 it would seem that there isn't really a bug here, merely implementation details that could be improved in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:12:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:12:13 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.44d6fd1b2901063abb2afc426e3f6547@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Oops, this was incorrectly closed; the performance regression is still present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:31:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:31:20 -0000 Subject: [GHC] #12682: ASSERT failures in testsuite In-Reply-To: <046.d518698d1f920b614ada882990c78990@haskell.org> References: <046.d518698d1f920b614ada882990c78990@haskell.org> Message-ID: <061.26425b148cd1d5323f377b8beb8f78b3@haskell.org> #12682: ASSERT failures in testsuite -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 nomeata): Yes, seems to be the case. Travis still fails, but now somewhere different (Broken window effect?) I’ll report that to the authorities once I found out who to blame. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:38:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:38:01 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.496f8657b4e8b80b75abc378123784f2@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Sadly it looks like this won't be fixed for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:40:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:40:31 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.1f05411998541d36d4440d12c9a79ac5@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 14:55:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 14:55:22 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.f6b48bb1bb42ee4e31550683012d19d6@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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 bgamari): Simon, you should be able to reproduce the issue with the following built with the current state of the `ghc-8.0` branch, {{{ $ git clone git://github.com/goldfirere/th-desugar $ cabal install th-desugar/ $ git clone git://github.com/goldfirere/singletons $ cabal install singletons/ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:02:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:02:03 -0000 Subject: [GHC] #12672: Missing lambda in third monad law description In-Reply-To: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> References: <051.8af1adfdd85366a280fe995a1de1a944@haskell.org> Message-ID: <066.28046474dd8a21785b6c75dc8892c0b9@haskell.org> #12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: vaibhavsagar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: documentation | monad Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2583 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as bdfa8a1ce14b551ce2989ad7fa74ee6b4015c5e1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:02:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:02:27 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.8288bc56f799217401597c79fe066143@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12124 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 5662ceaeb4da4fdee0f9fc01f72855168471377f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:03:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:03:33 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.49981221c6abe703481f513b01d04ed4@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 801cbb42638714004587ba39d1d6b2bbc9ad3b9d and 12cfcbeb93cff0747259e2cc5be652184734a292. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:03:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:03:41 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.1313b6e3cf5887b6764a0d4ab089f22a@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:21:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:21:26 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.a144089080b2475b9404687058328f4e@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 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 simonpj): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:21:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:21:33 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.eff5760dfdd200f2b0eba4c01737afbe@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 bgamari): * version: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:25:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:25:17 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.0d91d8f07bb4063eb15f62568406d270@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by bgamari): trommler, would you like to see Phab:D2525 merged for 8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:27:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:27:48 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking In-Reply-To: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> References: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> Message-ID: <065.fb85ab317bb3f0d9c7ac3c544ed7b2ac@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: goldfire Type: bug | Status: merge Priority: low | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: generalized | newtype deriving roles rankntypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T12616 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:32:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:32:25 -0000 Subject: [GHC] #12559: Don't ignore addTopDecls in module finalizers In-Reply-To: <056.d891faa710239ad090c2d102b89973c3@haskell.org> References: <056.d891faa710239ad090c2d102b89973c3@haskell.org> Message-ID: <071.148151f02700619a76a4352f4bad4d9a@haskell.org> #12559: Don't ignore addTopDecls in module finalizers -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: template- | haskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11832 | Differential Rev(s): Phab:D2505 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as a77bbb8b8c15ef21eab4357248d5d6964c542150. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:57:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:57:14 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.405fe03fd926d8a253c0d822273f006c@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by erikd): Even if @trommler doesn't, I would like to see it in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 15:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 15:57:56 -0000 Subject: [GHC] #12665: Make Read instances for Integral types faster, and make them fail fast (was: Make Read instances faster, and make them fail fast) In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.cdd629c75d26394772f0aae5e592a42c@haskell.org> #12665: Make Read instances for Integral types faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Sorry, I was confused by a parallel conversation on the mailing list about parsers for Float and Double. Now I see that this ticket is only about Integral types. Perhaps the title of this ticket should be changed to make that clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 16:13:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 16:13:38 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.8c9c5c612f5de9d51b2c2e159c671173@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've updated Phab:D2539 with a new approach suggested by Simon. Let's see whether it passes Harbormaster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 16:33:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 16:33:01 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.2c7036d267c7fbe5ba4c652f282be2a0@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:29 bgamari]: > trommler, would you like to see Phab:D2525 merged for 8.0.2? Yes, please include it in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 17:38:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 17:38:49 -0000 Subject: [GHC] #12665: Make Read instances for Integral types faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.f418966e4906e8696a2aefdb26d64650@haskell.org> #12665: Make Read instances for Integral types faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): It's bad enough for integral types: {{{ > reads "\t\n\v\f\r \160\5760\6158\8192\8193\8194\8195\8196\8197\8198\8199\8200\8201\8202\8239\8287\12288 ( ( - 1 ) ) " :: [(Integer,String)] [(-1," ")] }}} (Interestingly, `read "-(1)"` fails) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 18:06:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 18:06:39 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.af942429ae5a076380d052cc334667a4@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): This idea seems reasonable... but your example does not, I'm afraid. If `T` and `S` are datatypes, then how could they be equal? And your `F Int ~ S` seems like it could just be an instance of the type family. On the other hand {{{ data T data S type family F a type family G a instance F T ~ G S }}} seems more realistic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 18:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 18:13:30 -0000 Subject: [GHC] #12677: Type equality in constraint not used? In-Reply-To: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> References: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> Message-ID: <066.8ca49a9d2ddee204238ae80934d87d3c@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): This is a hard one to fix, surprisingly. The problem is that you've declared `a` to have type `k` and then used `a` as an argument to `->`. Of course, `->` expects a `Type`. So GHC should insert add a cast, forming `a |> η`, for the argument to `->`. The problem is that this would require using the equality proof for `Type ~ k` as the body of `η`, and the current type system simply does not allow this. [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality Here] are some notes on the matter, though they were not written to be digested by anyone but me. I don't expect this will be fixed until we have `-XDependentTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 18:42:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 18:42:04 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.e0bb35966fdc687507c4392221d010e4@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): > If T and S are datatypes, then how could they be equal? ``data S`` can be implemented with ``type S = T``, thus making them equal. Admittedly the use of ``data X`` to represent an abstract data type is awful, arguably we should get the syntax ``type X`` working which is a bit clearer. > And your `F Int ~ S` seems like it could just be an instance of the type family. Yes, I think you're right. The important thing is that if you write a type family instance in a signature, it does not indicate that there is *exactly* this reduction rule in the type family, just that it is derivable (though, what about injective type families? Ick.) David was specifically interested in playing around with alternative axiomatizations of type families by specifying equalities manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 18:55:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 18:55:29 -0000 Subject: [GHC] #12684: GHC panic due to bindnow linker flag Message-ID: <049.ae121ad737886820860242fd86c22578@haskell.org> #12684: GHC panic due to bindnow linker flag -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: 11238 Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As [https://ghc.haskell.org/trac/ghc/ticket/10458#comment:45 explained in #10458] our `haskell-opencv` library failed to build on NixOS-16.09 due to its recently introduced [https://nixos.org/nixpkgs/manual/#sec-hardening- in-nixpkgs hardening features]. Specifically the problem is that NixOS is setting the `-z bindnow` linker flag which causes the build to fail with: {{{ ... [33 of 64] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1001/ghc8697_0/libghc_200.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa }}} Fortunately this flag can be [https://github.com/LumiGuide/haskell- opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4 disabled] so I'm now able to build the library successfully. However, it would be nice if GHC is able to work around this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:01:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:01:37 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.29c3f36cb2e5f47d3bdde6d1a00e79cd@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Comment (by basvandijk): OK I created #12684 but I expect this is more of a NixOS issue than a GHC issue. I expect GHC is just calling `ld` which on NixOS is a [https://github.com/NixOS/nixpkgs/blob/release-16.09/pkgs/build-support /cc-wrapper/ld-wrapper.sh wrapper script] setting these hardening flags. So I'm not sure if GHC can fix this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:03:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:03:11 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.453f340fa0f7aafac60fd3c0c62026cd@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): I've not followed the Backpack blow-by-blow, but using `data S` to denote an abstract type of any stripe looks bad to me. `type S` is much better, because users can't make any assumptions about a `type` declaration that they might for a `data` declaration. Separately, you could get yourself into deep water here (not that that's necessary bad): {{{ type Nat type family (a :: Nat) + (b :: Nat) instance a + b ~ b + a }}} Good luck implementing this signature! :) It would be super awesome if the user could prove the equality manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:14:04 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.032bd71a2bf8778ba6c9b32dbfed1a75@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): > type S is much better, because users can't make any assumptions about a type declaration that they might for a data declaration. As far as I could tell, GHC actually doesn't make any assumptions when `data S` denotes an abstract type; so it's just a syntactic wart. It's a bit bothersome to fix because hs-boot syntax only supports data. > It would be super awesome if the user could prove the equality manually. Do you have an example of a case where you could do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:17:58 -0000 Subject: [GHC] #12685: getNumProcessors semantics dont match documentation Message-ID: <043.7166490946f73da79c709fdf98d75140@haskell.org> #12685: getNumProcessors semantics dont match documentation ----------------------------------------+--------------------------------- Reporter: Llgn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hi, The documentation of getNumProcessors says : "Returns the number of CPUs that the machine has", but it is true only for program compiled with -threaded option. https://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-Conc- Sync.html#v:getNumProcessors I guess the documentation is just misleading. Or is it a bug ? Regards -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:26:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:26:53 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.d4fc797d46a16a0e7a155c4e8b39bb7f@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 goldfire): This is an 8.0.2 release blocker, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 19:41:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 19:41:06 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.a29439cf495e44935de2cac5fc75ee7d@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): Replying to [comment:4 ezyang]: > > type S is much better, because users can't make any assumptions about a type declaration that they might for a data declaration. > > As far as I could tell, GHC actually doesn't make any assumptions when `data S` denotes an abstract type; so it's just a syntactic wart. It's a bit bothersome to fix because hs-boot syntax only supports data. I don't agree. In GHC 8: {{{ -- A.hs-boot module A where data T a }}} {{{ -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A foo :: (T a ~ T b) => a -> b foo x = x }}} These compile fine. GHC must be assuming that `T` is injective. So we must proceed cautiously. > > > It would be super awesome if the user could prove the equality manually. > > Do you have an example of a case where you could do this? Nope! :) Hence the level of awesomeness if we could do this. Admittedly well beyond the scope of Backpack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 20:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 20:13:05 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.9dd26014ccde177fe6b73a713f8ae582@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): OK, that looks like a straight up soundness bug. I'll fix it. > Nope! :) Well, I guess what I meant was, what is a situation where you would like this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 20:19:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 20:19:34 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.1f4f2b5f58b58dbc981dba1e8378c92a@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): Replying to [comment:6 ezyang]: > OK, that looks like a straight up soundness bug. I'll fix it. Fix what? I like the current behavior of the hs-boot file, because all `data`-types really are injective. Or do you mean fix what's used in a signature? > Well, I guess what I meant was, what is a situation where you would like this? The `Nat` one (comment:3) is a great starting point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 20:23:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 20:23:57 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.65241ee505fcec2b9b21cbeeeed6e73a@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): > Fix what? I like the current behavior of the hs-boot file, because all data-types really are injective. Or do you mean fix what's used in a signature? What we use in an hsig file. I guess, type synonyms should not be allowed to implement abstract data; and then add a new type construct which doesn't assume injectivity. > The Nat one (comment:3) is a great starting point. So, assuming that you had this equality floating around, would it actually do something useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 10 22:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 10 Oct 2016 22:34:46 -0000 Subject: [GHC] #12686: Attempt to promote a value to a type results in an internal error Message-ID: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> #12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to compile {{{#!hs {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = Zero | Succ Nat data Vec :: * -> Nat -> * where Nil :: Vec a 'Zero Cons :: a -> Vec a n -> Vec a ('Succ n) data Bad = Bad { a :: Nat, b :: Vec Int a} }}} results in `error: Not in scope: type variable ‘a’`. Change the last structure to {{{#!hs data Bad = Bad { a :: Nat, b :: Vec Int 'a} }}} and the result is {{{ • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r15Y :-> ATcTyCon Bad, r17P :-> APromotionErr RecDataConPE] • In the second argument of ‘Vec’, namely ‘a’ In the type ‘Vec Int a’ In the definition of data constructor ‘Bad’ }}} The user is attempting to promote a value to a type, which cannot be done, but the error message should be more informative. Reproduces in 8.0.1 and 8.1.20160916. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 02:00:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 02:00:49 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.9d3f4495dab6f83389ee524bc6ded818@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: BTW, #12411 demonstrates another occurrence of the same error message. I have no idea if Phab:2359 happens to fix that bug too, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 04:16:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 04:16:56 -0000 Subject: [GHC] #12686: Attempt to promote a value to a type results in an internal error In-Reply-To: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> References: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> Message-ID: <061.d0afa0314222d0adedfc024e5c8c0b05@haskell.org> #12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by johnleo: @@ -38,1 +38,1 @@ - Reproduces in 8.0.1 and 8.1.20160916. + Reproduces in 8.0.1 and 8.1.20161010. New description: Trying to compile {{{#!hs {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = Zero | Succ Nat data Vec :: * -> Nat -> * where Nil :: Vec a 'Zero Cons :: a -> Vec a n -> Vec a ('Succ n) data Bad = Bad { a :: Nat, b :: Vec Int a} }}} results in `error: Not in scope: type variable ‘a’`. Change the last structure to {{{#!hs data Bad = Bad { a :: Nat, b :: Vec Int 'a} }}} and the result is {{{ • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r15Y :-> ATcTyCon Bad, r17P :-> APromotionErr RecDataConPE] • In the second argument of ‘Vec’, namely ‘a’ In the type ‘Vec Int a’ In the definition of data constructor ‘Bad’ }}} The user is attempting to promote a value to a type, which cannot be done, but the error message should be more informative. Reproduces in 8.0.1 and 8.1.20161010. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 07:27:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 07:27:54 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.814f3561963079bb24ce287c73cd2cf2@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): Note: another reason you need to distinguish between `type` and `data` is because `type` must have its type arguments saturated (since it may be implemented with a type synonym). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 08:32:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 08:32:21 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.99dff64799db3848242c0d9fdbb9cde3@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): As RyanGlScott pointed out in #12584, essentially the problem is with patterns (here "as" pattern) being accepted (temporarily in the renamer) as expressions. Here is a minimal way to trigger the same error: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTemplateHaskell Prelude> pure @Q [];return () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tcMonoExpr _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 10:58:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 10:58:18 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.ddb44b2268e0e353d40f4389669de717@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Should be fixed by #12584. Let's wait for that to land (it's a tiny patch) and check -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 12:36:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 12:36:47 -0000 Subject: [GHC] #12687: Add a flag to control constraint solving trace Message-ID: <049.a796621b5229aec72ad370435c17f808@haskell.org> #12687: Add a flag to control constraint solving trace -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are flags to control the typechecking and renaming trace (`-dtrace- tc`, `-dtrace-rn`) but the constraint solver trace can't be controlled in this way. It doesn't seem to always be emitted but it the behaviour should be unified with the other tracing functions. `traceTcS` should be implemented in terms of `traceOptTcRn` and a flag added to control the output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 13:21:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 13:21:36 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.4c52613c3c940966bfd7aeca2aff6e9d@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 bgamari): Yes it is -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 13:26:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 13:26:08 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.d1e6f76580062e3df501664584219d8a@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 simonpj): I'm looking at this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 14:24:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 14:24:58 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings Message-ID: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple rebindablesyntax | overloadedstrings deriving show | string | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using both `RebindableSyntax` and `OverloadedStrings`, `deriving (Show)` no longer works. Example program: {{{#!hs {-# LANGUAGE RebindableSyntax, OverloadedStrings #-} module Bug where import Prelude (String,Show(..)) newtype Text = Text String fromString :: String -> Text fromString = Text x :: Text x = "x" newtype Foo = Foo () deriving (Show) }}} In this example, `fromString` is redefined to return a type different from `[Char]`. The example `x` typechecks due to to the `RebindableSyntax` and `OverloadedStrings` extensions. However, the generated code for the `deriving (Show)` instance for Foo does not typecheck, and ghc gives a code generation error: {{{#!hs error: • Couldn't match type ‘Text’ with ‘[GHC.Types.Char]’ Expected type: String Actual type: Text • In the first argument of ‘GHC.Show.showString’, namely ‘"Foo "’ In the first argument of ‘(GHC.Base..)’, namely ‘(GHC.Show.showString "Foo ")’ In the second argument of ‘GHC.Show.showParen’, namely ‘((GHC.Base..) (GHC.Show.showString "Foo ") (showsPrec 11 b1))’ When typechecking the code for ‘showsPrec’ in a derived instance for ‘Show Foo’: To see the code I am typechecking, use -ddump-deriv }}} A solution would be to protect the code generated by `deriving (Show)` from `OverloadedStrings` and `RebindableSyntax` extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 15:12:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 15:12:38 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules Message-ID: <046.137deb6f94373a15da504601d7833b6f@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin-off of https://ghc.haskell.org/trac/ghc/ticket/12618#comment:25: Simon writes there: Actually this is already a problem today. It's just rendered more prominent now that even `(:)` has a wrapper. Consider {{{#!hs data T = MkT {-# UNPACK #-} !Int {-# RULES "fT" f MkT = True "gT" forall x. g (MkT x) = x #-} f :: (Int -> T) -> Bool {-# NOINLINE f #-} f x = True g :: T -> Int {-# NOINLINE g #-} g (MkT x) = x+1 }}} yields {{{ Foo.hs:9:1: warning: [-Winline-rule-shadowing] Rule "fT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' Foo.hs:10:1: warning: [-Winline-rule-shadowing] Rule "gT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' }}} What to do? If we are to match these rules, we really must delay inlining the wrapper for `MkT` (after inlining we get a mess of unboxing etc). So either we must allow you to add a `NOINLINE` pragma to `MkT`; or we must add one automatically (e.g. `NOINLINE [1]`). Delaying all consructor-wrapper inlining to phase 1 is potentially quite drastic, because case-of-known-constructor wouldn't happen until the wrappers are inlined. Maybe that's ok; I'm not sure. Worth trying I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 15:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 15:13:06 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.24b3b1d17fd3f303455d337913a86ced@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): I have opened #12689 for the issue of rules vs. data con wrappers, as it is a separate one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 15:19:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 15:19:42 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.1c3a3cbe084c17934e1c12f2761b0386@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): We might want to look at two separate cases: 1. The LHS mentions a data con (wrapper) unsaturated, (`fT` above). 2. The LHS mentions a data con (wrapper) saturated, (`gT` above). In the first case, I think we should simply disable the warning. Because the wrapper is unsaturated, it will not have been inlined in the code. Unsaturation is as good as `NOINLINE`, isn’t it? Only in the latter case it matters that, as you write > after inlining we get a mess of unboxing etc Is really all hope lost that we can match the mess? My gut feeling is that it is more promising to not work against the inliner and simplifier, and rather let it do its jobs (both on the LHS and the code), and try hard to make the matcher smart enough to match the mess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 16:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 16:38:54 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.250616bdf94fac7b6b934375bc2f6117@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 17:44:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 17:44:19 -0000 Subject: [GHC] #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE Message-ID: <050.65e9f032446da5356b615bc9d51ff90f@haskell.org> #12690: Segmentation fault in GHC runtime system under low memory with USE_LARGE_ADDRESS_SPACE --------------------------------------+---------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I have here a ~600MB core dump on GHC 8.0.1 x86_64 linux triggered under low memory (1GB RAM total, no swap, trying to build aeson with optimizations), with a stacktrace blaming the GHC runtime system. Based on code review, it appears that when requesting memory from the OS fails, the error is ignored and GHC segfaults as soon as it writes to the newly "allocated" memory. == Diagnosis == My diagnosis is that osCommitMemory calls the potentially failing `my_mmap` but returns void (hence not propagating failures); it should instead probably use `my_mmap_or_barf` or handle the failure anyhow: https://github.com/ghc/ghc/blob/a6111b8cc14a5dc019e2613f6f634dec4eb57a8a/rts/posix/OSMem.c#L522-L525 However, while I'm very convinced that's a bug, I'm only mostly confident that's the culprit, since the segfault happens later; I've just looked for bugs on allocation failures in the code ran shortly before the crash. == Raw data == The core dump is on a VM from the reporter of https://github.com/commercialhaskell/stack/issues/2575, https://github.com/jiakai0419, which graciously gave me access to the VM and bothered reporting in the first place—I'd like to thank her. I'd like to avoid copying the dump here unless strictly needed. == Reproduction == The bug is deterministic on that machine, but it requires a failure in mmap without triggering an OOM, so I'm not 100% sure how easy it is to reproduce but it should be easy on a VM with 1GB RAM and 1 core. Here's the output of `free`: {{{ $ free total used free shared buff/cache available Mem: 1015352 95864 71396 51244 848092 733132 Swap: 0 0 0 }}} Instructions to produce a dump. First, as root: {{{ echo /tmp/core > /proc/sys/kernel/core_pattern }}} that's needed because otherwise the core file is produced in a temporary folder that stack removes. Then (as non-root, root has privileged access to memory), install stack, and run: {{{ ulimit -c unlimited git clone https://github.com/jiakai0419/snowflake.git stack build --verbose }}} Below is some raw data from the core dump. In short, an initializer for newly allocated data segfaults, and gdb tells that the address it's trying to write (bd->start) to can't be accessed, even though it's lower than mblock_high_watermark so it should have been committed (mmap'ed) by getFreshMBlocks (I don't get getReusableMBlocks in detail, but it also calls `osCommitMemory`, so I guess there's the same invariant). The existence of mblock_high_watermark (beyond other reasons) should confirm this is using USE_LARGE_ADDRESS_SPACE. If this diagnosis is correct, the bug exists since USE_LARGE_ADDRESS_SPACE was introduced in https://github.com/ghc/ghc/commit/0d1a8d09f452977aadef7897aa12a8d41c7a4af0, so it's a regression in 8.0.1. {{{ (gdb) bt #0 initMBlock (mblock=0x225c00000) at rts/sm/BlockAlloc.c:676 #1 alloc_mega_group (mblocks=mblocks at entry=1) at rts/sm/BlockAlloc.c:328 #2 0x00007fe650438d98 in allocGroup (n=1) at rts/sm/BlockAlloc.c:379 #3 allocGroup (n=1) at rts/sm/BlockAlloc.c:336 #4 0x00007fe65043ed55 in allocBlock_sync () at rts/sm/GCUtils.c:38 #5 0x00007fe65043ef7d in alloc_todo_block (ws=ws at entry=0x13196b0, size=size at entry=3) at rts/sm/GCUtils.c:330 #6 0x00007fe65043f13a in todo_block_full (size=size at entry=3, ws=0x13196b0) at rts/sm/GCUtils.c:292 #7 0x00007fe65041baed in alloc_for_copy (gen_no=, size=3) at rts/sm/Evac.c:81 #8 copy_tag (tag=2, gen_no=, size=3, src=0x21b353868, info=, p=0x225b13f10) at rts/sm/Evac.c:99 #9 evacuate1 (p=p at entry=0x225b13f10) at rts/sm/Evac.c:596 #10 0x00007fe65041d65c in scavenge_block1 (bd=0x225b004c0) at rts/sm/Scav.c:570 #11 0x00007fe6504415dc in scavenge_find_work () at rts/sm/Scav.c:2040 #12 scavenge_loop1 () at rts/sm/Scav.c:2103 #13 0x00007fe65043cee2 in scavenge_until_all_done () at rts/sm/GC.c:968 #14 0x00007fe65043d75a in GarbageCollect (collect_gen=collect_gen at entry=1, do_heap_census=do_heap_census at entry=rtsFalse, gc_type=gc_type at entry=2, cap=cap at entry=0x7fe650669a80 ) at rts/sm/GC.c:403 #15 0x00007fe65042ff81 in scheduleDoGC (force_major=rtsFalse, task=0x13228a0, pcap=) at rts/Schedule.c:1652 #16 scheduleDoGC (pcap=, task=0x13228a0, force_major=rtsFalse) at rts/Schedule.c:1433 #17 0x00007fe650430c1a in schedule (initialCapability=initialCapability at entry=0x7fe650669a80 , task=task at entry=0x13228a0) at rts/Schedule.c:551 #18 0x00007fe650431cf8 in scheduleWaitThread (tso=0x20000b388, ret=ret at entry=0x0, pcap=pcap at entry=0x7ffc4ee22c08) at rts/Schedule.c:2361 #19 0x00007fe65042c528 in rts_evalLazyIO (cap=cap at entry=0x7ffc4ee22c08, p=p at entry=0x7895c0, ret=ret at entry=0x0) at rts/RtsAPI.c:500 #20 0x00007fe65042e3a7 in hs_main (argc=96, argv=0x7ffc4ee22dc8, main_closure=0x7895c0, rts_config=...) at rts/RtsMain.c:64 #21 0x0000000000428414 in main () (gdb) info locals bd = 0x225c00100 block = 0x225c04000
(gdb) print/x mblock_high_watermark $11 = 0x225d00000 (gdb) print bd->start Cannot access memory at address 0x225c00100 (gdb) print *bd Cannot access memory at address 0x225c00100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 17:55:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 17:55:23 -0000 Subject: [GHC] #12574: Consistent use of sigs vs signatures in warnings In-Reply-To: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> References: <047.2ab88062e8f1967d3b0dbb931f7be22c@haskell.org> Message-ID: <062.0693d00b7cc3f7c11a15a1a9d7cc4643@haskell.org> #12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11583, #10752 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 19:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 19:52:06 -0000 Subject: [GHC] #12687: Add a flag to control constraint solving trace In-Reply-To: <049.a796621b5229aec72ad370435c17f808@haskell.org> References: <049.a796621b5229aec72ad370435c17f808@haskell.org> Message-ID: <064.7962588bf334e3568ef982fbaa9f58b8@haskell.org> #12687: Add a flag to control constraint solving trace -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 mpickering): It seems there is a flag `-ddump-cs-trace` but `csTraceTcM` implements it's own logic which should be unified with the logic in `traceOptTcRn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 20:23:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 20:23:17 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.d2f2bbb7f7e31b33d14252d86a95167b@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): Has anybody, say ilovezfs, produced a core dump/backtrace from this? That would be immensely helpful. (I'm not familiar with the OS X incantations unfortunately, but see http://stackoverflow.com/a/21308843/53974). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 20:28:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 20:28:18 -0000 Subject: [GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level Message-ID: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> #12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It wasn't clear to me what these flags should do and what they should turn off. From the user guide. `-dno-debug-output`:: Suppress any unsolicited debugging output. When GHC has been built with the DEBUG option it occasionally emits debug output of interest to developers. The extra output can confuse the testing framework and cause bogus test failures, so this flag is provided to turn it off. `-dtrace-level`:: Not present `-dno-debug-output` currently suppresses the output of `-ddump-tc-trace` which is certainly not "unsolicited". It should be used, and is, in `Outputable` to suppress the output of `pprTrace`. `dtrace-level` is used in a few places but always as if was a boolean flag. I don't really see what the point of it is. The only commit which mentions it is "8cdb98b9909561671ab4e61c90ebb12504478e4d" and I can't find the origin of the flag. I think we should just remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 20:43:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 20:43:00 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.76f662ddc96a043cb1d3107e62d3f4f8@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Joachim Breitner ): In [changeset:"b5be2ec33c395e3e092baf85ebd0696f233ad706/ghc" b5be2ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5be2ec33c395e3e092baf85ebd0696f233ad706" Add test case for #12689 which test a few variants of rules involving constructors, including nullary constructors, constructors with wrappers, and unsaturated of constructors. At the moment, all the rules work as expected, despite GHC’s compile time warnings when called with -Wall. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 20:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 20:52:06 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.4d3f9bf589d43dd6d23dab51ca656d4b@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Joachim Breitner ): In [changeset:"f8d2c205e04bcb83d39ccbede4c2a6279f702a6b/ghc" f8d2c205/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8d2c205e04bcb83d39ccbede4c2a6279f702a6b" Add a broken test case for #12689 A rule with a phase specification trying to match on a constructor with a wrapper will fail to match, as the wrapper will be inlined by then. The fact that it works in the other case is also mostly by accident. (Split into two test cases so that regressions with regard what works so far are caught.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 20:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 20:57:35 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.b92fc1dea46e1a9c905924b289af29ad@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I have my doubts about the threadsafety of the testsuite. In particular, the location of the function that's failing is right after a `rmtree` call that's supposed to ensure the path doesn't exist. Yet it does. Also I see that only relative paths are used in all directory name. I can only assume that it's relative to the `cwd` as explicit shell commands are issued to change the shell's `cwd`. Why the python call for this is not used I don't understand. I must be missing something since this is reliably working on Linux.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 21:16:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 21:16:02 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.db9f737c2690541f79c0d904637a3ecd@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yeah some sets are failing, I'm looking into it. In the mean time, I've asked, and you can read the replies here http://haskell.1045720.n5.nabble.com/Default-options-for-threaded- td5844118.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 21:31:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 21:31:44 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.f93966c13d72322b4b09b49a51f465e9@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Bad :-( So Haskell (compiled with GHC) is not parallel by default. If you see the advertising here https://www.haskell.org/ it speaks loud about concurrency and parallelism. In my code I use 'par' and it doesn't work if there is no compilation + run-time options... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 11 21:49:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 11 Oct 2016 21:49:37 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.4be6d6954b26b3fdb946614dc1bcbd30@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): There's nothing contradictory about what's on the website. It takes 3 flags to make it threaded. Also as the replies said, you can make it the default for your exe so you don't have to specify it when running the application. Surely calling `Control.Concurrent.setNumCapabilities` on startup or using `-with-rtsopts` isn't that prohibitive.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 01:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 01:52:22 -0000 Subject: [GHC] #12692: Can't find interface-file decl with Typeable Message-ID: <047.8081d198b95305daa8d4af7070a41151@haskell.org> #12692: Can't find interface-file decl with Typeable -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached code produces the following error: {{{ GHC error in desugarer lookup in Main: Can't find interface-file declaration for variable $tc'(,) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): initDs IOEnv failure }}} when I run `stack bench lol`. The issue seems to be related to `Typeable` instances for types created with singletons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 01:52:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 01:52:38 -0000 Subject: [GHC] #12692: Can't find interface-file decl with Typeable In-Reply-To: <047.8081d198b95305daa8d4af7070a41151@haskell.org> References: <047.8081d198b95305daa8d4af7070a41151@haskell.org> Message-ID: <062.22bebf46cd613ef641d4b88ae0098c6d@haskell.org> #12692: Can't find interface-file decl with Typeable -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "bug.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 08:06:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 08:06:09 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.8d59056d80d943941c1314522f79841e@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): For the most part, I think we want an "abstract type synonym" to behave like an open type family with no (known) equations. So wherever we see `type S :: * -> *`, it should be as if we see `type family S :: * -> *`. We must relax the signature matching rules to allow a type family to be implemented using a type synonym. I think it's sound to behave this way, because `type S = Foo` can always be interpreted as `type instance S = Foo`. There is two things to watch out for, however. First, consider the following program: {{{ signature H where type S f :: Int module M where type S = Int f :: S }}} We would like M to match H, but if S is an open type family, the match will fail: S is not definitionally equal to Int, and matching is done strictly with definitional equality. I don't think we should change this for now: with more complex matching we will have to generate coercions to keep Core well-typed. So, instead, we just want to replace the open type family tycon with a type synonym tycon (in the same way an abstract algebraic data type gets replaced with the full data type). This is only sound if, when a module typechecks, it continues to typecheck if more definitional equalities hold. This is actually not true; `instance Show T` and `instance Show S` will overlap if T is definitionally equal to S! But we knew that already: we can implement an abstract algebraic data type with a reexport (which will cause more definitional equalities to hold), and fortunately, Scott showed that this *is* sound in Haskell without instances, so it will do something vaguely reasonable. So, that was a really long way of justifying why we can't just search replace `type S` with `type family S` and `type S = Int` with `type family S = Int`. Second, consider the following program: {{{ signature H where type F a instance Show a => Show (F a) }}} We'd really like this to work. But if F is implemented with type family (or a type synonym to a type family), this instance is illegal and can't be implemented. So what we want to be able to say is that `type F a` can be implemented with a type synonym, but *only* a type synonym with no type families in it. There doesn't seem to be a good way to make a claim like this in the language. But given that ``type family F a`` is still a fair way to specify a type family, perhaps the correct thing to do in this case is to just say that an abstract type can only be implemented by a type synonym with no type families, and check that upon matching. So the abstract type synonym really is a beast of its own: it is like an open type synonym family (in that it is not reducible, but could become reducible in the future), BUT it should still be accepted in instances, because once we *do* know how it's reducible, there will be no more type families left. By the way, this discussion informed me of another problem: {{{ {-# LANGUAGE TypeFamilies #-} unit bar where signature H1 where data T signature H2 where data T module M where import qualified H1 import qualified H2 f :: (H1.T ~ H2.T) => a -> b f x = x }}} This typechecks! Today, the solver concludes that ``H1.T ~ H2.T`` is insoluble and accepts the rest of the function. But if H1 and H2 are instantiated in the same way, this equality could hold! So, for abstract data types from signatures (not boots) we better treat this differently. So let us summarize: * Abstract data types `data T a` can be implemented by a data type or newtype declaration. We can assume that they are injective on all type parameters and can be used in instances. * Abstract type synonyms `type T a` can be implemented by a type synonym (with no type families), data type or newtype declaration. They can be used in instances. Arguably it should be possible to specify their injectivity (in the absence of type families, they are either injective or not used at all). I guess it should also be possible to specify their role. * Open type families `type family T a` can be implemented by a type family, type synonym, data type or newtype. Injectivity can be specified in the usual way. Roles are irrelevant. Abstract type synonyms should probably be implemented as abstract data types that are not assumed to be injective; furthermore, both abstract data types and abstract type synonyms need to account for the fact that they might eventually become definitionally equal to something else. I am not so sure how this should happen; if we model off of open type families, the correct thing to do is flatten it with a fresh skolem variable, but this will thwart instance declarations, which is undesirable. So we will need to do something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 08:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 08:07:05 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.2df34c986384da3c9d97ee30a72221ac@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 10:21:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 10:21:20 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.d93ff40c6b04562b034b3914ce798f07@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 simonpj): I now know what is happening. * At some point we have a Given {{{ [G] Tuple3Sym3 x1 x2 y ~ Tuple3Sym3 n0 n1 n2 }}} * Currently we make derived constraints from injectivity from Givens, so we get {{{ [D] n1 ~ x2 }}} This becomes part of the "model". * Inside a further nest of implication constraints we are processing the Givens, and end up adding this to the inert set: {{{ [G] (n1 - n0) ~ fsk (CFunEqCan) }}} * But since that can be rewritten by the model, we emit a derived "shadow" of the Given: {{{ [D] (n1 - n0) ~ fsk (CNonCanonical) }}} * When processing that Derived constraint, we add {{{ [D] (n1 - n0) ~ fuv (CFunEqCan) }}} to the flat-cache * Now we finish processing the Givens and start doing the Wanteds. We get a hit in the flat-cache, so 'fuv' nwo shows up in the residual wanteds. Then during un-flattening we unify that fuv. At this point the assumption is that CFunEqCan can't reappear. But it's still there in the flat-cache, and when we re-solve the Wanteds we find hit again. But this time fuv is unified and chaos results. What to do? I can think of a number of alternatives. 1. For now the simple thing to do is to start processing the Wanteds with an empty flat-cache. This is easily done in `nestTcS`. But it's unsatisfactory because it discards useful Given entries in the flat-cache. Still, it's a 2-line quick-and-dirty fix that does solve the problem (I tried it). 2. We could address the unsatisfactory aspect of (1) by selectively purging the flat-cache, but I dislike that. Seems like a lot of work (both code and execution time) for an edge case. 3. We could simply not generate derived shadows for Given constraints. This is clean, simple, and will generate fewer deriveds. I have been unable to construct an example where we need to rewrite a Given with a (derived) model constraints to make useful progress. Can anyone else construct one? 4. We could still emit derived shadows from Givens, but in a less aggressive way, so that they don't pollute the flat-cache I'm going to try (3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 11:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 11:34:46 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.af1025387e7725a92cb6754e572e4a81@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"8fa5f5b197542b6e7e9e570991a1488204e606c9/ghc" 8fa5f5b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa5f5b197542b6e7e9e570991a1488204e606c9" Add derived shadows only for Wanted constraints This patch implements choice (3) of comment:14 on Trac #12660. It cures an infinite loop (caused by the creation of an infinite type) in in compiling the 'singletons' package. See Note [Add derived shadows only for Wanteds] in TcSMonad. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 11:38:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 11:38:12 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.67098c396493fb0798998052d6aafa6e@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 simonpj): * status: new => merge Comment: OK, (3) from comment:14 seemed to work. I couldn't come up with a small test case, but `singletons` compiles when I apply this patch to the 8.0 branch. But I have not pushed the patch to 8.0; hence marking this as 'merge' Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 12:05:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 12:05:44 -0000 Subject: [GHC] #12692: Can't find interface-file decl with Typeable In-Reply-To: <047.8081d198b95305daa8d4af7070a41151@haskell.org> References: <047.8081d198b95305daa8d4af7070a41151@haskell.org> Message-ID: <062.1ce67b317ccfcc57074ec3faaf781273@haskell.org> #12692: Can't find interface-file decl with Typeable -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If anyone can offer an easy way to reproduce this, it'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 14:00:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 14:00:45 -0000 Subject: [GHC] #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) In-Reply-To: <051.f5a3bb82cbacb1093f08604448c52c48@haskell.org> References: <051.f5a3bb82cbacb1093f08604448c52c48@haskell.org> Message-ID: <066.441c8c589db746b52591579b6e332beb@haskell.org> #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | CustomTypeErrors 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 andrewthad): Just to add information about my current workaround, the example given can be rewritten to use a type family instead: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits import Data.Kind -- Works just like a type synonym type family Fail where Fail = TypeError (Text "It failed") type family Bad a where Bad a = TypeError (Text "It messed up on " :<>: Text (Whoami a)) type family Whoami (ty :: Type) :: Symbol where Whoami Int = "a number" Whoami Float = "a number" Whoami [_] = "a list of things" Whoami _ = "something else" expr :: Bad [Bool] expr = 5 main :: IO () main = putStrLn "Hello" }}} Everyone on this ticket is probably already aware of this, but I just wanted to document it for passersby like myself who may be less familiar with the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 14:30:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 14:30:18 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.fcf023c3aa7edefc33f1bb8f85ac11e9@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be really really good to know why the tiny difference between the functions causes a seg fault. Why doesn't Core Lint (on the output of `CorePrep`) catch the seg-fault? How to find it? Since the failing tests use the GHC API, that suggests that the code for GHC itself gets messed up, which is a pain -- GHC is a very big test-case! One idea: spit out a `pprTrace` whenever `cpe_exprIsTrivial` does something different to what `exprIsTrivial` would have. I bet it doesn't happen much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 14:33:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 14:33:33 -0000 Subject: [GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level In-Reply-To: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> References: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> Message-ID: <064.fe03cd980d547b416b4fe41f888e0c8c@haskell.org> #12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I rather agree with all this. I think the trace-level thing was intended to allow different levels of trace verbosity, but it never got properly used. OK to remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 14:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 14:33:54 -0000 Subject: [GHC] #12687: Add a flag to control constraint solving trace In-Reply-To: <049.a796621b5229aec72ad370435c17f808@haskell.org> References: <049.a796621b5229aec72ad370435c17f808@haskell.org> Message-ID: <064.86adaae52fdfb8c0f700b8dff8e2aa4a@haskell.org> #12687: Add a flag to control constraint solving trace -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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 simonpj): Fine with me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 15:34:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 15:34:19 -0000 Subject: [GHC] #12044: Remove sortWith in favor of sortOn In-Reply-To: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> References: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> Message-ID: <058.0ed21d69ac1921e6c9db73f4b6dbd344@haskell.org> #12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: vkonton Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2659 | Differential Rev(s): Phab:D2587 Wiki Page: | -------------------------------------+------------------------------------- Changes (by cblp): * status: new => patch * differential: => Phab:D2587 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 15:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 15:47:08 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.05fae6546fc34429e77edfe8de49f282@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Look at commit 11ff1df8a7c25485c9c7508d65bcb380e592010d, and talk to Edward Yang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 15:52:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 15:52:46 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.2b0b1e67dcf75e651918ee0bf32a0d8a@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bce99086e9f54909f51ff5a74cb8c666083bb021/ghc" bce9908/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bce99086e9f54909f51ff5a74cb8c666083bb021" RnExpr: Actually fail if patterns found in expression This fixes #12584, where wildcard patterns were snuck into an expression, which then crashed the typechecker in TcExpr since EWildPats aren't supposed to appear in the AST after renaming. The problem was that `rnTopSpliceDecl` failed to check for errors from `rnSplice` (as done by other callers to `rnSplice`). Thanks to Shayan for reporting this! Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2539 GHC Trac Issues: #12584 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 15:54:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 15:54:42 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.31ca5cd2b74e2a0e19002ae07935c027@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 15:56:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 15:56:51 -0000 Subject: [GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings In-Reply-To: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> References: <046.da1b26e8a2018c0276dd1074021c6c71@haskell.org> Message-ID: <061.a460f79be238d5ab4e99a7d3f3dd4788@haskell.org> #12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T12615 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2545 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 0c2b766d5961562cc8e8603d12399db279ac7e51. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 16:06:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 16:06:09 -0000 Subject: [GHC] #5618: TH cannot splice patterns in declaration quotes In-Reply-To: <046.21dfb6fbbf0a8e4d2c5b6b6e34094e41@haskell.org> References: <046.21dfb6fbbf0a8e4d2c5b6b6e34094e41@haskell.org> Message-ID: <061.61449daa9bc5e15790cea4c65b93e162@haskell.org> #5618: TH cannot splice patterns in declaration quotes -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: invalid | 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 heisenbug): It seems to work in GHC v8.2.x: {{{#!haskell Prelude Language.Haskell.TH> runQ ((\p -> [d| $(p) = 1 |] ) [p| hhh|]) >>= print [ValD (VarP hhh_1) (NormalB (LitE (IntegerL 1))) []] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 16:12:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 16:12:14 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.246e2614673de4683d866a949637684b@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Not sure how it is supposed to work, but can I somehow pass a name to be spliced into a pattern synonym quote? {{{#!haskell :t \n -> [d| pattern $(n) = 42 |] }}} errors out (unfortunately). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 16:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 16:17:02 -0000 Subject: [GHC] #12693: Relax qualified import syntax Message-ID: <043.b867bcd45eeb19d34ce6352a29f30c11@haskell.org> #12693: Relax qualified import syntax -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: import, | Operating System: Unknown/Multiple qualified, syntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10478 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Problem = Case 1. {{{#!hs import Data.HashMap (HashMap) import qualified Data.HashMap as HashMap import Data.Map (Map) import qualified Data.Map as Map import Data.Set (Set) import qualified Data.Set as Set import Data.Text (Text) import qualified Data.Text as Text }}} Module names start in different columns, so the user cannot search it without help of tools, so the code is unreadable. Case 2. {{{#!hs import Data.HashMap (HashMap) import qualified Data.HashMap as HashMap import Data.Map (Map) import qualified Data.Map as Map import Data.Set (Set) import qualified Data.Set as Set import Data.Text (Text) import qualified Data.Text as Text }}} Too many space used, too less space left for imported items list, too hard to maintain without special tools. = Proposal = Allow to write `qualified` keyword after module name: {{{#!hs import Data.HashMap (HashMap) import Data.HashMap qualified as HashMap import Data.Map (Map) import Data.Map qualified as Map import Data.Set (Set) import Data.Set qualified as Set import Data.Text (Text) import Data.Text qualified as Text }}} All the problems solved! This proposal looks a little like ShorterImportSyntax and #10478, but differs from them in such ways: 1. It doesn't actually make imports shorter in visible symbols, only in lines used (in case of very long imported items list), a little. 2. It doesn't introduce new syntax constructions looking like existing but doing other things. 3. It is easy to implement and understand. 4. It looks more natural from the point of view of English language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 16:17:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 16:17:47 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.d379c1b4a03d508dff133cc9e1a93ea7@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Plan for #12689: Inline simple wrappers (like the ones that we add here) in the LHS of rules, so that are no worse off than before, and then figure out if we are actually getting the desired improvements with regard to nested tuples (re #5642). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 18:49:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 18:49:47 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.329c179c02d0ad53ce5590d76ca6be32@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Currently it's 2016. Most modern mobile phones are quad cores. Desktop/server/mobile single core processors are left in the past long time ago. Most high performance desktop/server machines are NUMA with a lot of cores. I think that single-threaded by default for GHC is a legacy which should be re-discussed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:01:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:01:09 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.65b6f2a81c349bf5d02171cf24d565aa@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ben, you set this milestone to 8.0.2, but marked the issue as closed. Should this be set as merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:02:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:02:56 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.d8a3388b1b29728729abb4d9d66f68b7@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"184d7cb8278b9c6cb3f9786a96f081d08e4640db/ghc" 184d7cb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="184d7cb8278b9c6cb3f9786a96f081d08e4640db" Add test for #12411 The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:02:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:02:56 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.368eddd0fc05e09987a9620988f7027b@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"184d7cb8278b9c6cb3f9786a96f081d08e4640db/ghc" 184d7cb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="184d7cb8278b9c6cb3f9786a96f081d08e4640db" Add test for #12411 The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:06:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:06:23 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.5033da0c9993e267c0f497270f5f8ed6@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12411 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => th/T12411 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:19:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:19:13 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.965bdd78131e07f38362b648d3eef802@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): This program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} import Data.Proxy hcpure :: proxy c -> (forall a. c a => f a) -> h f xs hcpure _ _ = undefined a = minBound & hcpure (Proxy @Bounded) }}} produces that GHC panic with GHC 8.0.1, but not with GHC 8.0.2 or HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 19:48:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 19:48:40 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.1b8aa9de221f8701530e4219fe08f695@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Doesn’t the note “Note [Inlining in CorePrep]” explain it sufficiently well? The runtime does not support trivial thunks (no stg_ap_0_upd_info), so CorePrep must not produce them. (Well, it is not a complete story yet – why does it segfault instead of giving a linker error; why does it only occur when linked against GHC.) I’ll ponder it some more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 20:43:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 20:43:33 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.c042066797e6d2b442013e490863f1c2@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): I recently ran into this, too. It’s definitely extremely confusing, since usually identifiers that aren’t in scope are ''very'' clearly indicated in error messages, but nothing in these errors would suggest that’s the problem. It took me a while to realize what exactly the problem was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 22:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 22:57:25 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.c74acb71860d759ba55fae0d394992d8@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): It appears that af21e38855f7d517774542b360178b05045ecb08 was the commit that fixed this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 23:19:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 23:19:39 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.de7a3573cbb091379cd5a8110b3283f0@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Ryan Scott ): In [changeset:"042c5930bff239337d21836db5b8d0ebf0180ffc/ghc" 042c5930/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="042c5930bff239337d21836db5b8d0ebf0180ffc" Add test for #12589 Commit af21e38855f7d517774542b360178b05045ecb08 fixed #12598. Let's add a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 23:19:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 23:19:39 -0000 Subject: [GHC] #12598: configure script: --enable-unregisterised default printed incorrectly In-Reply-To: <049.74a8794f08f225f7c1e273ea6f418ff2@haskell.org> References: <049.74a8794f08f225f7c1e273ea6f418ff2@haskell.org> Message-ID: <064.166271e4ceeef55cd6bc3e2e45bb8965@haskell.org> #12598: configure script: --enable-unregisterised default printed incorrectly -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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 Ryan Scott ): In [changeset:"042c5930bff239337d21836db5b8d0ebf0180ffc/ghc" 042c5930/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="042c5930bff239337d21836db5b8d0ebf0180ffc" Add test for #12589 Commit af21e38855f7d517774542b360178b05045ecb08 fixed #12598. Let's add a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 23:22:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 23:22:26 -0000 Subject: [GHC] #12598: configure script: --enable-unregisterised default printed incorrectly In-Reply-To: <049.74a8794f08f225f7c1e273ea6f418ff2@haskell.org> References: <049.74a8794f08f225f7c1e273ea6f418ff2@haskell.org> Message-ID: <064.880a79f3640c05723bfcf92792a3fffd@haskell.org> #12598: configure script: --enable-unregisterised default printed incorrectly -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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 RyanGlScott): Oops, that was meant for #12589 (I accidentally switched the 9 and the 8 in the commit description). Please ignore the above automessage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 12 23:23:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 12 Oct 2016 23:23:09 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.ac89d1ca21ba0f74509a2e8016c87f4f@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12589 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * testcase: => typecheck/should_fail/T12589 Comment: Since this test will also work in GHC 8.0.2, the above commit can be safely merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 00:31:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 00:31:00 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.ac398e6e0a77aa91c85f12af0a003883@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:27 heisenbug]: > Not sure how it is supposed to work, but can I somehow pass a name to be spliced into a pattern synonym quote? > {{{#!haskell > :t \n -> [d| pattern $(n) = 42 |] > }}} > errors out (unfortunately). No, I don't believe that's possible, because TH doesn't allow "name splices". You'd have to build up the syntax manually, using the `Dec` constructors or the functions from `Language.Haskell.TH.Lib`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 00:34:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 00:34:25 -0000 Subject: [GHC] #12693: Relax qualified import syntax In-Reply-To: <043.b867bcd45eeb19d34ce6352a29f30c11@haskell.org> References: <043.b867bcd45eeb19d34ce6352a29f30c11@haskell.org> Message-ID: <058.f7c19ddbcaf2c139ee3586ec37eeb61a@haskell.org> #12693: Relax qualified import syntax -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: import, Resolution: | qualified, syntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10478 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While this is a fine idea, I think the best place to have this discussion is as a GHC Proposal. See https://github.com/ghc-proposals/ghc-proposals. There, the community can weigh in on pros and cons of this proposal. If the community (and the GHC Committee) accept this request, then we can use a Trac ticket to track implementation. Thanks for posting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 01:04:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 01:04:32 -0000 Subject: [GHC] #12456: Panics when making a quotation as pattern synonym In-Reply-To: <051.e005d068b395051143f7da213f6d0769@haskell.org> References: <051.e005d068b395051143f7da213f6d0769@haskell.org> Message-ID: <066.b7ead674496212988a1e8571264f664a@haskell.org> #12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms 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 RyanGlScott): This works in GHC 8.0.2 and HEAD. It was apparently fixed in f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 01:08:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 01:08:57 -0000 Subject: [GHC] #12456: Panics when making a quotation as pattern synonym In-Reply-To: <051.e005d068b395051143f7da213f6d0769@haskell.org> References: <051.e005d068b395051143f7da213f6d0769@haskell.org> Message-ID: <066.3598a0209a7ac23f3130017012c47227@haskell.org> #12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms 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 Ryan Scott ): In [changeset:"fef1df4bb4f4b74f4a0d0d22c913d29189e140e4/ghc" fef1df4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fef1df4bb4f4b74f4a0d0d22c913d29189e140e4" Add test for #12456 Commit f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a fixed #12456. Let's add a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 01:10:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 01:10:30 -0000 Subject: [GHC] #12456: Panics when making a quotation as pattern synonym In-Reply-To: <051.e005d068b395051143f7da213f6d0769@haskell.org> References: <051.e005d068b395051143f7da213f6d0769@haskell.org> Message-ID: <066.8bb046e8d4147f743f52b813e29d49dd@haskell.org> #12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T12456 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * testcase: => ghci/should_run/T12456 Comment: Since this test will also work in GHC 8.0.2, the above commit can be safely merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 02:18:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 02:18:01 -0000 Subject: [GHC] #12464: Add `instance Semigroup a => Semigroup (IO a)` In-Reply-To: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> References: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> Message-ID: <066.072d9232b30bcaed6f65f9d66ed6ecab@haskell.org> #12464: Add `instance Semigroup a => Semigroup (IO a)` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2588 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2588 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 02:45:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 02:45:19 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.d5f5ed19b6441b7a39bfeff4e5b987ca@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: newcomer => * status: patch => infoneeded * cc: ezyang (added) Comment: Ok, here is some insight. The problem is related to trivial bindings – whether they are literals or nullary data cons. The latter are easy to produce, so here is what I did: I first broke `cpe_ExprIsLiteral`, by adding this as a new first clause {{{ cpe_ExprIsTrivial (Var v) | isDataConWorkId v = False }}} Then I compiled the smallest possible program (with `-dcore-lint -dstg- lint`) {{{#!hs main = return () }}} and it crashes. Here the output with `+RTS -Dg`: {{{ cap 0: initialised allocated 1 megablock(s) at 0x4200000000 allocated 1 megablock(s) at 0x4200100000 ---------------------------------------------------------- Gen Max Mut-list Blocks Large Live Slop Blocks Bytes Objects ---------------------------------------------------------- 0 0 0 1 0 0 4096 1 0 0 1 0 0 4096 ---------------------------------------------------------- 0 8192 ---------------------------------------------------------- cap 0: starting GC GC (gen 1, using 1 thread(s)) Memory inventory: gen 0 blocks : 11 blocks ( 0.0 MB) gen 1 blocks : 2 blocks ( 0.0 MB) nursery : 256 blocks ( 1.0 MB) retainer : 0 blocks ( 0.0 MB) arena blocks : 0 blocks ( 0.0 MB) exec : 0 blocks ( 0.0 MB) GC free pool : 0 blocks ( 0.0 MB) free : 235 blocks ( 0.9 MB) total : 504 blocks ( 2.0 MB) cap 0: GC working scavenging static objects T11158: internal error: evacuate(static): strange closure type 38956 (GHC version 8.1.20161012 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abgebrochen }}} So some pointer from the set of static objects is broken by this change. We are in a slightly better position than above because we no longer need to use ghc-the-library to trigger the crash. But still, the problem could be anywhere in the libraries. Here is the backtrace: {{{ (gdb) bt #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 #1 0x00007ffff70dd40a in __GI_abort () at abort.c:89 #2 0x00000000006d041a in rtsFatalInternalErrorFn (s=0x7525c0 "evacuate(static): strange closure type %d", ap=0x7fffffffdbf8) at rts/RtsMessages.c:182 #3 0x00000000006d004c in barf (s=0x7525c0 "evacuate(static): strange closure type %d") at rts/RtsMessages.c:46 #4 0x00000000006f2cc3 in evacuate (p=0x986158) at rts/sm/Evac.c:562 #5 0x0000000000717f18 in scavenge_static () at rts/sm/Scav.c:1764 #6 0x00000000007184d9 in scavenge_loop () at rts/sm/Scav.c:2088 #7 0x00000000006ee6a4 in scavenge_until_all_done () at rts/sm/GC.c:1001 #8 0x00000000006ed6cc in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=0, cap=0x9d0d80 ) at rts/sm/GC.c:404 #9 0x00000000006dc686 in scheduleDoGC (pcap=0x7fffffffdf10, task=0x9e9ce0, force_major=rtsTrue) at rts/Schedule.c:1821 #10 0x00000000006dd1a5 in exitScheduler (wait_foreign=rtsFalse) at rts/Schedule.c:2636 #11 0x00000000006d09c2 in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:326 #12 0x00000000006d0b7a in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:483 #13 0x00000000006e5312 in hs_main (argc=1, argv=0x7fffffffe178, main_closure=0x97d670, rts_config=...) at rts/RtsMain.c:91 #14 0x0000000000404226 in main () }}} But at this time of day, I will not dig in deeper. Edward, does this analysis provide any insight to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 04:08:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 04:08:29 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code Message-ID: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given this A.hs: {{{ {-# LANGUAGE GADTs #-} module A where f :: Bool ~ Int => a -> b f x = x }}} I get: {{{ ezyang at sabre:~$ ghc-head --version The Glorious Glasgow Haskell Compilation System, version 8.1.20161010 ezyang at sabre:~$ ghc-head --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:4:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘f’: f x = ... }}} In contrast: {{{ ezyang at sabre:~$ ghc-8.0 --make A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:3:6: error: • Couldn't match type ‘Bool’ with ‘Int’ Inaccessible code in the type signature for: f :: Bool ~ Int => a -> b • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: f :: Bool ~ Int => a -> b }}} Is this expected? I'd expect at least a warning! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 05:54:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 05:54:09 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.5de9544ec876560e46b79a0527cd4464@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): It turns out the widely used zlib library suffers from exactly this issue, and can segfault when executed in parallel. See https://github.com/haskell/zlib/issues/7#issuecomment-253028108 for more details. It seems like adding {{{noDuplicate}}} to {{{runST}}} and adding {{{unsafeRunST}}} is a reasonable compromise. There may be a performance impact on {{{runST}}}, but having segfaults/value-changes should require typing something with the word {{{unsafe}}} in it at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 08:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 08:45:20 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.5fd8f1bbf26863cf3519f21ae0d3538c@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:28 goldfire]: > Replying to [comment:27 heisenbug]: >> ''snip'' > No, I don't believe that's possible, because TH doesn't allow "name splices". You'd have to build up the syntax manually, using the `Dec` constructors or the functions from `Language.Haskell.TH.Lib`. Oh, sure. I'd build as much as possible using a quote and then alter the name by a transformation on the ADT. {{{#!haskell Prelude Language.Haskell.TH> runQ [d| pattern Foo <- 42 where Foo = 43 |] [PatSynD Foo_0 (PrefixPatSyn []) (ExplBidir [Clause [] (NormalB (LitE (IntegerL 43))) []]) (LitP (IntegerL 42))] }}} Swapping out the `Foo_0` looks easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 08:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 08:59:19 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.d1326b5f969be3c03ed56a4d26904381@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with Neil here. But is it just `runST`? Every time we build a thunk whose evaluation will mutate state, we must ensure that thunk can be evaluated at most once (no- duplicate). And doesn't every use of `bind` in the lazy ST world have that property? From `Control.Monad.Lazy.ST.Lazy.Imp`: {{{ (ST m) >>= k = ST $ \ s -> let (r,new_s) = m s ST k_a = k r in k_a new_s }}} That `m s` thunk must be evaluated at most once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 09:05:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 09:05:45 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.5f5b77cd990bb482b5a0f2116431a58b@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Correct, it's not just `runST`, we would need to use `noDuplicate#` in the definition of `>>=`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 09:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 09:18:59 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code In-Reply-To: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> References: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> Message-ID: <060.54564d9a5a932458abc72dd153d7b886@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 simonpj): See #12466 for an extended discussion. I wish I had a better solution. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 09:23:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 09:23:35 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.934e23068e4ef8aa463c0e02fcf095bf@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What C-- and STG code do you get for {{{ f x = let y = Nothing in (y,y) }}} No optimistaion, so the y binding isn't floated, so you get a local nullary-datacon binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 09:26:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 09:26:31 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.ffa20b2165d85ec5b0434a2c7cede630@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I can't see any decent way forward here except to delay inlining the wrapper until phase 1. In GHC as-is that may be fine, because it'll only apply to data-cons that have wrappers, which are relatively rarer. It'd need to be documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 10:35:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 10:35:40 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later Message-ID: <043.b25e91253b49ad08042d636adf423d59@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: FreeBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to build GHC 8.0.1 on FreeBSD 11.x, I come across following compiler error: {{{ /usr/local/bin/clang-cpp38 -DPROFILING -DTHREADED_RTS -DDEBUG -fno- stack-protector -O2 -pipe -Qunused-arguments -I/usr/local/include -fstack-protector -fno-strict-aliasing -Wall -Wall -Wextra -Wstrict- prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -fno-strict-aliasing -fno-common -Irts/dist/build/autogen -Wno-unknown-pragmas -O2 -fomit-frame- pointer -g -DRtsWay=\"rts_v\" -MM -x c rts/posix/OSMem.c -MF rts/dist/build/.depend-v-p-dyn-l-debug-thr-thr_debug-thr_l-thr_p- debug_dyn-thr_dyn-thr_debug_dyn-l_dyn-thr_l_dyn.c_asm.bit rts/posix/OSMem.c:158:5: error: USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE # error USE_LARGE_ADDRESS_SPACE needs MAP_NORESERVE ^ 1 error generated. }}} From some [https://svnweb.freebsd.org/base/head/sys/sys/mman.h?r1=273249&r2=273250& investigation], it turns out when it was there, it was not even implemented. The value of `__FreeBSD_version` (in case you plan to add conditional based on it), where it is [https://svnweb.freebsd.org/base/head/sys/sys/param.h?r1=273250&r2=273249&pathrev=273250 changed] is `1100039`. Let me know if you need more information. Thanks for looking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 10:36:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 10:36:26 -0000 Subject: [GHC] #12693: Relax qualified import syntax In-Reply-To: <043.b867bcd45eeb19d34ce6352a29f30c11@haskell.org> References: <043.b867bcd45eeb19d34ce6352a29f30c11@haskell.org> Message-ID: <058.bc393bebecfab079348bb4ec6be8e059@haskell.org> #12693: Relax qualified import syntax -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: import, Resolution: | qualified, syntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10478 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cblp): https://github.com/ghc-proposals/ghc-proposals/pull/21 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 11:47:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 11:47:28 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.32d587e4c31fce6a79a97380be8d3a8f@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2fdf21bf26386ac5558ed5b95105bcf78e31f093/ghc" 2fdf21b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fdf21bf26386ac5558ed5b95105bcf78e31f093" Further improve error handling in TcRn monad This patch builds on the one for Trac #12124, by dealing properly with out-of-scope "hole" errors. This fixes Trac #12529. The hard error coming from visible type application is still there, but the out-of-scope error is no longer suppressed. (Arguably the VTA message should be suppressed somehow, but that's a battle for another day.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 11:47:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 11:47:28 -0000 Subject: [GHC] #12124: Ambiguous type variable: it's a red herring! In-Reply-To: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> References: <045.3fef5c2d647c702c366f69de60e48a08@haskell.org> Message-ID: <060.6d26163e8847f7e7116e195d6e7c7400@haskell.org> #12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12124 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2fdf21bf26386ac5558ed5b95105bcf78e31f093/ghc" 2fdf21b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fdf21bf26386ac5558ed5b95105bcf78e31f093" Further improve error handling in TcRn monad This patch builds on the one for Trac #12124, by dealing properly with out-of-scope "hole" errors. This fixes Trac #12529. The hard error coming from visible type application is still there, but the out-of-scope error is no longer suppressed. (Arguably the VTA message should be suppressed somehow, but that's a battle for another day.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 11:51:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 11:51:52 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.1271fad2e11ba3e8ea88b181cbca6d7f@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: RyanGlScott (added) * owner: => RyanGlScott Comment: > A solution would be to protect the code generated by deriving (Show) from OverloadedStrings and RebindableSyntax extensions. Yes, I think that's probably the right solution. Ryan, do you agree? Might you do it? I think it's a matter of fiddling with `ib_extensions`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 11:53:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 11:53:18 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.980a38e4da235d8e8a08cb970aca1894@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12529 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T12529 * status: new => merge Comment: Possibly worth merging? Since the patch for #12124 is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:08:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:08:16 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.34a30d8d16529198f441d4ac55abfa38@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I get {{{ T11158.f :: forall a1_aDG a2_aDF t_aDp. t_aDp -> (GHC.Base.Maybe a2_aDF, GHC.Base.Maybe a1_aDG) [GblId, Arity=1, Caf=NoCafRefs, Unf=OtherCon []] = \r [x_sNH] let { sat_sNJ [Occ=Once] :: GHC.Base.Maybe a_aDG [LclId] = NO_CCS GHC.Base.Nothing! []; } in let { sat_sNI [Occ=Once] :: GHC.Base.Maybe a1_aDF [LclId] = NO_CCS GHC.Base.Nothing! []; } in (,) [sat_sNI sat_sNJ]; }}} and {{{ ==================== Output Cmm ==================== [section ""data" . T11158.f_closure" { T11158.f_closure: const T11158.f_info; }, T11158.f_entry() // [R2] { info_tbl: [(cNQ, label: T11158.f_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cNQ: _sNG::P64 = R2; goto cNS; cNS: Hp = Hp + 24; if (Hp > HpLim) goto cNU; else goto cNT; cNU: HpAlloc = 24; goto cNR; cNR: R2 = _sNG::P64; R1 = T11158.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cNT: I64[Hp - 16] = (,)_con_info; P64[Hp - 8] = GHC.Base.Nothing_closure+1; P64[Hp] = GHC.Base.Nothing_closure+1; _cNP::P64 = Hp - 15; R1 = _cNP::P64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} which looks reasonable, doesn’t it? But here is an interesting difference, which might be a clue. Before my patch: {{{ ==================== Output Cmm ==================== [section ""relreadonly" . SOb_srt" { SOb_srt: const GHC.Base.$fMonadIO_closure; }] }}} After my patch: {{{ ==================== Output Cmm ==================== [section ""relreadonly" . SNV_srt" { SNV_srt: const GHC.Base.Nothing_closure; const GHC.Base.$fMonadIO_closure; const sat_sNJ_closure; }] }}} Is it kosher to add a static constructor closure to the `srt` table? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:11:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:11:25 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.80ac9948ef011456d28ffde3da034ed8@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, we've certainly changed the way deriving works in the past to accommodate the presence of `RebindableSyntax` (see #11396 and #12080 for examples). But those were quite small, non-invasive changes. On the other hand, derived `Show` instances make heavy use of string literals, so I don't think changing the derived `Show` methods is really an option here. Simon, are you suggesting just disabling `RebindableSyntax` entirely for derived code? I'd be fine with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:16:17 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.720a63ba22bbaa5ff91add79f05227cd@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:42:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:42:43 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.e3f2e7e170a2b9e327b68ec8a8108af8@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Here is an idea that came out of what Iavor said (or at least how I understood him). There are still open questions, but I do like the general approach: Consider a rule (which I write with the wrapper name already, as that is what we desugar to these days) {{{ RULE forall a b. foo ($WMkCon a b) = bar a b }}} and a wrapper {{{ $WMkCon a b = case a of (a1,a2) -> MkCon a1 a2 b }}} We don’t want cases on the LHS of the rule, so we do not just want to inline MkCon into the LHS. But what if we move it to the right hand side, and write the rule like that: {{{ RULE forall a1 a2 b. foo (MkCon a1 a2 b) = let a = (a1,a2) in bar a b }}} The rule is nice because the LHS is a normal form (with regard to the simplifier and the rewrite rules). The necessary transformations could be stored with the unfolding information of `$WMkCon`. At least for a strict `foo`, things might work out. We’d get: {{{ case some expr of (a1,a2) -> … foo (MkCon a1 a2 someB) … → case some expr of (a1,a2) -> … (let a = (a1,a2) in bar a someB) … -- rule fires → case some expr of (a1,a2) -> … bar (a1,a2) a someB … -- inlining }}} and further cleanup may happen due to CSE. Unfortunately it does not work as immediately if `foo` is not strict, as the `case` does not get floated out of the way, and we need to match an expression like {{{ foo (case some expr of (a,b) -> MkCon a1 a2 someB) }}} and it would not be sound if the matcher would simply float the case out of the way. So this idea requires more thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:46:04 -0000 Subject: [GHC] #12439: DeriveDataTypeable - deriving Data for several type constructor applications In-Reply-To: <048.ddc69e4fd5a90cb2d727e0e34d26bd92@haskell.org> References: <048.ddc69e4fd5a90cb2d727e0e34d26bd92@haskell.org> Message-ID: <063.6d66c6cf9c2e58c50d3662eab8f1807e@haskell.org> #12439: DeriveDataTypeable - deriving Data for several type constructor applications -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: deriving 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 RyanGlScott): * status: new => closed * resolution: => duplicate Comment: This is basically a duplicate of #12245, which was already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 13:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 13:54:15 -0000 Subject: [GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) In-Reply-To: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> References: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> Message-ID: <063.35dfbd15e0a6c144509d18b9266b3046@haskell.org> #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving 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 RyanGlScott): I had to make some changes to your code to get that exact error message. Here is what I tried: {{{#!hs {-# LANGUAGE DeriveDataTypeable, FlexibleInstances, StandaloneDeriving #-} module T12438 where import Control.Applicative (Const(..)) import qualified Data.Data data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu (Const ())) }}} Note the addition of `FlexibleInstances`. Also, `Const` wasn't in scope in your original program — I assume you are referring to the `Const` from `Control.Applicative`? If so, there's a simple explanation for why that program won't compile — `Const` doesn't have a `Data` instance. Sure enough, this program compiles just fine: {{{#!hs {-# LANGUAGE DeriveDataTypeable, FlexibleInstances, StandaloneDeriving #-} module T12438 where import Control.Applicative (Const(..)) import qualified Data.Data deriving instance (Data.Data.Data a, Data.Data.Data b) => Data.Data.Data (Const a b) data Mu f = Mu (f (Mu f)) deriving instance Data.Data.Data (Mu (Const ())) }}} In light of this, there's no bug in `DeriveDataTypeable` - it's just a Haskell library design question of whether `Const` should have a `Data` instance or not (I wouldn't be opposed to introducing one). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:00:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:00:13 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.d2dfbf89a518286fb2c730538c7184db@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Simon, are you suggesting just disabling RebindableSyntax entirely for derived code? I'd be fine with that. Yes, exactly Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:02:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:02:48 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.e742dec1e2d48234637edebb53e3bd9f@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for pointing that out, Ryan! comment:8 was merged to `ghc-8.0` as 47ae01bfb7ca426188d85c6ecb33ebbacc837aa6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:04:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:04:23 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.f4b946c4ae1c0562eb3bfc16a1b3aca7@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12411 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge Comment: Since #12584 was merged into GHC 8.0.2, this can be safely merged too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:04:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:04:54 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.26db3db122b4205235b0b47c17dda9d5@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12411 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:10:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:10:01 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.c86543b656d7b3fd6d50913ce3e2aa78@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Is #9494 the same issue as this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:11:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:11:11 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.862c28a94f02032aa7b6261f797c2d52@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Yes, looks reasonable. No point in having `Nothing` in an SRT. It should have a no-CAF info. I wonder why it doesn't. The `sat_sNJ_closure` thing is strange. Does it come from a top level binding {{{ sat_sNG = () }}} or how does it arise? I don't know if anything bad would happen if these two closures do end up in SRT; I don't see why they should. Adding simonmar to cc; he'll know for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:43:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:43:05 -0000 Subject: [GHC] #12245: Deriving Data at higher kinds In-Reply-To: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> References: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> Message-ID: <061.e7655e4504d69dc5db1ff83f8670d4f5@haskell.org> #12245: Deriving Data at higher kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12245 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): Oh, I was not even aware that this got fixed! (You either did not bother to notify me or I missed something. Also I must have messed up my search when opening the duplicate ticket, pretty sure I did some search; sorry about that). Anyways, thanks for the fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 14:55:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 14:55:30 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.998488c95478bd4a1ef03a7718f07fb5@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It arose out of `main = return ()`. In CoreTidy, it is {{{ main = return @ IO GHC.Base.$fMonadIO @ () GHC.Tuple.() }}} and CorePrep turns that (due to my change of `cpe_ExprIsTrivial`!) into {{{ -- RHS size: {terms: 1, types: 0, coercions: 0} sat_sNJ :: () [LclId] sat_sNJ = GHC.Tuple.() -- RHS size: {terms: 3, types: 2, coercions: 0} T11158.main :: GHC.Types.IO () [GblId] T11158.main = GHC.Base.return @ GHC.Types.IO GHC.Base.$fMonadIO @ () sat_sNJ }}} which yields this STG {{{ sat_sNJ :: () [LclId] = NO_CCS ()! []; T11158.main :: GHC.Types.IO () [GblId] = \u [] GHC.Base.return GHC.Base.$fMonadIO sat_sNJ; }}} Given that the crash happens in `scavenge_static ()` I think it is likely that the SRT table is related to the issue. I don’t see anywhere in `cpeArg` (which creates the float) code that would set CAF information on the floated argument. According to note `Note [CafInfo and floating]` it is safe to have top-level binds with `HasCafRef` even when they do not actually reference any CAFs. (Trying to set `NoCafInfo` on all the extra floats I am generating here, and rebuilding the libraries. Will report back.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 15:06:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 15:06:01 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.34b22dfe04a9119c30e5b8e3bf43cc35@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > (Trying to set NoCafInfo on all the extra floats I am generating here, and rebuilding the libraries. Will report back.) That did the trick. No more crashes. I conclude that having a data constructor closure mentioned in the SRT is bad. But it is not everz occurence that causes problems: With the libraries built so that all new floats have `NoCafInfo`, and then building my test program to include the floated `()` closure or `GHC.Base.Nothing_closure` in the SRT does *not* crash. So there must be further conditions required for such an entry in the SRT causing a crash. Maybe with this analysis Simon Marlow can without too much effort shed more light on the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 15:23:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 15:23:18 -0000 Subject: [GHC] #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.564df9b520de083f4e269bc05576dbc4@haskell.org> #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 7.10.2 Resolution: fixed | 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 bgamari): * milestone: 8.2.1 => 8.0.2 Comment: Merged to `ghc-8.0` as b7d6e20ce342c4a2b46089dfe64498d28337afd9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 15:24:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 15:24:08 -0000 Subject: [GHC] #12456: Panics when making a quotation as pattern synonym In-Reply-To: <051.e005d068b395051143f7da213f6d0769@haskell.org> References: <051.e005d068b395051143f7da213f6d0769@haskell.org> Message-ID: <066.1396d24bfd9c1a0bd6eeabde534044d6@haskell.org> #12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T12456 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Test in comment:2 merged `ghc-8.0` as 243994c30e70bc8987a5bf8ceaf780ac01c8eb5e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:03:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:03:20 -0000 Subject: [GHC] #12689: DataCon wrappers get in the way of rules In-Reply-To: <046.137deb6f94373a15da504601d7833b6f@haskell.org> References: <046.137deb6f94373a15da504601d7833b6f@haskell.org> Message-ID: <061.1c98ca9ad27f229766a4c6fbb9389df7@haskell.org> #12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): I just found this comment in `SimplUtils`: {{{ active_unfolding_minimal :: Id -> Bool -- Compuslory unfoldings only -- Ignore SimplGently, because we want to inline regardless; -- the Id has no top-level binding at all -- -- NB: we used to have a second exception, for data con wrappers. -- On the grounds that we use gentle mode for rule LHSs, and -- they match better when data con wrappers are inlined. -- But that only really applies to the trivial wrappers (like (:)), -- and they are now constructed as Compulsory unfoldings (in MkId) -- so they'll happen anyway. active_unfolding_minimal id = isCompulsoryUnfolding (realIdUnfolding id) }}} Was there a time when `(:)` had a wrapper? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:06:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:06:29 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.a902cce84cbcebf14252437942ba20f8@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2591 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2591 * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:10:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:10:30 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.8cf8b3ee2d1d6e5dcbaa478e67cb66a7@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Phyx-): Binutils 2.27-2 has been released on msys, this contains Awson's patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:11:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:11:02 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful Message-ID: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: exception | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was told in #haskell @freenode to report this as a bug. I have a program that throws exceptions and tried debugging the problem within ghci and also outside of ghci with these commands: {{{ stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls' --executable-profiling stack exec -- vhdl +RTS -xc }}} {{{#!hs tfComment :: Data from => from -> from tfComment = transformBi tf where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) tf a = a zeroPos :: Data from => from -> from zeroPos = transformBi zp where zp sp@(M.SourcePos _ _ _) = sp { M.sourceName="", M.sourceLine=unsafePos 1, M.sourceColumn=unsafePos 1} zp x = x -- (a)dd (e)xtended(i)dentifier (s)laches aeis :: Data from => from -> from aeis = transformBi x where x (IExtended a) = let updated_text :: Text updated_text = T.concat ["\\", snd $ t_text a, "\\"] in IExtended $ a {t_text = (fst $ t_text a, updated_text)} x a = a bla = something.. where parser_prop :: ContextClause -> Bool parser_prop = \x -> (transformIn <$> Right x) == (transformOut <$> parseSource parser $ T.toStrict . printSource $ transformIn x) transformIn ast = zeroPos ast transformOut ast = tfComment $ aeis $ zeroPos ast }}} ghci trace {{{ λ> :trace main Stopped in , _exception :: e = _ λ> :back Logged breakpoint at Main.hs:95:13-26 _result :: from -> from tf :: Comment -> Comment λ> :list 94 tfComment :: Data from => from -> from 95 tfComment = transformBi tf -- transformBi tf highlighted here 96 where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) λ> :back Logged breakpoint at Main.hs:242:28-57 _result :: from ast :: from λ> :list 241 transformIn ast = zeroPos ast 242 transformOut ast = tfComment $ aeis $ zeroPos ast -- tfComment $ aeis $ zeroPos ast highlighted here 243 λ> :force ast ast = Right [] λ> transformIn (Right []) Right [] λ> transformOut (Right []) Right [] λ> zeroPos (Right []) Right [] λ> aeis (Right []) Right [] λ> tfComment (Right []) Right [] }}} run with profiling options (this was aborted at some point) {{{ » stack exec -- vhdl +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Data.CAF --> evaluated by: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Data.Generics.Uniplate.Internal.Data.uniplateVerbose, called from Data.Generics.Uniplate.Internal.Data.CAF:uniplateVerbose --> evaluated by: Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.Generics.Uniplate.Internal.Data.fromOracle, called from Data.Generics.Uniplate.Internal.Data.biplateData, called from Data.Generics.Uniplate.Data.biplate, called from Main.tfComment, called from Main.qcrp.transformOut, called from Main.qcrp.parser_prop, called from Main.qcrp.parser_prop, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2, called from Test.QuickCheck.Property.forAllShrink.\.\, called from Test.QuickCheck.Property.property, called from Test.QuickCheck.Test.quickCheckWithResult.property', called from Test.QuickCheck.Test.quickCheckWithResult.\, called from Test.QuickCheck.Text.withNullTerminal, called from Test.QuickCheck.Test.quickCheckWithResult, called from Main.qc2, called from Main.qcrp, called from Main.ntc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl1945_r3oc9 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy ^C^C^C^C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:15:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:15:32 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.18be2543fce65b676ddf77e69a7eb88f@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 rwbarton): What is the bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:17:23 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.4f9af7249b43b04198d30546130a4aac@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 flip101): it's a bug that ghc is not reporting something useful -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:20:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:20:46 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.509fd43db6b6cf4b64df9fc672ccfccb@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 rwbarton): Reporting something useful about what? Please be specific. We are not mind readers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:27:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:27:21 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.9723a028931e48981e8da177381695c0@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by flip101: @@ -10,0 +10,5 @@ + + The bug is that it's a bug that ghc is not reporting something useful on + the exception. So i don't get sufficient information from the debug + facilities. When i have sufficient information i can go ahead and debug my + program. This ticket is not about solving a possible bug in my code. New description: I was told in #haskell @freenode to report this as a bug. I have a program that throws exceptions and tried debugging the problem within ghci and also outside of ghci with these commands: {{{ stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls' --executable-profiling stack exec -- vhdl +RTS -xc }}} The bug is that it's a bug that ghc is not reporting something useful on the exception. So i don't get sufficient information from the debug facilities. When i have sufficient information i can go ahead and debug my program. This ticket is not about solving a possible bug in my code. {{{#!hs tfComment :: Data from => from -> from tfComment = transformBi tf where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) tf a = a zeroPos :: Data from => from -> from zeroPos = transformBi zp where zp sp@(M.SourcePos _ _ _) = sp { M.sourceName="", M.sourceLine=unsafePos 1, M.sourceColumn=unsafePos 1} zp x = x -- (a)dd (e)xtended(i)dentifier (s)laches aeis :: Data from => from -> from aeis = transformBi x where x (IExtended a) = let updated_text :: Text updated_text = T.concat ["\\", snd $ t_text a, "\\"] in IExtended $ a {t_text = (fst $ t_text a, updated_text)} x a = a bla = something.. where parser_prop :: ContextClause -> Bool parser_prop = \x -> (transformIn <$> Right x) == (transformOut <$> parseSource parser $ T.toStrict . printSource $ transformIn x) transformIn ast = zeroPos ast transformOut ast = tfComment $ aeis $ zeroPos ast }}} ghci trace {{{ λ> :trace main Stopped in , _exception :: e = _ λ> :back Logged breakpoint at Main.hs:95:13-26 _result :: from -> from tf :: Comment -> Comment λ> :list 94 tfComment :: Data from => from -> from 95 tfComment = transformBi tf -- transformBi tf highlighted here 96 where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) λ> :back Logged breakpoint at Main.hs:242:28-57 _result :: from ast :: from λ> :list 241 transformIn ast = zeroPos ast 242 transformOut ast = tfComment $ aeis $ zeroPos ast -- tfComment $ aeis $ zeroPos ast highlighted here 243 λ> :force ast ast = Right [] λ> transformIn (Right []) Right [] λ> transformOut (Right []) Right [] λ> zeroPos (Right []) Right [] λ> aeis (Right []) Right [] λ> tfComment (Right []) Right [] }}} run with profiling options (this was aborted at some point) {{{ » stack exec -- vhdl +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Data.CAF --> evaluated by: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Data.Generics.Uniplate.Internal.Data.uniplateVerbose, called from Data.Generics.Uniplate.Internal.Data.CAF:uniplateVerbose --> evaluated by: Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.Generics.Uniplate.Internal.Data.fromOracle, called from Data.Generics.Uniplate.Internal.Data.biplateData, called from Data.Generics.Uniplate.Data.biplate, called from Main.tfComment, called from Main.qcrp.transformOut, called from Main.qcrp.parser_prop, called from Main.qcrp.parser_prop, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2, called from Test.QuickCheck.Property.forAllShrink.\.\, called from Test.QuickCheck.Property.property, called from Test.QuickCheck.Test.quickCheckWithResult.property', called from Test.QuickCheck.Test.quickCheckWithResult.\, called from Test.QuickCheck.Text.withNullTerminal, called from Test.QuickCheck.Test.quickCheckWithResult, called from Main.qc2, called from Main.qcrp, called from Main.ntc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl1945_r3oc9 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy ^C^C^C^C }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 18:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 18:59:56 -0000 Subject: [GHC] #12697: Improve output of pattern synonym info Message-ID: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> #12697: Improve output of pattern synonym info -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import GHC.Prim import Data.Kind data TypeRep :: forall k. k -> Type where TI :: TypeRep Int TB :: TypeRep Bool TL :: TypeRep [] TA :: TypeRep f -> TypeRep x -> TypeRep (f x) data (a::k1) :~~: (b::k2) where HRefl :: a :~~: a deriving instance Show (a :~~: b) eqTT :: TypeRep (a::k1) -> TypeRep (b::k2) -> Maybe (a :~~: b) eqTT TI TI = Just HRefl eqTT TB TB = Just HRefl eqTT TL TL = Just HRefl pattern IsList <- (eqTT TL -> Just HRefl) where IsList = TL }}} What is the type of `IsList`? The result of `:type` is only accurate when used as an expression (`IsList :: TypeRep []`) and the result of `:info` is uses `~#` {{{ >>> :info IsList pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~# k2, [] ~# b) => TypeRep b }}} which won't parse (`parse error on input ‘~#’`). {{{#!hs -- t9R4.hs:20:67: error: … -- • Expected kind ‘* -> *’, but ‘b’ has kind ‘k2’ -- • In the second argument of ‘~’, namely ‘b’ -- Compilation failed. pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~ k2, [] ~ b) => TypeRep b pattern IsList <- (eqTT TL -> Just HRefl) where IsList = TL }}} The user may try to use `~` but we need [https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Types.html#t:-126--126- heterogeneous equality from GHC.Types] (`~~`) {{{#!hs pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~ k2, [] ~~ b) => TypeRep b }}} and in the end, we only need {{{#!hs pattern List :: () => [] ~~ b => T b }}} `:info` should show something closer to that! Copy-pasting should work -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 19:42:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 19:42:57 -0000 Subject: [GHC] #12698: GHC panic on pattern synonym Message-ID: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> #12698: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language ViewPatterns, TypeOperators, KindSignatures, PolyKinds, TypeInType, StandaloneDeriving, GADTs, RebindableSyntax, RankNTypes, LambdaCase, PatternSynonyms, TypeApplications #-} import GHC.Types import Prelude hiding ( fromInteger ) import Data.Type.Equality import Data.Kind import qualified Prelude class Ty (a :: k) where ty :: T a instance Ty Int where ty = TI instance Ty Bool where ty = TB instance Ty a => Ty [a] where ty = TA TL ty instance Ty [] where ty = TL instance Ty (,) where ty = TP data AppResult (t :: k) where App :: T a -> T b -> AppResult (a b) data T :: forall k. k -> Type where TI :: T Int TB :: T Bool TL :: T [] TP :: T (,) TA :: T f -> T x -> T (f x) deriving instance Show (T a) splitApp :: T a -> Maybe (AppResult a) splitApp = \case TI -> Nothing TB -> Nothing TL -> Nothing TP -> Nothing TA f x -> Just (App f x) data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a eqT :: T a -> T b -> Maybe (a :~~: b) eqT a b = case (a, b) of (TI, TI) -> Just HRefl (TB, TB) -> Just HRefl (TL, TL) -> Just HRefl (TP, TP) -> Just HRefl pattern List :: () => [] ~~ b => T b pattern List <- (eqT (ty @(Type -> Type) @[]) -> Just HRefl) where List = ty pattern Int :: () => Int ~~ b => T b pattern Int <- (eqT (ty @Type @Int) -> Just HRefl) where Int = ty pattern (:<->:) :: () => fx ~ f x => T f -> T x -> T fx pattern f :<->: x <- (splitApp -> Just (App f x)) where f :<->: x = TA f x pattern Foo <- List :<->: Int }}} Using GHCi version 8.1.20160930: {{{ G$ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/td2W.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/td2W.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): ASSERT failed! k1_a2mO k1_a2mO [TCvSubst In scope: InScope {k_a2mM fx_a2mN f_a2mP x_a2mQ rep_a2ny r_a2nz scrut_a2nB $cshowsPrec_a2ob $cshow_a2p1 $cshowList_a2p8 $cty_a2pi $cty_a2po $cty_a2pw $cty_a2pJ $cty_a2pP splitApp eqT $fTy(->)(,) $fTy(->)[] $fTyTYPE[] $fTyTYPEBool $fTyTYPEInt $fShowT $mList $bList $mInt $bInt $m:<->: $b:<->:} Type env: [a2mN :-> fx_a2mN, a2mP :-> f_a2mP, a2mQ :-> x_a2mQ, a2nz :-> r_a2nz] Co env: []] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2318:46 in ghc:TyCoRep Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2318:46 in ghc:TyCoRep Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 19:49:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 19:49:56 -0000 Subject: [GHC] #12698: GHC panic on pattern synonym In-Reply-To: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> References: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> Message-ID: <066.327979fc283a92b42738fb67a6d2520d@haskell.org> #12698: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Iceland_jack): Works if supplied with type signature {{{#!hs pattern Foo :: () => [Int] ~~ t => T t pattern Foo = List :<->: Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 19:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 19:53:32 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.90ed5a094be46f5c26f1c1d66151dfb2@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://github.com/ghc-proposals/ghc- proposals/pull/16#issuecomment-253612659 comment] {{{#!hs dynHead :: Dynamic -> Maybe Dynamic dynHead (Dyn (rxs :: TypeRep txs) (xs :: txs)) = do App rl rx <- splitApp rxs Refl <- rl `eqT` (typeRep :: TypeRep []) return (Dyn rx (head xs)) }}} can be written as (I'm not sure about the `Con` definition) {{{#!hs pattern (:<->:) :: () => fa ~ f a => TypeRep f -> TypeRep a -> TypeRep fa pattern f :<->: a <- (splitApp -> Just (App f a)) where f :<->: a = TypeApp f a pattern Con :: forall (u :: k1) (b :: k2). TypeRep u => u ~~ b => TypeRep b pattern Con <- (eqT (typeRep @k1 @u) -> Just HRefl) where Con = typeRep @k1 @u pattern :: () => [Int] ~~ t => TypeRep t pattern ListInt = Con @_ @[] :<->: Con @_ @Int }}} that should work the same as {{{#!hs pattern Int :: () => Int ~~ int => T int pattern Int <- (eqT (ty @Type @Int) -> Just HRefl) where Int = typeRep pattern List :: () => [] ~~ list => T list pattern List <- (eqT (ty @(Type -> Type) @[]) -> Just HRefl) where List = typeRep pattern :: () => [Int] ~~ t => TypeRep t pattern ListInt = List :<->: Int }}} Should also be able to be defined (?) {{{#!hs pattern Int :: () => Int ~~ int => T int pattern Int = Con @Type @Int pattern List :: () => [] ~~ list => T list pattern List = Con @(Type -> Type) @[] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:06:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:06:33 -0000 Subject: [GHC] #11760: runST with lazy blackholing breaks referential transparency In-Reply-To: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> References: <044.f9450e9011a111f1ca51def99a5b24a4@haskell.org> Message-ID: <059.02273d2dbf409cb896a3ed993d637e25@haskell.org> #11760: runST with lazy blackholing breaks referential transparency -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): Right, I was also going to say it'd have to be in `>>=`, not just `runST`. The type of `noDuplicate#` should be generalised to not limit it to `RealWorld`. Is this going to be horribly expensive? Do we need rules to merge duplicate `noDuplicate#`s? In IO it's clear when we pay this expense since we do it via unsafeInterleaveIO, but in lazy ST that just corresponds to "safe" bind. For now I'll add some `noDuplicate`s in the zlib binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:20:20 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.ff2f85f09315e4b23927404a2e0d609e@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 mpickering): It still isn't clear to me what the code is which causes the exception. Could you please provide a test case which you can invoke with one invocation of the 'ghc' executable which shows the error you think is bad? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:40:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:40:14 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.03c21b848155e4b0b226e06b2eb913be@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by flip101: @@ -11,0 +11,2 @@ + Paraphrased my own words and others from irc: + @@ -16,0 +18,15 @@ + The specific issue is that it's producing what ghci calls an undefined + exception, and -xc is producing *** Exception (reporting due to +RTS -xc): + (THUNK_2_0). + "(THUNK_2_0)" doesn't tell anyone anything. I'd expect to see that it + reentered something it wasn't supposed to, or something like that. + THUNK_2_0 sounds like an internal GHC thing, which i why i'm filing a bug. + + The +RTS -xc includes names of info tables, which would help identify + *what* it's throwing on. but unless the Core is generated at the same time + during compilation, it's not possible to find out what. If i generate core + now i will get different names. The exception could even be in the + standard library. +RTS -xc definitely has a lot of room for improvement + + When the program runs normally it doesn't terminate. The GHCI run + terminate because -fbreak-on-exception was set. @@ -53,0 +70,22 @@ + λ> _exception + + :2:1: error: + • No instance for (Show e) arising from a use of ‘print’ + Cannot resolve unknown runtime type ‘e’ + Use :print or :force to determine these types + Relevant bindings include it :: e (bound at :2:1) + These potential instances exist: + instance [safe] Show Args -- Defined in ‘Test.QuickCheck.Test’ + instance [safe] Show Result -- Defined in ‘Test.QuickCheck.Test’ + instance Show a => Show (ZipList a) + -- Defined in ‘Control.Applicative’ + ...plus 297 others + ...plus 133 instances involving out-of-scope types + (use -fprint-potential-instances to see them all) + • In a stmt of an interactive GHCi command: print it + λ> :print e + + :1:1: error: Not in scope: ‘e’ + λ> :force e + + :1:1: error: Not in scope: ‘e’ New description: I was told in #haskell @freenode to report this as a bug. I have a program that throws exceptions and tried debugging the problem within ghci and also outside of ghci with these commands: {{{ stack build --ghc-options '-rtsopts -fprof-auto -fprof-auto-calls' --executable-profiling stack exec -- vhdl +RTS -xc }}} Paraphrased my own words and others from irc: The bug is that it's a bug that ghc is not reporting something useful on the exception. So i don't get sufficient information from the debug facilities. When i have sufficient information i can go ahead and debug my program. This ticket is not about solving a possible bug in my code. The specific issue is that it's producing what ghci calls an undefined exception, and -xc is producing *** Exception (reporting due to +RTS -xc): (THUNK_2_0). "(THUNK_2_0)" doesn't tell anyone anything. I'd expect to see that it reentered something it wasn't supposed to, or something like that. THUNK_2_0 sounds like an internal GHC thing, which i why i'm filing a bug. The +RTS -xc includes names of info tables, which would help identify *what* it's throwing on. but unless the Core is generated at the same time during compilation, it's not possible to find out what. If i generate core now i will get different names. The exception could even be in the standard library. +RTS -xc definitely has a lot of room for improvement When the program runs normally it doesn't terminate. The GHCI run terminate because -fbreak-on-exception was set. {{{#!hs tfComment :: Data from => from -> from tfComment = transformBi tf where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) tf a = a zeroPos :: Data from => from -> from zeroPos = transformBi zp where zp sp@(M.SourcePos _ _ _) = sp { M.sourceName="", M.sourceLine=unsafePos 1, M.sourceColumn=unsafePos 1} zp x = x -- (a)dd (e)xtended(i)dentifier (s)laches aeis :: Data from => from -> from aeis = transformBi x where x (IExtended a) = let updated_text :: Text updated_text = T.concat ["\\", snd $ t_text a, "\\"] in IExtended $ a {t_text = (fst $ t_text a, updated_text)} x a = a bla = something.. where parser_prop :: ContextClause -> Bool parser_prop = \x -> (transformIn <$> Right x) == (transformOut <$> parseSource parser $ T.toStrict . printSource $ transformIn x) transformIn ast = zeroPos ast transformOut ast = tfComment $ aeis $ zeroPos ast }}} ghci trace {{{ λ> :trace main Stopped in , _exception :: e = _ λ> _exception :2:1: error: • No instance for (Show e) arising from a use of ‘print’ Cannot resolve unknown runtime type ‘e’ Use :print or :force to determine these types Relevant bindings include it :: e (bound at :2:1) These potential instances exist: instance [safe] Show Args -- Defined in ‘Test.QuickCheck.Test’ instance [safe] Show Result -- Defined in ‘Test.QuickCheck.Test’ instance Show a => Show (ZipList a) -- Defined in ‘Control.Applicative’ ...plus 297 others ...plus 133 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of an interactive GHCi command: print it λ> :print e :1:1: error: Not in scope: ‘e’ λ> :force e :1:1: error: Not in scope: ‘e’ λ> :back Logged breakpoint at Main.hs:95:13-26 _result :: from -> from tf :: Comment -> Comment λ> :list 94 tfComment :: Data from => from -> from 95 tfComment = transformBi tf -- transformBi tf highlighted here 96 where tf (Comment ((pos_c, c), (pos_s, s))) = Comment $ ((pos_c, T.concat ["--", c]), (pos_s, s)) λ> :back Logged breakpoint at Main.hs:242:28-57 _result :: from ast :: from λ> :list 241 transformIn ast = zeroPos ast 242 transformOut ast = tfComment $ aeis $ zeroPos ast -- tfComment $ aeis $ zeroPos ast highlighted here 243 λ> :force ast ast = Right [] λ> transformIn (Right []) Right [] λ> transformOut (Right []) Right [] λ> zeroPos (Right []) Right [] λ> aeis (Right []) Right [] λ> tfComment (Right []) Right [] }}} run with profiling options (this was aborted at some point) {{{ » stack exec -- vhdl +RTS -xc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Data.CAF --> evaluated by: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 *** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: Data.Generics.Uniplate.Internal.Data.uniplateVerbose, called from Data.Generics.Uniplate.Internal.Data.CAF:uniplateVerbose --> evaluated by: Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2028_r3oe6 --> evaluated by: Data.Generics.Uniplate.Internal.Data.fromOracle, called from Data.Generics.Uniplate.Internal.Data.biplateData, called from Data.Generics.Uniplate.Data.biplate, called from Main.tfComment, called from Main.qcrp.transformOut, called from Main.qcrp.parser_prop, called from Main.qcrp.parser_prop, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2.logInput, called from Main.qc2, called from Test.QuickCheck.Property.forAllShrink.\.\, called from Test.QuickCheck.Property.property, called from Test.QuickCheck.Test.quickCheckWithResult.property', called from Test.QuickCheck.Test.quickCheckWithResult.\, called from Test.QuickCheck.Text.withNullTerminal, called from Test.QuickCheck.Test.quickCheckWithResult, called from Main.qc2, called from Main.qcrp, called from Main.ntc *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2025_r3oe3 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl2022_r3oe0 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.biplate.answer, called from Data.Generics.Uniplate.Data.biplate, called from Main.CAF:lvl1945_r3oc9 *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer6_r3ocg *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer7_r3ocp *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Data.Generics.Uniplate.Internal.Data.sybChildren.f, called from Data.Generics.Uniplate.Internal.Data.sybChildren, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f.cs, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate.f, called from Data.Generics.Uniplate.Internal.Data.insertHitMap.populate, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy --> evaluated by: Data.HashMap.Base.toList', called from Data.HashMap.Base.equal, called from Data.HashMap.Base.==, called from Data.Generics.Uniplate.Internal.Data.fixEq, called from Data.Generics.Uniplate.Internal.Data.insertHitMap, called from Data.Generics.Uniplate.Internal.Data.readCacheFollower, called from Data.Generics.Uniplate.Data.descend.answer, called from Data.Generics.Uniplate.Data.descend, called from Data.Generics.Uniplate.Operations.transform.g, called from Data.Generics.Uniplate.Operations.transform, called from Main.CAF:answer8_r3ocy ^C^C^C^C }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:42:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:42:17 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.13d4dc57f407f82eeda8fa4405c6747f@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): OK, after a bit of hacking, I have a much better, gloriously simple solution: 1. `data T` in hs-boot is treated as a "nominally distinct abstract type", whereas `data T` in hsig is treated as "totally abstract type"; the difference being that T may become definitionally equal to another type at some later point. 2. When unifying TyCons in the type inference, when we would hard failure because a totally abstract TyCon doesn't unify with something else, we *instead* treat the constraint as irreducible and continue on. This prevents `f :: (H1.T ~ H2.T) => a -> b` from being treated as inaccessible. There may be some other cases I need to handle, but this is the big one. 3. We continue to assume that abstract data is injective; e.g., `(T a ~ T b) => a -> b` should hold when T is totally abstract. When accepting a type synonym implementation of data, we need to ensure that it is injective. This can be done easily by (1) excluding any type synonyms which contain type families, and (2) ensuring that all type parameters of the type synonym are used (since "phantom" type parameters are not injective). 4. If someone DOESN'T want us to assume that `T` is injective, they should declare an open type family instead ala `type family T a` instead of `data T a`. I suppose we should permit such a declaration to be *implemented* using a type synonym, but this doesn't seem very urgent since you can always write `type instance T a = Blah a` instead. No more nonsense with open type families. Phabricator incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:42:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:42:45 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.715f8bd4cee0891ee3dde636eeb4d3c9@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 flip101): mpickering i can attempt to. However this is my first haskell project and the original file is over 2000 lines with a lot of tangled code which i assume you would like have reduced to just a few lines without any dependencies. To be honest i'm not sure if i will be able to pull that off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 21:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 21:48:42 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code In-Reply-To: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> References: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> Message-ID: <060.24dae0e7d750a1632b68195a9313bdf4@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 ezyang): I would suggest putting it under a `-W` option but you've mentioned it in the ticket; in any case, I doubt it will help anyone who doesn't already know what's going on. I ran into this because I was debugging something that was marked insoluble that wasn't (very confusing! At least the "warning" is printed in `ddump-tc-trace`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 22:22:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 22:22:32 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.ec2942df854fb5e9cab51f723b7df52b@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): Also, you may be tempted to implement this using a constraint family: {{{ signature Key where import GHC.Exts (Constraint) type family Key k :: Constraint instance Key Bool }}} But this doesn't work, because GHC expects an instance head to be a type class. (This will probably be a problem even if we allow data types that are not kind Constraint.) The "silver lining" is that you can just defer the "insoluble" constraint to the use-site. But this is terribel, and there are other problems too. Here is some code that type checks with HEAD, but it is not pretty. {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE RoleAnnotations #-} unit p where signature Key where import GHC.Exts (Constraint) type family Key :: * -> Constraint signature Map where import Key type role Map nominal representational data Map k a empty :: Map k a insert :: Key k => k -> a -> Map k a -> Map k a lookup :: Key k => k -> Map k a -> Maybe a module M where import Map import Key -- Need to stick the instance constraint here -- (and need to do it explicitly! GHC won't infer it.) x :: Key Bool => Map Bool String x = insert True "foo" empty unit q where module Key where import GHC.Exts (Constraint) type family Key :: * -> Constraint type instance Key = Ord module Map(Map, M.empty, insert, lookup) where import Prelude hiding (lookup) import Data.Map (Map) import qualified Data.Map as M import Key -- Ord is NOT definitionally equal to Key, which means -- we have to massage the types insert :: Key k => k -> a -> Map k a -> Map k a insert = M.insert lookup :: Key k => k -> Map k a -> Maybe a lookup = M.lookup unit r where dependency p[Key=q:Key, Map=q:Map] -- OK! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 22:58:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 22:58:04 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.174f84280f467ee745cde18600f4fdf8@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2592 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 23:26:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 23:26:17 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.204f1b5a1bfb1661ecd26dfc70537f1b@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tohnann): * cc: tohnann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 23:51:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 23:51:03 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels Message-ID: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 13 23:52:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 13 Oct 2016 23:52:24 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.166b6f9b8035b73c6dcf2243a76645c3@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -4,2 +4,2 @@ - renamed), renaming them causes `bkpreex06` to fail with the panic - `find_lbl missing foo`. + renamed), renaming them (in `RnModIface`) causes `bkpreex06` to fail with + the panic `find_lbl missing foo`. New description: While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them (in `RnModIface`) causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 01:12:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 01:12:13 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.daf6c0e2d8611f3df9a4ccc5ec7bebb7@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): This all makes me a bit worried. First off, I think the best way to think about all of this is in terms of generativity and injectivity. As I read comment:10 and comment:11, I worry that these two concepts are being mixed, but they're really quite separable. (Below and throughout, we talk only of nominal equality.) '''Generativity:''' If `t1` and `t2` are ''generative'', then `t1 a ~ t2 b` implies `t1 ~ t2`. It has been pointed out to me that generativity really describes a set of types, any two of which have the property above. That viewpoint may be enlightening. In particular, it says that generativity is not really an inherent property of a type, but instead exists only by relationship to other types. '''Injectivity:''' If `t` is injective, then `t a ~ t b` implies that `a ~ b`. Now, to respond to specific points in comment:10 and comment:11: > So, that was a really long way of justifying why we can't just search replace `type S` with `type family S` and `type S = Int` with `type family S = Int`. So what ''can'' we say? You say that we can't use type families because type family LHSs are not definitionally equal (in FC) to their RHSs. (These ''are'' definitionally equal in ''Haskell'', though.) I'm just a little lost as the upshot of the first section of comment:10. > a type synonym with no type families in it I think what you mean here that you want a type synonym that is generative and injective. Only things that are generative and injective can appear as type patterns (that is, type/data family LHSs and instance heads). I call "generative and injective" ''matchable''. The reason that only matchable types can appear in type patterns is that matching on anything that's not matchable is ill-defined. (Try it.) One stumbling block here is that, of course, type synonyms are not generative -- a ''synonym'' can't be generative, roughly by definition! So what you really mean is that the expansion of the type synonym, after all vanilla synonyms are expanded, is matchable. And that no variables are lost en route. This is, I imagine, what is done to implement `TypeSynonymInstances`. Let's call type synonyms with this property "pre- matchable". Now we can say: `type T a` in a signature declares a pre-matchable type synonym. Any implementing module will need to supply a pre-matchable type synonym definition for these pre-matchable type synonyms. But I agree that this is a new beast, hitherto unknown. > But if H1 and H2 are instantiated in the same way, this equality could hold! How can this happen? When I see `data`, I think you're declaring a matchable type. And matchable types are generative. Do I take that this equality between `H1` and `H2` can happen when mixing modules (as in "mix- in")? If `H1` and `H2` really ''can'' equal, then they would appear to be pre- matchable. In this case, how does a `data` definition differ from a `type` definition in a signature? > Open type families `type family T a` can be implemented by a type family, type synonym, data type or newtype. So my signature can have `type family T a` and my module `data T a = MkT`? That feels very fishy. It seems you are using `type family` as a proxy for "type that is not necessarily generative nor injective". Perhaps generativity and injectivity properties should just be specified directly. > When unifying TyCons in the type inference, This should already happen, if you set the results for `isGenerativeTyCon` and `isInjectiveTyCon` correctly. (And if the canonicalizer is implemented correctly.) You want only a mismatch between generative TyCons do have a hard error, and that should be what's implemented. -------------------- In the past, whenever I've been dwelling on these kinds of issues, I have found that always reducing the problems to generativity and injectivity to be helpful. It might be nice to have a concrete statement of what definitions in signatures mean in terms of these properties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 01:18:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 01:18:24 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.1e3c328fde78611ab25ba2c75b0c8995@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): I don't think this is #11715 but is instead related to the commentary in #12680, where there seems to be some confusion about `data` vs `type` in signatures. See comment:10:ticket:12680 and comment:11:ticket:12680. If `data` can be implemented by a type synonym (something I dislike, to be honest), then `class` should be too. Can you use `class` instead of `data` in your example? That would seem to meet your needs. After all, `class` is essentially the same as `data` but with a different result kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 02:03:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 02:03:29 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.ac10a80569a7cf3a22d713be45b45d29@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:46 Phyx-]: > Binutils 2.27-2 has been released on msys, this contains Awson's patch. Awson's patch doesn't seem to be enough: Tried Msys2 mingw64/mingw-w64-x86_64-binutils 2.27-2 with LLVM 3.7 and 64-bit GHC 8.0.1 on Windows with a simple Sieve of Eratosthenes Program, which while it compiles using the -fllvm switch still segfaults on execution but does not segfault on execution using no -fllvm switch (defaults to using NCG). However, Awson's patch does help as other versions of a similar program can be compiled with the same platform and same -fllvm switch to run successfully (and 25% faster than with NCG) whereas they never have before. I need to boil down a version that consistently fails using -fllvm and not without and will submit it here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 02:54:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 02:54:11 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.27681856fee2107b13644872493dec8a@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): goldfire and I had a chat, and here were the conclusions: 1. comment:10 is totally nonsense, ignore it. 2. I'm happy to give up on abstract type synonyms. Maybe someone will find them useful for something, but they're not necessary for the Backpack use- cases I have in mind. 3. We agreed that these two examples should fundamentally work the same way: {{{ unit p where signature H1 where data T signature H2 where data T module M where import qualified H1 import qualified H2 f :: H1.T -> H2.T f x = x -- ill typed; the Ts are NOT obviously equal g :: (H1.T ~ H2.T) => a -> b g x = x -- ill typed (H1.T ~ H2.T should not make this inaccessible) unit q where signature H1 where data T1 signature H2 where data T2 module M where import H1 import H2 f :: T1 -> T2 f x = x -- ill typed g :: (T1 ~ T2) => a -> b g x = x -- ill typed (T1 ~ T2 should not make this inaccessible) }}} 4. Here's what you do: totally abstract data types (`data T` in an hsig file) are generative AND injective. They can only be implemented by `data` (except, see below). The only difference is that we do not eagerly fail when we come up with an insoluble constraint in the givens involving a totally abstract type. As the OutsideIn(X) paper states, it is sound to not eagerly fail when simplifying givens, and removing a failure case should not impact guess-freeness of the solver. While it is true that when the solver encounters a wanted `T1 ~ T2` (where T1/T2 are totally abstract) it could kick this constraint out to the use-site, but this is silly; we really do want to report a type error here. 5. Under certain restricted circumstances, we can implement totally abstract data with a type synonym. But there are quite a few conditions that need to be upheld: it must be generative, injective, and partially applicable. A sufficient condition for the type synonym is for it to have NO type parameters and for it to have no type family applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 02:58:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 02:58:48 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.3df14c433fe22e94110060b0920c2639@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2467 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"34d933d6a821edf5abfcbee76d9325362fc28a13/ghc" 34d933d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34d933d6a821edf5abfcbee76d9325362fc28a13" Clean up handling of known-key Names in interface files Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 02:58:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 02:58:48 -0000 Subject: [GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples In-Reply-To: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> References: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> Message-ID: <061.22f9d335081a0f1063a1a262d5b97059@haskell.org> #12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"34d933d6a821edf5abfcbee76d9325362fc28a13/ghc" 34d933d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34d933d6a821edf5abfcbee76d9325362fc28a13" Clean up handling of known-key Names in interface files Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 03:04:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 03:04:31 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities Message-ID: <047.e796800360deb24c984967cba0fa772b@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `-Wall`, the following code {{{ {-# LANGUAGE TypeFamilies #-} type family Foo x where Foo Double = Int foo :: (RealFrac a, Integral b, b ~ Foo a) => a -> b foo = round }}} produces the warning {{{ • Redundant constraint: b ~ Foo a • In the type signature for: foo :: (RealFrac a, Integral b, b ~ Foo a) => a -> b }}} Technically, I suppose this is correct in the sense that if we remove the constraint `b ~ Foo a`, `foo` still compiles. However, the ''meaning'' changes without the type equality, because the function I wrote is equivalent to `foo :: (RealFrac a, Integral (Foo a)) => a -> Foo a` (which requires `-XFlexibleContexts`), while the function it suggests is the much more general `foo :: (RealFrac a, Integral b) => a -> b`. Since this is the case, I think the warning is invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 03:09:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 03:09:13 -0000 Subject: [GHC] #12701: Eta reduce type synonyms when possible Message-ID: <045.3bfc0a7badd39b1b019818a280602437@haskell.org> #12701: Eta reduce type synonyms when possible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you can eta reduce a type synonym, it is always better: {{{ -- Bad type F a = Maybe a instance Functor F -- illegal, partially applied type synonym! -- Good type F = Maybe instance Functor F -- ok with type synonym instances }}} So... GHC should do this automatically for users. Ordinarily this is not terribly important (thus the priority); in the context of #12680 it is a modestly helpful affordance which allows a user to implement `data Map a` using `type Map a = HashMap a` (signature matching requires the type synonym to be nullary.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 03:21:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 03:21:10 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.44fa956fa0cf1a2703ff089ec645834d@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2467 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: It has been done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 03:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 03:21:24 -0000 Subject: [GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples In-Reply-To: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> References: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> Message-ID: <061.2c27b395a2c3dc3cc74f940b14abb8ba@haskell.org> #12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 04:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 04:14:46 -0000 Subject: [GHC] #12702: Don't warn about redundant constraints for necessary Message-ID: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> #12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached example, GHC warns that the constraint on line 16 of Main.hs is redundant. {{{ • Redundant constraint: e ~ FGCD r s • In the type signature for: foo :: (e ~ FGCD r e', e' ~ (e * (s / r)), e ~ FGCD r s) => Proxy s -> Proxy r -> () }}} However, when I remove that constraint, I get the following error: {{{ • Occurs check: cannot construct the infinite type: t0 ~ Factored.FMul (FGCD r t0) (Factored.FDiv s r) The type variable ‘t0’ is ambiguous • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: forall e e' r s. (e ~ FGCD r e', e' ~ (e * (s / r))) => Proxy s -> Proxy r -> () }}} I'm not entirely sure if the error is correct or not; I can't figure out what it's getting on about. So: if the constraint is required to make `foo` compile, then it is most certainly ''not'' redundant, and there shouldn't be a warning suggesting its removal. If the constraint really isn't required, then the error is a bug. (I apologize for the second bug involving singletons in as many days; I simply don't know an easy way to remove that dependency.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 04:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 04:15:12 -0000 Subject: [GHC] #12702: Don't warn about redundant constraints for necessary In-Reply-To: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> References: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> Message-ID: <062.1ebf9e77dffa74f16813c32510d52a5c@haskell.org> #12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 crockeea): * Attachment "bug.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:14:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:14:01 -0000 Subject: [GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot In-Reply-To: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> References: <046.24dfdfd7e6c2171f1bdb9eda7c695193@haskell.org> Message-ID: <061.01b9a153f1c6e928952c9dea2ec962d0@haskell.org> #12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: comment:15 merged to `ghc-8.0` as fefc53011e6d961c4dd8d61386bbdd36fc83f6d0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:23:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:23:07 -0000 Subject: [GHC] #12703: Expand Backpack's signature matching relation beyond definitional equality Message-ID: <045.ac70502042cd4e3b5bdce9d4b94672a9@haskell.org> #12703: Expand Backpack's signature matching relation beyond definitional equality -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, signature matching is done by strict definitional equality. This can be pretty inconvenient in some cases (it is also the only place in the Haskell language that we actually expose definitional equality): **Polymorphism.** This is the obvious one. If I have an implementing function that is more polymorphic than my signature, I have to manually monomorphize it. {{{ unit p where signature H where import Prelude (Int) data String length :: String -> Int unit q where module H(String, length) where -- from Prelude unit r where dependency p[H=q:H] }}} Gives {{{ : error: Identifier ‘Data.Foldable.length’ has conflicting definitions in the module and its hsig file Main module: Data.Foldable.length :: Data.Foldable.Foldable t => forall a. t a -> GHC.Types.Int Hsig file: Data.Foldable.length :: GHC.Base.String -> GHC.Types.Int The two types are different }}} Essentially, you have to monomorphize any functions you want to use. Annoying! **Quantifier ordering.** Here's a more subtle one: if I don't explicitly specify a type signature, GHC will pick whatever quantifier ordering it wants. Quantifier ordering affects definitional equality. It's actually pretty easy to trigger this, since GHC seems to always pick the reverse of what you'd get if you explicitly specified the type signature: {{{ unit p where signature H where k :: a -> b -> a unit q where module H where k x y = x unit r where dependency p[H=q:H] }}} Fails with: {{{ q.bkp:7:9: error: Identifier ‘q:H.k’ has conflicting definitions in the module and its hsig file Main module: q:H.k :: t2 -> t1 -> t2 Hsig file: q:H.k :: a -> b -> a The two types are different }}} **Constraint relaxation.** In #12679, you might want to define an abstract class which you can use to let implementors pass in type class instances that they might need. But you often end up in situations where the real implementations of your functions require less constraint than the signature specifies; for example, you might write `insert :: Key k => k -> a -> Map k a -> Map k a`, but if Map is an association list and just appends the new value onto the front of the list, no Eq constraint needed! There goes another impedance matching binding. **Type families.** Type family applications aren't reduced when deciding definitional equality. {{{ {-# LANGUAGE TypeFamilies #-} unit p where signature H where f :: Int unit q where module H where type family F type instance F = Int f :: F f = 2 unit r where dependency p[H=q:H] }}} Gives {{{ q.bkp:11:9: error: Identifier ‘q:H.f’ has conflicting definitions in the module and its hsig file Main module: q:H.f :: q:H.F Hsig file: q:H.f :: GHC.Types.Int The two types are different }}} **Discussion.** It's instructive to consider what the impacts of this sort of relaxation would have on hs-boot files. Some of the equalities that users expect in the source language have operational impact: for example, the ordering of constraints affects the calling convention of the function in question. So there would need to be an impedance matching binding to reorder/drop constraints to match the defining function. We already do an impedance matching of this sort with dictionary functions; this would be a logical extension. Thus, a signature would have to monomorphize, coerce, etc--whatever it needs to show the matching holds. I think this is quite plausible, although it would require rewriting this chunk of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:24:36 -0000 Subject: [GHC] #9717: More lazy orphan module loading In-Reply-To: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> References: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> Message-ID: <060.0f27ab9586d1b5e4da09c85424fb6ce8@haskell.org> #9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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): Phab:D454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: backpack => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:26:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:26:53 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.e3cacafd199e0b7db4798fe5a3c4622e@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: lowest | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: backpack 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 ezyang): * priority: normal => lowest Comment: Since we no longer have a shaping pre-pass, it's a LOT more difficult to actually do this. Lowering priority accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:27:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:27:46 -0000 Subject: [GHC] #10798: Signatures with only types should not be included in unit keys In-Reply-To: <045.a9d0a60676134e87bb6bcdfe70d2a8f5@haskell.org> References: <045.a9d0a60676134e87bb6bcdfe70d2a8f5@haskell.org> Message-ID: <060.8231128690b700e988092a95a8785d17@haskell.org> #10798: Signatures with only types should not be included in unit keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Package system | Version: 7.11 Resolution: wontfix | Keywords: backpack 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 ezyang): * status: new => closed * resolution: => wontfix Comment: While we could do this, it goes against the compiler/package manager separation we've settled on. Best not to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:28:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:28:31 -0000 Subject: [GHC] #12053: Mode for ghc --make which only compiles the files I pass on command line In-Reply-To: <045.29aa132cfb016cf36b9e85269467760f@haskell.org> References: <045.29aa132cfb016cf36b9e85269467760f@haskell.org> Message-ID: <060.d19ccbf5cee5005a3f136f6829826a55@haskell.org> #12053: Mode for ghc --make which only compiles the files I pass on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 ezyang): * keywords: backpack => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:50:31 -0000 Subject: [GHC] #12704: Check if constraint synonym satisfies functional dependencies Message-ID: <045.a9a7c74299c8b61d662ad7a5ba1a3210@haskell.org> #12704: Check if constraint synonym satisfies functional dependencies -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When we resolve #12679, it will be possible to implement an abstract type class using a constraint synonym. However, in my implementation, I didn't implement functional dependency checking: {{{ signature H where class F a b | a -> b -- This should be an invalid implementation module H where type F a b = (Eq a, Eq b) }}} The check is annoying fiddly: we have to descend into the constraint synonym, collect all the implied fundeps, and then see if we have the ones we need, so I didn't implement it. Maybe some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 05:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 05:53:12 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.8c2707a1c164a8d7c6efd39a0c048b2f@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2595 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2595 Comment: Richard is right. I put in a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:25:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:25:33 -0000 Subject: [GHC] #12705: Renamer should reject signatures that reexport only part of a declaration Message-ID: <045.90832cf5cff9c23cff438f9cb5d5e169@haskell.org> #12705: Renamer should reject signatures that reexport only part of a declaration -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following signature is bogus, and also, unfortunately, accepted by GHC at the moment: {{{ signature A(f) where data T = MkT { f :: Bool } }}} This doesn't make any sense at all. We should reject it early. It can lead to very strange errors (see bkpreex05 in tree) but happily it is fairly easy to avoid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:42:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:42:35 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra (was: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4) In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.970ef4f79fa51b729f7b002c8ddbca67@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:47:58 -0000 Subject: [GHC] #12024: GHC leaks GHC.Prim.~# into type In-Reply-To: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> References: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> Message-ID: <066.46d806dc7ed22c99de2d5b4b9433c9a4@haskell.org> #12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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 simonpj): `:info` uses `IfaceType.pprIfaceType` which is currently less clever than `TyCoRep.pprType` (look for `Opt_PrintEqualityRelations` in the latter). This will be fixed by #16660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:49:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:49:12 -0000 Subject: [GHC] #12697: Improve output of pattern synonym info In-Reply-To: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> References: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> Message-ID: <066.49ffdcecb0375438148ae93d4e406b93@haskell.org> #12697: Improve output of pattern synonym info -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms 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 simonpj): Thanks. Dup of #12024, which is awaiting #11660 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:50:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:50:33 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.d5610ec4e046c108f196aecd1e592324@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * related: #12550, #12447, #11786, #11549 => #12550, #12447, #11786, #11549, #12024, #12697, #12510 Comment: Adding more related tickets... It'd be good to complete this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 07:59:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 07:59:32 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.14044a998608a24f4d360e22395fe9be@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => adamgundry Comment: Adam, might you look at this? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 08:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 08:01:51 -0000 Subject: [GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples In-Reply-To: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> References: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> Message-ID: <061.a97efed0167e94cabfea6042e8e8cfb3@haskell.org> #12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hooray! Well done Ben. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 08:02:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 08:02:25 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.3d5fe51dbf2906f0509e6c4099bdd2be@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2467 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also hooray! Long saga here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 08:09:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 08:09:58 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.522ebb1d0ed4889170fa835368ce2107@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't get what you mean by "the meaning changes". I understand that writing {{{ foo :: (RealFrac a, Integral (Foo a)) => a -> Foo a }}} requires `FlexibleContexts` whereas the version you wrote does not; but that's not too terrible is it? Maybe putting equalities in contexts should require `FlexibleContexts` too, since it's just as flexible. You say that "the function it suggests is the much more general...". But the two are fully equivalent, so I don't know what you have in mind by "suggests" here. Would you care to elaborate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 10:44:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 10:44:51 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.25ea03429b4b08f5332722775d32b872@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Thank you so much for making a reproducible test case -- I know it takes work to do that. There was a real bug, involving accidental name capture in the worker/wrapper pass. It only occurred under very obscure circumstances, which is why it's so hard to reproduce. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 11:27:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 11:27:51 -0000 Subject: [GHC] #12702: Don't warn about redundant constraints for necessary In-Reply-To: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> References: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> Message-ID: <062.54f6d788d81a5771dc0103ffceaa6cdd@haskell.org> #12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): > So: if the constraint is required to make foo compile, then it is most certainly not redundant, and there shouldn't be a warning suggesting its removal. Correct. But I can't reproduce this error either with HEAD or with the 8.0 branch (which has zillions of bugs fixed wrt 8.0.1). Could you see if you get the warning with either of those? You'll need to ask for `-Wredundant-constraints` explicitly, because it's no longer in `-Wall`. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 12:03:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 12:03:39 -0000 Subject: [GHC] #12704: Check if constraint synonym satisfies functional dependencies In-Reply-To: <045.a9a7c74299c8b61d662ad7a5ba1a3210@haskell.org> References: <045.a9a7c74299c8b61d662ad7a5ba1a3210@haskell.org> Message-ID: <060.7a542350e2608400eca31d834bcb93b3@haskell.org> #12704: Check if constraint synonym satisfies functional dependencies -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 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 goldfire): By "I didn't implement it", do you mean that you disallow the fundep? Or just not check the implementation? The former seems better. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 12:29:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 12:29:35 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.6a721c1397d656d706a7d76f8235d8b4@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Sorry if I was unclear, Simon. GHC says the constraint `b ~ Foo a` is redundant. To me, this warning means that GHC is suggesting it would be better to write `foo :: (RealFrac a, Integral b) => a -> b`. I disagree with GHC's suggestion: I meant to write the original signature (which is equivalent to the one which requires `FlexibleContexts`), because it is more specific and can help with type inference elsewhere in my program. Moreover, if I wrote the original signature in a different form (the `FlexibleContexts` version), GHC does ''not'' suggest it would be better to write `foo :: (RealFrac a, Integral b) => a -> b`. In that case it notices that the type restriction is meaningful. What I'm getting at here is: if A and B are equivalent (as my two signatures are), then GHC should have the same behavior when I do either one. Maybe it's difficult for GHC to realize that my particular A and B are equivalent, and I suppose that would be a valid reason to close the ticket. As to why I chose to write the signature I did instead of the `FlexibleContexts` version, it can be save some space in type signatures when some type variables are equivalent to long expressions. I don't give a whit about using `FlexibleContexts`, in fact it is enabled almost everywhere in my code already. As to whether putting type equalities in contexts should require `FlexibleContexts`: that misses the point, since I get the same warning with the original signature when the extension is enabled. GHC still behaves differently on equivalent inputs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 12:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 12:32:05 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.a65042cc354a8ef441d6b9e4ab77c219@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Funny you say that; I actually dusted off the patch last night. It's very close to working; I just need to sort out some remaining printing inconsistencies and perhaps an import loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 12:33:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 12:33:33 -0000 Subject: [GHC] #12702: Don't warn about redundant constraints for necessary In-Reply-To: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> References: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> Message-ID: <062.0c8b8e792ab50836a36d27908ec7f097@haskell.org> #12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 crockeea): If you can't reproduce with 8.0 branch, then I'd say it has been fixed by some other change. I'll let you close just in close just in case you want to add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 13:42:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 13:42:52 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.98ece59b78bf4e3fa20c8ebdceea58af@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One thing slightly non-trivial issue that I've run into on this is that I seem to walk into holes while printing with the IfaceType printer which previously we avoided. For instance, `tcfail123` fails with, {{{ =====> tcfail123(normal) 61 of 82 [0, 51, 0] cd "./typecheck/should_fail/tcfail123.run" && "/opt/exp/ghc/ghc- ifacetype/inplace/test spaces/ghc-stage2" -c tcfail123.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output Actual stderr output differs from expected: --- ./typecheck/should_fail/tcfail123.run/tcfail123.stderr.normalised 2016-10-14 09:36:08.560991222 -0400 +++ ./typecheck/should_fail/tcfail123.run/tcfail123.comp.stderr.normalised 2016-10-14 09:36:08.560991222 -0400 @@ -1,7 +1,14 @@ tcfail123.hs:11:9: Couldn't match a lifted type with an unlifted type - When matching the kind of ‘GHC.Prim.Int#’ - In the first argument of ‘f’, namely ‘3#’ - In the expression: f 3# - In an equation for ‘h’: h v = f 3# + When matching the kind of ‘GHC.Prim.Int#ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161014 for x86_64-unknown-linux): + toIfaceUnivCoProv hit a hole + {ax1} + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/iface/IfaceType.hs:: in :IfaceType + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It's not entirely clear how best to deal with this, but it does make me worried that this idea may be on shaky ground. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 14:19:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 14:19:53 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.9766f5d3fc78d84c49c769b11a312944@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The other issue is that rendering tuples, sums, and other built-in syntax things becomes a bit tricker. While previously we had access to the `TyCon` and could therefore simply use `isTupleTyCon_maybe` to identify tuples, now we only have the `IfaceTyCon` which can't easily be identified since it only gives us a `Name`. I can imagine a few (all fairly non-satisfactory) options here: * build a finite map of `TyCon` `Name`s that require special treatment. This is quite bad as it brings us back to the situation of building a map of a technically-infinite family of tycons * capture some analogue of `AlgTyConRhs` (which allows us to distinguish tuple `TyCon`s) in `IfaceTyCon` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 14:30:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 14:30:16 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.fc11fd1ebd6b3770ea81f08750b0a84c@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:13 bgamari]: > The other issue is that rendering tuples, sums, and other built-in syntax things becomes a bit tricker. While previously we had access to the `TyCon` and could therefore simply use `isTupleTyCon_maybe` to identify tuples, now we only have the `IfaceTyCon` which can't easily be identified since it only gives us a `Name`. Use `IfaceTyConInfo`: it's precisely there to guide pretty-printing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 14:33:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 14:33:10 -0000 Subject: [GHC] #12464: Add `instance Semigroup a => Semigroup (IO a)` In-Reply-To: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> References: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> Message-ID: <066.167a71a351896aa93382506701dc4800@haskell.org> #12464: Add `instance Semigroup a => Semigroup (IO a)` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2588 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8c6a3d68c0301bb985aa2a462936bbcf7584ae9c/ghc" 8c6a3d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8c6a3d68c0301bb985aa2a462936bbcf7584ae9c" Add missing Semigroup instances for Monoidal datatypes in base Summary: There are currently three datatypes that are exposed in `base` that have `Monoid` instances, but no `Semigroup` instances: * `IO` * `Event` (from `GHC.Event`) * `Lifetime` (from `GHC.Event`) (There is also `EventLifetime` in `GHC.Event.Internal`, but it is not exported directly, so I didn't bother with it.) Adding the `Semigroup` instances for these types directly in the modules in which they're defined resulted in some horrific import cycles, so I opted to take the easy approach of defining all of these instances in `Data.Semigroup`. (When `Semigroup` becomes a superclass of `Monoid`, these instances will have to be moved somehow.) Fixes #12464. Test Plan: It compiles Reviewers: hvr, ekmett, austin, bgamari Reviewed By: ekmett Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2588 GHC Trac Issues: #12464 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 14:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 14:33:41 -0000 Subject: [GHC] #12464: Add `instance Semigroup a => Semigroup (IO a)` In-Reply-To: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> References: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> Message-ID: <066.bd8552f18b827b4d6975d894ff7f1738@haskell.org> #12464: Add `instance Semigroup a => Semigroup (IO a)` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2588 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 14:46:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 14:46:57 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.08b8df0b0b43a393b83a85654f6d52ac@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One thing slightly non-trivial issue that I've run into on this is that I seem to walk into holes while printing with the IfaceType printer which previously we avoided. For instance, `tcfail123` fails The typechecker is trying to unify a lifted type with an unlifted one. So it produces {{{ [W] ax1 :: TYPE IntRep ~ TYPE LiftedPtrRep }}} which of course it can't solve. But rather than print that obscure message, it tries to print the offending type, which looks like {{{ Int# |> (hole{ax1}) }}} where `hole{ax1}` is the un-proven assertion above. The type printer suppresses the coercion (though you can see it with current GHC using `-fprint-explicit-coercions`). So for this and debugging reasons we do want to be able to print types with coercion holes in them, although they should never end up in interface files. So let's add `IfaceHoleProv` to `IfaceUnivCoProv`; and make `toIfaceType` use it. But serialisation can barf. Clearly this will need a Note, taken from this comment -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 15:09:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 15:09:57 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.ca22996959d99dd2d584eba294c6d2ee@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see * `foo` really does have the type `(RealFrac a, Integral b) => a -> b`. That is, as GHC claims, the constraint can simply be omitted. * But you specifically want to write a less-polymorphic type than the most general type. Another example might be {{{ f :: Ord a => a -> a f x = x }}} The `Ord a` is not needed, but you might want to require it for some software engineering reason. That's your situation here, I believe. * It's worth noting that you can certainly say {{{ f :: [a] -> [a] f x = x }}} thus specifying a less polymorphic type than the most general one, without causing a warning of any kind. This is one of the reasons that `-Wredundant-constraints` is no longer on by default, and is not even enabled by `-Wall`. I'm a bit sad, but the annoyance was too great. The real solution would be a per-function pragma to say "I intend to have a redundant constraint here". If I've understood aright, then we need take no action, except add it as another use-case for the per-function pragma See #11370, #10635 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 15:22:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 15:22:26 -0000 Subject: [GHC] #12681: Missing fields warning when qualified records are initialized with unqualified field names In-Reply-To: <044.c445f1fd9a044eeb249ef2fce7934ce3@haskell.org> References: <044.c445f1fd9a044eeb249ef2fce7934ce3@haskell.org> Message-ID: <059.76f871e40bc2c0947b149950cf7090ce@haskell.org> #12681: Missing fields warning when qualified records are initialized with unqualified field names -------------------------------------+------------------------------------- Reporter: lyxia | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I have not tried the released 8.0.1, but the 8.0 branch and HEAD both say {{{ T12681.hs:4:17: error: Not in scope: ‘a’ Perhaps you meant ‘T12681a.a’ (imported from T12681a) }}} which is quite reasonable. (I renamed the modules involved.) So it looks as if this one is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:13:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:13:20 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.b3ba9726c320530c0eea2a109089c08b@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 flip101): Maybe a test case is not needed to help the issue along .. i discovered some more things {{{ λ> :trace main Stopped in , _exception :: e = _ λ> :print _exception _exception = (_t1::e) λ> seq _exception () () λ> :p _exception _exception = GHC.Exception.SomeException (GHC.Exception.ErrorCallWithLocation (_t9::String) (_t10::String)) λ> _t9 "Data.Data.fromConstr" λ> _t10 "" }}} https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.Data.html#fromConstr I would say this pretty much points to the origin of the exception. I found out about the seq-trick after another read of the debugging wiki. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:16:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:16:28 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.fc65910624f2031cb1dec48161bb2e95@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've fixed this.. patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:25:59 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.843bd9eed9596fbc0a94154707cecef0@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I would have thought it was safe (but inefficient) to use `HasCafRef` instead of `NoCafInfo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:40:04 -0000 Subject: [GHC] #12696: Exception gives not enough information to be useful In-Reply-To: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> References: <046.ab59793938e09147ff693ad8d4cfed49@haskell.org> Message-ID: <061.27a0a92bfbcc11b75c07db54e7e3e08c@haskell.org> #12696: Exception gives not enough information to be useful -------------------------------------+------------------------------------- Reporter: flip101 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: exception 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 flip101): The scope of this ticket is just the issue of poorly reported exceptions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:41:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:41:50 -0000 Subject: [GHC] #12706: Collecting type info is slow Message-ID: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> #12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `:set +c` option in GHCi, I'm waiting for 10-15 seconds for {{{ Collecting type info for 34 module(s) ... }}} after both first load and subsequent reloads, even if only top-level module was modified. And GHCi uses about 1.5-2x more memory than it uses without `:set +c`. My app has about 30k lines of code. Is it expected behavior and some performance improvements are planned or it's a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 16:57:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 16:57:45 -0000 Subject: [GHC] #12044: Remove sortWith in favor of sortOn In-Reply-To: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> References: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> Message-ID: <058.ebc59b91a9e05b65e7eeb767753b5a80@haskell.org> #12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: cblp Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2659 | Differential Rev(s): Phab:D2587 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: vkonton => cblp Comment: It's really not clear to me that this is actually a refactoring that we would want to undertake. While `sortOn` and `sortWith` are semantically equivalent, they are operationally much different. Namely, for "cheap" mapping functions (e.g. projections like `fst`) `sortOn` will allocate significantly more than `sortWith`. Consider the case of, {{{#!hs x :: [(Int, String)] x = ... by = sortBy (comparing fst) x on = sortOn fst }}} The evaluation of `on` will allocate a list of type `[(Int, (Int, String))]`, `sortBy (comparing fst)` that intermediate list, and then project back to a `[(Int, String)]`. It seems to me like this would be quite undesirable. While we may not want to deprecate `GHC.Exts.sortWith` in favor of `sortOn` in particular, perhaps we want to deprecate it nevertheless. The more standard form `sortBy (comparing f)` is only a bit longer and arguably you should be forced to consider whether or not you want to use `sortOn` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:27:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:27:41 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.fc7e26314980ba426a5cbd9781176155@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d5a4e49d657682eeb6e86ae464d281974ce2f5e2/ghc" d5a4e49d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5a4e49d657682eeb6e86ae464d281974ce2f5e2" Make error when deriving an instance for a typeclass less misleading Before, when you attempted to derive an instance for a typeclass, e.g., ``` class C1 (a :: Constraint) where class C2 where deriving instance C1 C2 ``` GHC would complain that `C2`'s data constructors aren't in scope. But that makes no sense, since typeclasses don't have constructors! By refining the checks that GHC performs when deriving, we can make the error message a little more sensible. This also cleans up a related `DeriveAnyClass` infelicity. Before, you wouldn't have been able to compile code like this: ``` import System.IO (Handle) class C a deriving instance C Handle ``` Since GHC was requiring that all data constructors of `Handle` be in scope. But `DeriveAnyClass` doesn't even generate code that mentions any data constructors, so this requirement is silly! Fixes #11509. Test Plan: make test TEST=T11509 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2558 GHC Trac Issues: #11509 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:27:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:27:42 -0000 Subject: [GHC] #12355: Invalid assembly in foreign prim In-Reply-To: <043.e628067e14a84102326ba14e6b406a11@haskell.org> References: <043.e628067e14a84102326ba14e6b406a11@haskell.org> Message-ID: <058.4a9b180341bd88527ed9bafe6283d2fb@haskell.org> #12355: Invalid assembly in foreign prim -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): 2563 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c7393261e723af3651f47bcee9af8db6bb6cf17/ghc" 6c739326/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c7393261e723af3651f47bcee9af8db6bb6cf17" Check for empty entity string in "prim" foreign imports Foreign imports with "prim" convention require a valid symbol identifier (see linked issue). We check this. Fix line too long Test Plan: Validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2563 GHC Trac Issues: #12355 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:29:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:29:32 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.95e054221b48856811db770830f7685c@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12529 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 1ef274298978369e2e07b5c43e635a5ca529a0af. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:34:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:34:47 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.44bd530ea5a6301b5994c564a5d42bb6@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This would be quite an effort to backport and the issue seems non- critical. Let's punt this to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:56:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:56:23 -0000 Subject: [GHC] #12707: Add contributed performance testcase Message-ID: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> #12707: Add contributed performance testcase -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- phadej was kind enough to offer a compile-time performance testcase. Add it to the testsuite or perhaps nofib. https://gist.github.com/phadej/554c2cc7e06b98142dc0fbadb6d3a47f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 17:56:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 17:56:33 -0000 Subject: [GHC] #12707: Add contributed performance testcase In-Reply-To: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> References: <046.1bf6ea763214c7ebde7fb77e5141cdd8@haskell.org> Message-ID: <061.0a389f1c49ed4a2ec83237b175a0c61b@haskell.org> #12707: Add contributed performance testcase -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 bgamari): * component: Compiler => Test Suite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 18:39:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 18:39:31 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.73c838e4a050f179fcb939d4e0c946e7@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Could we allow local type alias declarations into contexts? E.g., {{{ foo :: (RealFrac a, Integral b, let b ~ Foo a) => a -> b }}} This would be equivalent to: {{{ foo :: forall a. (RealFrac a, Integral b, let b ~ Foo a) => a -> b }}} i.e., b doesn't leak and isn't reported as redundant. Still ideally "b" should be accessible in the function code (with ScopedTypeVariable, TypeApplications, etc.). It would be useful to me to avoid redundancy into contexts such as the following where "zs" is the type alias: {{{ xxx :: forall x xs ys zs m. ( Monad m , zs ~ Union (Filter x xs) ys , Catchable x xs , Liftable (Filter x xs) zs , Liftable ys zs ) => Variant xs -> (x -> Flow m ys) -> Flow m zs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 18:50:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 18:50:26 -0000 Subject: [GHC] #12355: Invalid assembly in foreign prim In-Reply-To: <043.e628067e14a84102326ba14e6b406a11@haskell.org> References: <043.e628067e14a84102326ba14e6b406a11@haskell.org> Message-ID: <058.16d62b027e4768d100c4fb65a51d152e@haskell.org> #12355: Invalid assembly in foreign prim -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2563 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * differential: 2563 => Phab:D2563 * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 5eab189b329344630f76b8751c1289ce480ca46b and 0f9a8a9096b3b236b80fe82f2570ca3865903518. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 19:49:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 19:49:05 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.8842329b54a274fb9a82b27c155f04e7@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 20:21:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 20:21:15 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.23e098de5f977acbb3cf1ac5d94d1e5e@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 ezyang): I'm also happy to advise on the intended semantics of interface renaming, but I really don't understand why the TcIface code goes into an OccName, and then back to a Name afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 20:51:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 20:51:32 -0000 Subject: [GHC] #12706: Collecting type info is slow In-Reply-To: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> References: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> Message-ID: <063.d484388b2d24ceb7eefbeb8c7adcddf7@haskell.org> #12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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 nomeata): > Is it expected behavior and some performance improvements are planned or it's a bug? I would not be surprised to find that this is a rather rarely used feature and may not have gotten the necessary attention. But this might also mean that there is some low-hanging fruit. I would recommend building a profiled compiler and get a profile for this bit, just to see if there are obvious hotspots. vshabanov, are you interested in working on this, or just reporting it for now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 21:37:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 21:37:17 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.c5f16c32059964f853b96931daaa7fa2@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): What's the inferred pattern type of `IsList` (#12697) {{{#!hs pattern IsList <- (eqTT TL -> Just HRefl) where IsList = TL }}} Is it {{{#!hs pattern List :: () => [] ~~ b => T b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 21:38:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 21:38:35 -0000 Subject: [GHC] #12697: Improve output of pattern synonym info In-Reply-To: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> References: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> Message-ID: <066.047d1752547d90c9dcb1ccfb31b496e6@haskell.org> #12697: Improve output of pattern synonym info -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -59,1 +59,1 @@ - pattern List :: () => [] ~~ b => T b + pattern IsList :: () => [] ~~ b => T b New description: {{{#!hs import GHC.Prim import Data.Kind data TypeRep :: forall k. k -> Type where TI :: TypeRep Int TB :: TypeRep Bool TL :: TypeRep [] TA :: TypeRep f -> TypeRep x -> TypeRep (f x) data (a::k1) :~~: (b::k2) where HRefl :: a :~~: a deriving instance Show (a :~~: b) eqTT :: TypeRep (a::k1) -> TypeRep (b::k2) -> Maybe (a :~~: b) eqTT TI TI = Just HRefl eqTT TB TB = Just HRefl eqTT TL TL = Just HRefl pattern IsList <- (eqTT TL -> Just HRefl) where IsList = TL }}} What is the type of `IsList`? The result of `:type` is only accurate when used as an expression (`IsList :: TypeRep []`) and the result of `:info` is uses `~#` {{{ >>> :info IsList pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~# k2, [] ~# b) => TypeRep b }}} which won't parse (`parse error on input ‘~#’`). {{{#!hs -- t9R4.hs:20:67: error: … -- • Expected kind ‘* -> *’, but ‘b’ has kind ‘k2’ -- • In the second argument of ‘~’, namely ‘b’ -- Compilation failed. pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~ k2, [] ~ b) => TypeRep b pattern IsList <- (eqTT TL -> Just HRefl) where IsList = TL }}} The user may try to use `~` but we need [https://hackage.haskell.org/package/ghc-prim-0.5.0.0/docs/GHC- Types.html#t:-126--126- heterogeneous equality from GHC.Types] (`~~`) {{{#!hs pattern IsList :: forall k2 (b :: k2). () => ((* -> *) ~ k2, [] ~~ b) => TypeRep b }}} and in the end, we only need {{{#!hs pattern IsList :: () => [] ~~ b => T b }}} `:info` should show something closer to that! Copy-pasting should work -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 22:11:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 22:11:30 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num Message-ID: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs >>> :kind Prelude.Num Prelude.Num :: * -> Constraint >>> :kind Main.Num Main.Num :: * -> Constraint >>> :set -fprint-explicit-runtime-reps >>> :kind Main.Num Main.Num :: TYPE k -> Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 22:32:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 22:32:15 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.99989f7d8c7ac87bb1f1b1fe947cf297@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): (I am concerned that it seems the instance resolution defaults to `Type`.. if I remove the instances (and qualify the `fromInteger` views) {{{#!hs -- × × × REMOVED × × × -- instance P.Num a => Num (a :: Type) where -- instance P.Show a => Show (a :: Type) where }}} the types of `show` and `(+)` are (let's give it a module name `UU`) {{{#!hs UU.fromInteger :: UU.Num a => Integer -> a (UU.+) :: UU.Num a => a -> a -> a UU.show :: UU.Show a => a -> String }}} whereas with those instances it seems to default to the `Type`, is this intended! {{{#!hs UU.fromInteger :: Prelude.Num a => Integer -> a (UU.+) :: Prelude.Num a => a -> a -> a (UU.show') :: Prelude.Show a => a -> String }}} ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 22:40:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 22:40:54 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.644985e48ef2736617a717e2eb45f061@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): With it and `RebindableSyntax` you can write {{{#!hs foo :: Int foo = I# u + 10 * 4 where u :: Int# u = 10 + 10 * 4 bar :: String bar = show @PtrRepLifted @Int 24 ++ show @IntRep @Int# 24 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 22:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 22:58:22 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.aaad45aaddc3647c1c18560c7cf61824@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): Should this not be allowed when `minBound :: () -> a` is allowed? {{{#!hs class Bounded (TYPE rep) where minBound :: a minBound :: a }}} for {{{#!hs instance Bounded Int# where minBound :: Int# minBound = -9223372036854775808# maxBound :: Int# maxBound = 9223372036854775807# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 22:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 22:59:08 -0000 Subject: [GHC] #12706: Collecting type info is slow In-Reply-To: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> References: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> Message-ID: <063.19c4ad638e87ccfedee7626c6d8dfc82@haskell.org> #12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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 vshabanov): Latest haskell-mode for Emacs uses ":set +c" by default. So it's not that rarely used. I will try to build a profiled compiler and look whether there is something obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 14 23:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 14 Oct 2016 23:31:02 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.94802a79fdc4b552312c553dea1c4c32@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): {{{#!hs instance Eq (MutVar# s a) where (==) :: MutVar# s a -> MutVar# s a -> Bool a == b = isTrue# (sameMutVar# a b) instance Eq (MVar# s a) where (==) :: MVar# s a -> MVar# s a -> Bool a == b = isTrue# (sameMVar# a b) instance Eq (TVar# s a) where (==) :: TVar# s a -> TVar# s a -> Bool a == b = isTrue# (sameTVar# a b) instance Eq (StableName# a) where (==) :: StableName# a -> StableName# a -> Bool a == b = isTrue# (eqStableName# a b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 01:52:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 01:52:37 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.33fc04f0e60431c7ce8249221ae62aaa@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -93,0 +93,9 @@ + {{{#!hs + class Functor (f :: Type -> TYPE rep) where + fmap :: (a -> b) -> (f a -> f b) + + instance Functor ((# , #) a) where + fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) + fmap f (# a, b #) = (# a, f b #) + }}} + @@ -98,1 +107,0 @@ - >>> :kind Prelude.Num @@ -100,0 +108,7 @@ + Main.Num :: * -> Constraint + + -- >>> :set -fprint-explicit-runtime-reps + Prelude.Num :: * -> Constraint + Main.Num :: TYPE k -> Constraint + + >>> :set -Wprint-explicit-runtime-rep @@ -101,4 +116,3 @@ - Main.Num :: * -> Constraint - >>> :set -fprint-explicit-runtime-reps - >>> :kind Main.Num - Main.Num :: TYPE k -> Constraint + Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint + + New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) fmap f (# a, b #) = (# a, f b #) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint >>> :set -Wprint-explicit-runtime-rep >>> :kind Main.Num Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 01:54:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 01:54:19 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.2655ec53c1336f6158c6b3914a061475@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -114,5 +114,3 @@ - >>> :set -Wprint-explicit-runtime-rep - >>> :kind Main.Num - Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint - - + -- >>> :set -Wprint-explicit-runtime-rep + Prelude.Num :: * -> Constraint + Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) fmap f (# a, b #) = (# a, f b #) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -Wprint-explicit-runtime-rep Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 01:56:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 01:56:15 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.e401b3ecb0ff562c9312d3f836184fee@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -114,1 +114,1 @@ - -- >>> :set -Wprint-explicit-runtime-rep + -- >>> :set -fprint-explicit-foralls New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) fmap f (# a, b #) = (# a, f b #) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -fprint-explicit-foralls Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 02:21:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 02:21:42 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.8674c8da8bd8071a093cbb879301ace3@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:46 Phyx-]: > Binutils 2.27-2 has been released on msys, this contains Awson's patch. > I need to boil down a version that consistently fails using -fllvm (with the patch on 64-bit Windows) and not without and will submit it here... Failure code as follows: {{{ {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -rtsopts #-} -- or O2 import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 50000 :: Integer -- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 (so one L1 cache size). test :: () -> [Int] test() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else loop (n - 1) loop numLOOPS main = print $ length $ test() }}} The above code consistently segfaults with 64-bit GHC 8.0.1 with LLVM 3.7 with the latest MSYS2_64 including the patch on Windows when compiled with the -fllvm flag but not on Linux 64-bit (Fedora 24) under the same conditions or without the -fllvm flag (defaulting to using NCG). It does not segfault if 'numLOOPS' is made only 1000 or if the type of 'numLOOPS' is changed from multi-precision 'Integer' to base 'Int' (64-bit integer value for 64-bit systems). I suspect there is a value such as 32768 where the segfault starts when using 'Integer'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 02:40:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 02:40:14 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.f2f5515128b0ff2c17e463b5d721ef29@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -100,0 +100,18 @@ + + class Applicative (f :: Type -> TYPE rep) where + pure :: a -> f a + (<*>) :: f (a -> b) -> (f a -> f b) + + instance Monoid m => Applicative ((# , #) m) where + pure :: a -> (# m, a #) + pure a = (# mempty, a #) + + (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) + (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) + + class Foldable (f :: Type -> TYPE rep) where + fold :: Monoid m => f m -> m + + instance Foldable ((# , #) xx) where + fold :: Monoid m => (# xx, m #) -> m + fold (# _, m #) = m @@ -101,0 +119,2 @@ + + halp where does this end New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) fmap f (# a, b #) = (# a, f b #) class Applicative (f :: Type -> TYPE rep) where pure :: a -> f a (<*>) :: f (a -> b) -> (f a -> f b) instance Monoid m => Applicative ((# , #) m) where pure :: a -> (# m, a #) pure a = (# mempty, a #) (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) class Foldable (f :: Type -> TYPE rep) where fold :: Monoid m => f m -> m instance Foldable ((# , #) xx) where fold :: Monoid m => (# xx, m #) -> m fold (# _, m #) = m }}} halp where does this end ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -fprint-explicit-foralls Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 02:58:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 02:58:06 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.9f4924ec961f0e8963a18aa0ca43a7b1@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I would have thought it was safe (but inefficient) to use HasCafRef instead of NoCafInfo. Yes, also the code obviously makes that assumption, but it does not seem to be true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 03:54:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 03:54:39 -0000 Subject: [GHC] #12709: GHC panic Message-ID: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive /tmp/tEZm.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tEZm.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160930 for x86_64-unknown-linux): kindPrimRep.go rep_a13E Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:369:9 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:337:18 in ghc:RepType typePrimRep, called at compiler/ghci/ByteCodeGen.hs:1541:15 in ghc:ByteCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} running {{{#!hs {-# Language MagicHash, PolyKinds, ViewPatterns, TypeInType, RebindableSyntax, NoImplicitPrelude #-} import GHC.Types import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim data BoxUnbox = BUB Int Int# class Num (a :: TYPE rep) where (+) :: a -> a -> a fromInteger :: Integer -> a instance Num Int where (+) = (P.+) fromInteger = P.fromInteger instance Num Int# where (+) = (+#) fromInteger (fromInteger -> I# n) = n a :: BoxUnbox a = let u :: Num (a :: TYPE rep) => a u = 1 + 2 + 3 + 4 in BUB u u }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 04:06:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 04:06:03 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.dd4b36d53bf981fd67ba639a5c731e02@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Iceland_jack): Btw this works, {{{#!hs data BoxUnbox = BUB Int Int# a :: (forall rep (a :: TYPE rep). Num a => a) -> BoxUnbox a u = BUB u u }}} as does this {{{#!hs b :: BoxUnbox b = do let u :: forall rep (a :: TYPE rep). Num a => a u = 24 BUB u u }}} and it looks like it fails on more complicated numerical equations {{{#!hs -- × × × FAILS × × × a_applied :: BoxUnbox a_applied = a (1 + 2 + 3) -- × × × FAILS × × × b' :: BoxUnbox b' = do let u :: forall rep (a :: TYPE rep). Num a => a u = 1 + 2 + 3 BUB u u }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 04:27:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 04:27:42 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.38611b64be9eab13ff5296770eebdca9@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): With the upcoming `UnboxedSums` {{{#!hs instance (Eq a, Eq b) => Eq (# a | b #) where (==) :: (# a | b #) -> (# a | b #) -> Bool (# a | #) == (# a' | #) = a == a' (# | b #) == (# | b' #) = b == b' _ == _ = False }}} In GHCi, version 8.1.20160930 it seems like you cannot partially apply unboxed sums `(# | #)` so I can't write {{{#!hs instance Functor ((# | #) a) instance Applicative ((# | #) a) instance Foldable ((# | #) a) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 04:53:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 04:53:29 -0000 Subject: [GHC] #12710: Make some reserved Unicode symbols "specials" Message-ID: <051.88b8e9f391a6c7d6ea42931dc5feec1e@haskell.org> #12710: Make some reserved Unicode symbols "specials" -------------------------------------+------------------------------------- Reporter: JoshPrice247 | Owner: JoshPrice247 Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Unicode, | Operating System: Unknown/Multiple UnicodeSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following comment is in `compiler/parser/Lexer.x`: > ToDo: ideally, → and ∷ should be "specials", so that they cannot > form part of a large operator. This would let us have a better > syntax for kinds: ɑ∷*→* would be a legal kind signature. (maybe). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 05:11:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 05:11:33 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums Message-ID: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help Prelude> :set -XUnboxedSums Prelude> :kind (# _ | _ #) :1:4: error: • GHC internal error: ‘_’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the type ‘(# _ | _ #)’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 05:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 05:32:51 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.9c13aa48002f7e0f0c6e7fd540e2f78f@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 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 Iceland_jack): With `UnboxedSums` {{{#!hs pattern Left# :: a -> (# a | b #) pattern Left# a = (# a | #) pattern Right# :: b -> (# a | b #) pattern Right# b = (# | b #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 06:06:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 06:06:27 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.e14f0a541e61dc74f7200b1f098c8316@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by richardfung): * owner: richardfung => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 06:59:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 06:59:12 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.5b16db8424e02aeca5dfb0ab642fd00c@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 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 Iceland_jack): I believe `MonadTrans` should be {{{#!hs class forall m. Monad m `Implies` Monad (t m) => MonadTrans t where lift :: Monad m => m a -> (t m) a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 07:24:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 07:24:11 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.03068d982b42d628c1c20b1c6b9a7e17@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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 Iceland_jack): Is this another example of this {{{#!hs type f ~> g = forall a. f a -> g a type f ~~> g = forall a b. f a b -> g a b newtype Free0 :: Foo Type where Free0 :: (forall q. k q => (p -> q) -> q) -> Free0 k p newtype Free1 :: ((k -> Type) -> Constraint) -> (k -> Type) -> (k -> Type) where Free1 :: (forall q. k q => (p ~> q) -> q a) -> Free1 k p a newtype Free2 :: ((k1 -> k2 -> Type) -> Constraint) -> (k1 -> k2 -> Type) -> (k1 -> k2 -> Type) where Free2 :: (forall q. k q => (p ~~> q) -> q a b) -> Free2 k p a b }}} They all follow the pattern `type FREE ĸ = (ĸ -> Constraint) -> (ĸ -> ĸ)` {{{#!hs Free0 :: FREE Type Free1 :: FREE (k -> Type) Free2 :: FREE (k1 -> k2 -> Type) }}} Maybe you could write it as? {{{#!hs data family Free :: FREE k newtype instance Free :: FREE Type where Free0 :: (forall q. k q => (p -> q) -> q) -> Free k p newtype instance Free :: forall k. FREE (k -> Type) where Free1 :: (forall q. k q => (p ~> q) -> q a) -> Free k p a newtype instance Free :: forall k1 k2. FREE (k1 -> k2 -> Type) where Free2 :: (forall q. k q => (p ~~> q) -> q a b) -> Free2 k p a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 07:30:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 07:30:41 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.53c0629a3cdaa39f9d52aa8bb7e05830@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 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 Iceland_jack): [https://www.reddit.com/r/haskell/comments/52f77p/how_would_you_express_the_free_category_in_haskell/d7k5x9r This] has one of the best examples {{{#!hs type f ~> g = forall a. f a -> g a type f ~~> g = forall a b. f a b -> g a b newtype Free0 k p = Free0 (forall q. k q => (p -> q) -> q) newtype Free1 k p a = Free1 (forall q. k q => (p ~> q) -> q a) newtype Free2 k p a b = Free2 (forall q. k q => (p ~~> q) -> q a b) class Semigroup m class Semigroup m => Monoid m class Semigroupoid c class Semigroupoid c => Category c class Category c => Arrow c }}} you can define {{{#!hs instance p `Implies` Semigroup => Semigroup (Free0 p a) instance p `Implies` Monoid => Monoid (Free0 p a) instance p `Implies` Semigroupoid => Semigroupoid (Free2 p a) instance p `Implies` Category => Category (Free2 p a) instance p `Implies` Arrow => Arrow (Free2 p a) instance p `Implies` ArrowLoop => ArrowLoop (Free2 p a) -- (?) }}} instead of {{{#!hs instance Semigroup (Free0 Semigroup a) instance Semigroup (Free0 Monoid a) instance Monoid (Free0 Monoid a) instance Semigroupoid (Free2 Semigroupoid p) instance Semigroupoid (Free2 Category p) instance Semigroupoid (Free2 Arrow p) instance Semigroupoid (Free2 ArrowLoop p) instance Category (Free2 Category p) instance Category (Free2 Arrow p) instance Category (Free2 ArrowLoop p) instance Arrow (Free2 Arrow p) instance Arrow (Free2 ArrowLoop p) instance ArrowLoop (Free2 ArrowLoop p) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 07:39:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 07:39:29 -0000 Subject: [GHC] #12044: Remove sortWith in favor of sortOn In-Reply-To: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> References: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> Message-ID: <058.e1d64b124dbb2bf00cb8104b5f187116@haskell.org> #12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: cblp Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2659 | Differential Rev(s): Phab:D2587 Wiki Page: | -------------------------------------+------------------------------------- Comment (by cblp): Somebody should investigate and document when one should use `sortOn` or `sortWith`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 07:44:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 07:44:28 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.945b7b36c4b1a135b13f8b7d54c3ca74@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Can't reproduce this neither with ghc-8.0.1.20160826+llvm-3.7, nor with ghc-8.1.20160921+llvm-4.0(HEAD). I have no segfaults in both cases (tried to increase numLOOPS to 100000 and 200000 -- no segfaults either). Perhaps, that was a bug in GHC which was fixed since 8.0.1 release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 08:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 08:20:55 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.8391737ef543bf4f7300681d7fd5d266@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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 Iceland_jack): Should it be {{{#!hs type FIX k = (* -> k) -> k data family Fix :: FIX k }}} which fits the type of `newtype Fix2 f a = In2 (f (Fix2 f a) a)` {{{#!hs Fix2 :: FIX (k -> Type) }}} or {{{#!hs type FIX k = (k -> k) -> k data family Fix :: FIX k }}} which fits `newtype Fix_ f a = In_ (f (Fix_ f) a)`'s type {{{#!hs Fix_ :: FIX (k -> Type) }}} I would be **very** interested if this somehow tied in with the example of a fixed point of mutually recursive types from [http://www.cs.ox.ac.uk/ralf.hinze/publications/SCP-78-11.pdf s] > **Definition 2.** In Haskell, mutually recursive types can be modelled as follows. > > {{{#!hs > newtype Fix_1 f1 f2 = In_1 (f1 (Fix_1 f1 f2) (Fix_2 f1 f2)) > newtype Fix_2 f1 f2 = In_2 (f2 (Fix_1 f1 f2) (Fix_2 f1 f2)) > }}} > > Since Haskell has no concept of pairs on the type level, that is, no product kinds, we have to curry the type constructors: `Fix_1 f1 f2 = Outl (Fix )` and `Fix_2 f1 f2 = Outr (Fix )`. We can get close to an arrow in a product category {{{#!hs -- Beautiful definition btw data (×) :: Cat x -> Cat y -> Cat (x, y) where Prod :: c1 a a_ -> c2 b b_ -> (c1 × c2) '(a, b) '(a_, b_) }}} but the closest I've gotten to modelling an endofunctor over a product category {{{ F = }}} is {{{#!hs type family F (pair :: (*, *)) :: (*, *) where F '(a, b) = '((Int, b), Either () (a, b)) }}} and the desired `FixProd` would probably have a type like `((*, *) -> (*, *)) -> (*, *)` (kinds can probably be generalised) {{{#!hs newtype FixProd :: FIX (*, *) where FixProd :: ... }}} Except this requires a non-`Type` return kind, I appreciate any pointers and if having a value of type `(*, *)` might ever make sense -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 12:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 12:15:55 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.1d2f24cb2aef6367b06a99a473ddade2@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 13:30:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 13:30:40 -0000 Subject: [GHC] #12699: Suspicious treatment of renaming of field labels In-Reply-To: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> References: <046.a60ad2ba4743b2fb4c2d4635b8a910e1@haskell.org> Message-ID: <061.257eace90f1aee3fc3a10af0b2c73d95@haskell.org> #12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 adamgundry): I don't really understand what is going on here with the interface renaming, unfortunately. The basic idea of the `DuplicateRecordFields` implementation is that we distinguish the `FieldLabelString`/`OccName` of a field from the `Name` of a record selector. For example, `data T = MkT { foo :: Int }` gives rise to a `FieldLabelString` `foo` whose selector `Name` is `$sel:foo:MkT`. Perhaps `ifConFields :: [IfaceTopBndr]` is the wrong type? I suspect it should originally have been `[FieldLabelString]`, i.e. the old code treated the `[OccName]` as a list of field labels (and hence had to look up the selectors corresponding to the labels in `tcIfaceDataCons`). Note that record selectors are not implicit TyThings, i.e. they have their own `IfaceDecl`s separate from the `IfaceDecl` of the datatype. Following Phab:D2467 I wonder if the right thing is to have `ifConFields :: [FieldLabel]` or `[FieldLbl IfaceTopBndr]`, so that interface files would store both the `FieldLabelString` and selector `Name` (avoiding duplication when the former can be derived from the latter)? That would allow the selector name to be renamed without affecting the label, and we could get rid of the `find_lbl` lookup business in `tcIfaceDataCons`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 13:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 13:41:13 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.4b6c2c3e0d73b5d20ed961aa1e4c942c@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've updated Phab:D2528 with the current state of my branch, which almost passes the testsuite. There 21 testsuite failures, nearly all of which are trivial changes in parentheses. In fact, I am quite tempted to accept the new output since it looks significantly more consistent than the previous output. However, there is one rather tricky testsuite failure that I'm a bit unsure how to handle. Namely, when we go to print an equality we look at the types involved to determine what operator to print. However, since we only have `IfaceType`s we can't see through type synonyms. This means that if we have an equality, {{{ (a :: GHC.Types.*) ~ (b :: GHC.Types.⋆) }}} we will render it as a heterogeneous equality (with a kind annotation on each operand) since the kinds look different (although in reality are synonyms). The solution for this that I am currently leaning towards is to represent equalities explicitly in `IfaceType` and ensure that they carry their "flavor" for pretty-printing purposes. **Failing tests**: `TEST="TypeSkolEscape T10632 T7939 T2431 ghci059 T7525 T7019a tcfail130 T9222 T8912 T8958 T12634 T2766 IPFail ContextStack2 T11252 ClassOperator tcfail041 tcrun045 tcfail211 T10858 T5837"` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:12:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:12:29 -0000 Subject: [GHC] #10122: PolyKinds: inferred type not as polymorphic as possible In-Reply-To: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> References: <045.edb4969f8dea25967994c907b9a7d88d@haskell.org> Message-ID: <060.cfe61791132b068e50abd8f2754c49e7@haskell.org> #10122: PolyKinds: inferred type not as polymorphic as possible -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10122 Blocked By: | Blocking: Related Tickets: #7688 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mpickering: @@ -52,0 +52,1 @@ + }}} New description: In the user's guide on [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/kind- polymorphism.html kind polymorphism] the following example is presented: {{{#!hs f1 :: (forall a m. m a -> Int) -> Int -- f1 :: forall (k:BOX). -- (forall (a:k) (m:k->*). m a -> Int) -- -> Int }}} "Here in f1 there is no kind annotation mentioning the polymorphic kind variable, so k is generalised at the top level of the signature for f1, making the signature for f1 is as polymorphic as possible." When I ask GHCi for the type of `f1`, it is however not as polymorphic as possible: {{{ > :t f1 f1 :: (forall a (m :: * -> *). m a -> Int) -> Int }}} Trying to compile the following program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE Rank2Types #-} module PolyFail where f :: (forall a m. m a -> Int) -> Int f g = g (Just 3) }}} Results in this error: {{{ [1 of 1] Compiling PolyFail ( PolyFail.hs, PolyFail.o ) PolyFail.hs:8:10: Kind incompatibility when matching types: m0 :: k -> * Maybe :: * -> * Expected type: m0 a0 Actual type: Maybe a1 Relevant bindings include g :: forall (a :: k) (m :: k -> *). m a -> Int (bound at PolyFail.hs:8:3) f :: (forall (a :: k) (m :: k -> *). m a -> Int) -> Int (bound at PolyFail.hs:8:1) In the first argument of ‘g’, namely ‘(Just 3)’ In the expression: g (Just 3) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:12:53 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.5ce5e6f159bc3f3b0dd3334ae8bab92a@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2591 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b501709ed79ba03e72518ef9dd101ce2d03db2de/ghc" b501709/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b501709ed79ba03e72518ef9dd101ce2d03db2de" Fix Show derivation in the presence of RebindableSyntax/OverloadedStrings Summary: To fix this issue, we simply disable `RebindableSyntax` whenever we rename the code generated from a deriving clause. Fixes #12688. Test Plan: make test TEST=T12688 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2591 GHC Trac Issues: #12688 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:14:04 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.35af26b43559693ac9d4a3d1e7abe83d@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T12688 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2591 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T12688 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:18:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:18:24 -0000 Subject: [GHC] #10437: RunHaskell error in HSExtra on Win64 In-Reply-To: <052.aa77c29a6e025461dfccfc1392459b8c@haskell.org> References: <052.aa77c29a6e025461dfccfc1392459b8c@haskell.org> Message-ID: <067.ad91016604bb91ee72d0fd20820186ef@haskell.org> #10437: RunHaskell error in HSExtra on Win64 -------------------------------------+------------------------------------- Reporter: ScottSedgwick | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: runhaskell Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I am unable to reproduce this error with GHC 8.0.1 on Windows (note that I had to add a `import Prelude hiding ((*>))` line in order to make it compile). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:19:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:19:24 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows In-Reply-To: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> References: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> Message-ID: <060.bbe4b65627ff08e115ee434352bbadb4@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8596 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:21:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:21:28 -0000 Subject: [GHC] #989: Build GHC on Windows using Microsoft toolchain In-Reply-To: <047.96e16f269cc7176052a090de33c91146@haskell.org> References: <047.96e16f269cc7176052a090de33c91146@haskell.org> Message-ID: <062.030537bfca7dcea0c1c989c29ebce6ae@haskell.org> #989: Build GHC on Windows using Microsoft toolchain ------------------------------------+--------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+--------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:26:51 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.a0d584bea84e156d22072cc27a115b11@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I think I see what is going on here. But first some background. The testsuite driver runs each testcase in its own fresh directory to ensure a clean test environment. The code responsible for this can be found in `testlib.do_test()`. This looks something like the following, {{{#!python def do_test(name, way, func, args, files): opts = getTestOpts() shutil.rmtree(opts.testdir, ignore_errors=True) os.makedirs(opts.testdir) # Copy test files into testdir and run test ... }}} Note how we invoke `rmtree` with `ignore_errors=True`, presumably to account for the fact that `testdir` may not exist (e.g. if we are running in a fresh working directory). However, this unfortunately hides any **real** errors that we may encounter while trying to delete `testdir`, in which case we'll attempt to create `testdir` when it already exists. This appears to be precisely what happens some fraction of the time on Windows. Namely, if we rework `do_test` as follows, {{{#!python def do_test(name, way, func, args, files): opts = getTestOpts() if os.path.exists(opts.testdir): print('cleaning %s' % opts.testdir) shutil.rmtree(opts.testdir, ignore_errors=False) os.makedirs(opts.testdir) # Copy test files into testdir and run test ... }}} We find the following, {{{ =====> TH_nameSpace(ext-interp) 39 of 42 [0, 3, 12] cleaning ./th/TH_nameSpace.run *** framework failure for TH_nameSpace(ext-interp) [Error 5] Access is denied: './th/TH_nameSpace.run/TH_nameSpace.exe' }}} I suspect this is due to the fact that executable images of running programs are locked and therefore cannot be deleted. The strange thing here is that the process has presumably already terminated. It seems like the test process must still be in some sort of zombie state where it has terminated and we have its exit code, but its resources (e.g. executable image) have still not been released. As one would expect, adding a `time.sleep(0.1)` before the `rmtree` hides the issue. It's not clear to me what the proper solution is here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 15:39:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 15:39:08 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.231aa2eae5181a474cab7f1d59bf839d@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ilovezfs): There's a proposal for a partial fix in https://github.com/haskell/cabal/pull/3982 (and backported to Cabal 1.24 in https://github.com/haskell/cabal/pull/3983). "Partial" fix in that the problem persists unaddressed for `cabal new- buld`, which will still trigger the "malformed mach-o: load commands size" failure. I have used the PR to build git-annex in a cabal sandbox successfully (hurray). Attempting to do the same with cabal new-build still fails as "expected." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 16:08:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 16:08:05 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.cd624def1be0b0a4011e25b258fa259a@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Logfile.CSV" added. I/O trace -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 16:08:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 16:08:51 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.19cbe1535697222260952e273fce930b@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): That (though filtering on the python process, will make a wider filter now, seems to indicate, that at least the stderr is still locked when it tries to delete the folder.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 17:01:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 17:01:31 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.9e70762784d488d43d682e753227bc52@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): oh and I seem to get a different error from you {{{ =====> TH_repGuardOutput(ext-interp) 17 of 239 [0, 9, 8] cleaning ./TH_repGuardOutput.run cd "./TH_spliceE5_prof.run" && $MAKE -s --no-print-directory TH_spliceE5_prof *** framework failure for TH_repGuardOutput(ext-interp) [Error 32] The process cannot access the file because it is being used by another process: './TH_repGuardOutput.run/TH_repGuardOutput.comp.stderr' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 17:12:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 17:12:30 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.62c5025e0dbf9c8d9465394b4b8d7d48@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "cgrun035.zip" added. Zipped ProcMon log of a failure of cgrun035 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 17:12:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 17:12:57 -0000 Subject: [GHC] #9494: Probable data corruption with GHCi 7.8.* and Zlib In-Reply-To: <047.c599b15a57b1de1c882b98999535443e@haskell.org> References: <047.c599b15a57b1de1c882b98999535443e@haskell.org> Message-ID: <062.321c0199475a0d8d462dba0e9710fddc@haskell.org> #9494: Probable data corruption with GHCi 7.8.* and Zlib -------------------------------------+------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * status: infoneeded => closed * resolution: => duplicate Comment: This is almost certainly a duplicate of https://github.com/haskell/zlib/issues/7, which lives on the right bug tracker. I've added a link on the zlib bug to this test case, so after it is considered solved the test case can be checked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 17:26:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 17:26:40 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.849bbea566207c5635cbc4fa1dbdcaad@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "ProcessName=cgrun035.exe.CSV" added. Different subset of the same trace, this time filtered on processname=cgrun035 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 19:33:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 19:33:29 -0000 Subject: [GHC] #12701: Eta reduce type synonyms when possible In-Reply-To: <045.3bfc0a7badd39b1b019818a280602437@haskell.org> References: <045.3bfc0a7badd39b1b019818a280602437@haskell.org> Message-ID: <060.4b4c719a3012e32ef10ae2d456246980@haskell.org> #12701: Eta reduce type synonyms when possible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): I'm -1 on this change, as it is very easy for a user to specify that they want eta-reduction. With this change, partially applying a type synonym would sometimes work and sometimes not, in ways that are perhaps surprising to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 20:50:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 20:50:08 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.79903934db8499f911fe3181a30e8b22@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 goldfire): By gum, this is bloody brilliant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 20:56:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 20:56:29 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.a332b91057d8ae63e441092dfbdecf04@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 goldfire): Replying to [comment:3 Iceland_jack]: > Should this not be allowed when `minBound :: () -> a` is allowed? Because `blah :: Int#` is not allowed? This would actually be OK, because methods -- even nullary ones, like `minBound` are actually functions that take dictionaries. So we're OK here. And to your question in comment:2: You won't be able to supply a default implementation of these functions because of the Golden Rule of Representation Polymorphism: You may never bind a variable whose type is representation polymorphic. Your default implementation violates this rule. I'm wondering if a `default` type signature can help, somehow, but I don't see how to write it: there's no way of saying `NotAVariable k` as a constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 21:01:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 21:01:42 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.d4d92c4640a344c3874a37e4ed6ecbba@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 nomeata): > By gum, this is brilliant. He wanted a sanity check, not a brilliance check :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 15 22:01:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 15 Oct 2016 22:01:01 -0000 Subject: [GHC] #12701: Eta reduce type synonyms when possible In-Reply-To: <045.3bfc0a7badd39b1b019818a280602437@haskell.org> References: <045.3bfc0a7badd39b1b019818a280602437@haskell.org> Message-ID: <060.da6adee907e1753871ad24b95e17279f@haskell.org> #12701: Eta reduce type synonyms when possible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: wontfix | Keywords: backpack 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 ezyang): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:01:16 -0000 Subject: [GHC] #12712: break011 is broken on Windows Message-ID: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> #12712: break011 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: break011 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `break011` testcase fails on Windows with some unexpected differences in stdout. {{{ +++ ./ghci.debugger/scripts/break011.run/break011.run.stdout.normalised 2016-10-16 01:57:26.489544400 +0000 @@ -51,6 +51,9 @@ "foo" "CallStack (from HasCallStack): error, called at Test7.hs:: in :Main") -*** Exception: foo -CallStack (from HasCallStack): - error, called at Test7.hs:: in :Main +Stopped in , +_exception :: e = SomeException + (ErrorCallWithLocation + "foo" + "CallStack (from HasCallStack): + error, called at Test7.hs:: in :Main") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:05:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:05:15 -0000 Subject: [GHC] #12712: break011 is broken on Windows In-Reply-To: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> References: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> Message-ID: <061.e05d045a7b73e3da4896ebad10aae481@haskell.org> #12712: break011 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: break011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm going to mark this test as `expect_broken` for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:20:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:20:44 -0000 Subject: [GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux Message-ID: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> #12713: Bytes allocated statistic for T10858 differs between Windows and Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Strangely `T10858` seems to pass without any trouble on 64-bit Linux with its current expected "bytes allocated" statistic of 241MB. Strangely, this test allocates 16% less on 64-bit Windows, {{{ bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T10858(normal) bytes allocated: 241655120 +/-8% Lower bound T10858(normal) bytes allocated: 222322710 Upper bound T10858(normal) bytes allocated: 260987530 Actual T10858(normal) bytes allocated: 203567896 Deviation T10858(normal) bytes allocated: -15.8 % *** unexpected stat test failure for T10858(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:28:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:28:33 -0000 Subject: [GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux In-Reply-To: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> References: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> Message-ID: <061.fac321657e6e52c6b466c0311013ec83@haskell.org> #12713: Bytes allocated statistic for T10858 differs between Windows and Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 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 bgamari): Usually I would just update the number, but I would really like to understand why this is the case. This is a rather large deviation in the compilation of a program which really shouldn't have any appreciable platform dependence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:42:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:42:53 -0000 Subject: [GHC] #12713: Bytes allocated statistic for T10858 differs between Windows and Linux In-Reply-To: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> References: <046.1fb325382eb1a6980ce23a23a2e2e164@haskell.org> Message-ID: <061.a5364f0932e3da0d1b05eb8cf3bffa99@haskell.org> #12713: Bytes allocated statistic for T10858 differs between Windows and Linux ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:43:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:43:08 -0000 Subject: [GHC] #12712: break011 is broken on Windows In-Reply-To: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> References: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> Message-ID: <061.d06a66e078725213f5a87f119425cc2f@haskell.org> #12712: break011 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: break011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:49:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:49:12 -0000 Subject: [GHC] #12714: T9405 fails on Windows Message-ID: <046.8d33f0cca216ec45205082af03358f60@haskell.org> #12714: T9405 fails on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The `T9405` testcase currently fails on Windows, {{{ }}} Contrary to what was suggested in ticket:12004#comment:3 it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:49:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:49:52 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.8345bdfa799c6f063aee57f62daab83c@haskell.org> #12714: T9405 fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by bgamari: @@ -3,0 +3,9 @@ + =====> T9405(normal) 8 of 14 [0, 1, 0] + cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405 + Wrong exit code (expected 0 , actual 2 ) + Stdout: + [1 of 1] Compiling Main ( T9405.hs, T9405.o ) + Linking T9405.exe ... + + Stderr: + make[1]: *** [Makefile:50: T9405] Error 1 New description: The `T9405` testcase currently fails on Windows, {{{ =====> T9405(normal) 8 of 14 [0, 1, 0] cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405 Wrong exit code (expected 0 , actual 2 ) Stdout: [1 of 1] Compiling Main ( T9405.hs, T9405.o ) Linking T9405.exe ... Stderr: make[1]: *** [Makefile:50: T9405] Error 1 }}} Contrary to what was suggested in ticket:12004#comment:3 it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 02:54:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 02:54:16 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.935275516ea2b40981ebefef5856564a@haskell.org> #12004: Windows unexpected failures ---------------------------------+---------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): I have opened tickets to tracking the issues which I ran into while trying to get the new Windows build bot to validate, which overlap with some of the issues mentioned in this ticket, * #12714: `T9405` failure * #12713: Unexpected allocations difference in `T10858` * #12712: `break011` failure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 03:08:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 03:08:16 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.64ebe89f4e2baf2e5545891b1899d5ee@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I spent quite a while today cleaning up the testsuite driver's Python 3 compatibility story and it seems that Python 3.5.2 is significantly less buggy than 2.7.11 with respect to this issue.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 03:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 03:14:10 -0000 Subject: [GHC] #12715: T3994 is intermittently broken on Windows Message-ID: <046.c5c17c3ffa0f5995b9ee92c16bf2d478@haskell.org> #12715: T3994 is intermittently broken on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The `T3994` testcase sometimes appears to crash on Windows, {{{ +++ ../../libraries/process/tests/T3994.run/T3994.run.stderr.normalised 2016-10-16 03:11:54.601205700 +0000 @@ -0,0 +1,2 @@ + 1521 [main] sh 5272 child_copy: cygheap read copy failed, 0x1802FE408..0x180307A08, done 0, windows pid 5272, Win32 error 299 + 7952 [main] sh 5272 C:/msys64/usr/bin/sh: *** fatal error in forked process - ccalloc would have returned NULL }}} This very well may be an msys issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 03:43:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 03:43:32 -0000 Subject: [GHC] #12715: T3994 is intermittently broken on Windows In-Reply-To: <046.c5c17c3ffa0f5995b9ee92c16bf2d478@haskell.org> References: <046.c5c17c3ffa0f5995b9ee92c16bf2d478@haskell.org> Message-ID: <061.d24b3442a54ba135c5d5074db7747909@haskell.org> #12715: T3994 is intermittently broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): It looks like `T1372` sometimes fails in a similar way, {{{ +++ ./driver/T1372/T1372.run/T1372.run.stderr.normalised 2016-10-16 03:38:08.773888500 +0000 @@ -1,2 +1,5 @@ + 4 [main] make (39172) C:/msys64/usr/bin/make: *** fatal error in forked process - CreateFileMapping cygpid.39172, Win32 error 5. Terminating. + 4 [main] make 21144 fork: child -1 - forked process 39172 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 +make[3]: C:/msys64/home/drydock/ghc/testsuite/mk/boilerplate.mk:180: fork: Resource temporarily unavailable }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 04:46:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 04:46:50 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.81456a3c513a3b3a7f53dfdd41c78721@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a fairly minimal testcase which reproduces the issue. Phyx-, can you verify that this doesn't crash in your working environment? {{{#!hs #!/usr/bin/python import sys import subprocess import os import os.path import time import shutil d = 'testdir' f = d + '/test.exe' log = d + '/log' if os.path.exists(d): shutil.rmtree(d) while True: os.makedirs(d) shutil.copy('test.exe', f) subprocess.check_call(f, stdout=open(log, 'w')) time.sleep(0.04) shutil.rmtree(d) print '.', sys.stdout.flush() }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 05:08:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 05:08:25 -0000 Subject: [GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope Message-ID: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> #12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently wrote this: {{{ {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE TypeApplications #-} module B where f :: forall a. a -> a f x = id @a x }}} And was hornswoggled for the better part of five minutes for why "a" wasn't in scope. Answer: you need `ScopedTypeVariables`. A suggestion would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 05:18:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 05:18:07 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.9a660224bf372586d077bcd9f360f91a@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): If we did like [https://github.com/mikeizbicki/subhask subhask] we could even interpret `==` in a different logic {{{#!hs -- This doesn't work unless it's closed type family Rep (rep :: RuntimeRep) :: RuntimeRep where Rep IntRep = IntRep Rep DoubleRep = IntRep Rep PtrRepUnlifted = IntRep Rep PtrRepLifted = PtrRepLifted -- etc. class Eq (a :: TYPE rep) where type Logic (a :: TYPE rep) :: TYPE (Rep rep) (==) :: a -> a -> Logic a instance Eq (Int :: Type) where type Logic Int = Bool (==) :: Int -> Int -> Bool (f == g) a = f a == g a instance Eq (Int# :: TYPE IntRep) where type Logic Int# = Int# (==) :: Int# -> Int# -> Int# (==) = (==#) instance Eq (Double# :: TYPE DoubleRep) where type Logic Double# = Int# (==) :: Double# -> Double# -> Int# (==) = (==##) }}} Come on, you know you want it ;) we can use the same `==` for EDSLs? {{{#!hs data Exp :: Type -> Type where Eq :: a -> a -> Exp Bool instance Eq (Exp a) where type Logic (Exp a) = Exp Bool (==) :: Exp a -> Exp a -> Exp Bool (==) = Eq }}} or {{{#!hs data TY = INT | BOOL data Exp :: TY -> Type where EqI :: INT -> INT -> Exp BOOL EqB :: BOOL -> BOOL -> Exp BOOL instance Eq (Exp INT) where type Logic (Exp INT) = Exp BOOL (==) :: Exp INT -> Exp INT -> Exp BOOL (==) = EqI instance Eq (Exp BOOL) where type Logic (Exp BOOL) = Exp BOOL (==) :: Exp BOOL -> Exp BOOL -> Exp BOOL (==) = EqB }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 07:00:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 07:00:21 -0000 Subject: [GHC] #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) Message-ID: <045.4ee09af1e0d9c93ce8dbfd1c44d905af@haskell.org> #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I write in a signature: {{{ data Type = TArrow t1 t2 | TApp String [Type] }}} But it turns out that the real data type only has TApp (and uses "->" as the TyCon for TArrow). It would be nice if a pattern synonym could be used to implement this "concrete abstract data type" instead. Signature matching would have to typecheck the pattern synonyms against each other, and also check for totality. Note that in this example, App would need a guard against the Arrow case; otherwise the patterns overlap, whereas in the data type above it shouldn't matter what order the patterns go in. The converse might be useful too: {{{ data Type pattern TArrow :: Type -> Type -> Type pattern TInt :: Type }}} These patterns would be available for matching, with the assumption that they weren't total. If they were implemented directly using constructors, that should not be a problem. (In fact, do we even support abstract pattern synonyms?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 09:59:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 09:59:48 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.627b5e9253bb8bb20c00817c900d649e@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari, yes the script works fine for me as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 10:01:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 10:01:45 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.8aada8a58ecd1a75f3a12e8c6f6a2553@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): that said, it also doesn't crash without the sleep in there. May be my test.exe is too simple? it's just "print 123" atm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 11:28:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 11:28:15 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.9c1d6eb51f265778b22219f3e9a2932e@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): Modifying the `traceRn` interface to the `traceTc` interface causes 3 of the performance tests to fail due to the strings being floated to the top level (by `-ffull-laziness`) and hence allocated. Previously these strings were not allocated as there is a rule which optimises `text "abc"` to `ptext (Ptr p)`. Here is the diff where I tried various things to fix this: https://phabricator.haskell.org/D2586 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 11:58:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 11:58:36 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.f2350f5311f8f08e2177ba82e24cf986@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Usage of `ignore_errors=True` was sloppy program, sorry about that. It would be better to revert back to the original (working and commented) code: {{{ def clean_full_path(name): try: # Remove files... os.remove(name) except OSError as e1: try: # ... and empty directories os.rmdir(name) except OSError as e2: # We don't want to fail here, but we do want to know # what went wrong, so print out the exceptions. # ENOENT isn't a problem, though, as we clean files # that don't necessarily exist. if e1.errno != errno.ENOENT: print(e1) if e2.errno != errno.ENOENT: print(e2) }}} On the real bug: you could try to eliminate any possible problems with `timeout`: {{{ - r = subprocess.call([timeout_prog, timeout, cmd], + r = subprocess.call(['sh', '-c', cmd], }}} On Windows the testsuite uses a `timeout` program written in Haskell, on all other platforms `timeout` is written in Python. I'm not quite sure why two separate versions exist, but all the code is in `testsuite/timeout`. Fwiw: I couldn't reproduce this issue myself, last time I tried. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 12:49:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 12:49:12 -0000 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@haskell.org> References: <047.d854a286f40f24efedada1697ad637ee@haskell.org> Message-ID: <062.bc97e73937aef9ae464833ae99211c7f@haskell.org> #1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 14:00:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 14:00:32 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.385e80f3aa74b5e5e82440b2d7b10307@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => cpp * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 14:11:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 14:11:04 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.cf9204166036b34810234efdee0c3f7a@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen 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 thomie): See also #11758, where a failed attempt was made to delete the hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 14:31:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 14:31:22 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.b373b2694bb4aca49533939d69b18c37@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 goldfire): I think your first '''Edit:''' in comment:13 is orthogonal to the overall ticket and could be accomplished by generalizing `Eq` along similar lines to what you've done but without representation polymorphism. And we must be careful: while this is a new sword that slays many beasts, it doesn't slay ''all'' beasts, nor should we expect it to. Your '''Edit 2''' looks like a beast it doesn't slay. Some smart design will be needed for us to learn how to wield this sword, and I would favor implementing this all in a library for a cycle before thinking about moving anything into `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 14:53:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 14:53:48 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.31492c8d7b460f4a6a274ff4c5958acd@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 thomie): The reason we don't build `mkUserGuideParts` with stage0 currently is that it depends on the `ghc` library. `Main.hs` import `DynFlags`, although currently only to get to `glasgowExtsFlags`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 14:55:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 14:55:16 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.f7d76fa06ebe69ffc195f07448bc394f@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have no good advice to suggest for comment:17. Printing equality is currently an unpleasant compromise and would love a brand new approach. In particular, do not worry about wibbles against the status quo! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 16:30:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 16:30:58 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.299749eec3823555e9606c94cb96b21a@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539, #12716 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1316, #3691, #11438, #10581, #11539 => #1316, #3691, #11438, #10581, #11539, #12716 Comment: Another request for this feature: #12716. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 16:31:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 16:31:20 -0000 Subject: [GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope In-Reply-To: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> References: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> Message-ID: <060.5170a3c4628d796e18b2e3b8343b94f4@haskell.org> #12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 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 thomie): Duplicate of #9244 (and #1316, #3691, #11438, #10581, #11539, ...). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 16:31:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 16:31:31 -0000 Subject: [GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope In-Reply-To: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> References: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> Message-ID: <060.02cbe87c7eec383742040cf32497fd3b@haskell.org> #12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | 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 thomie): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 16:34:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 16:34:55 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.a39b69305dce838c37613d4ae480150e@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I pushed some patches which I was testing with to Phab:D2598. They cover a few things including Python 3 compatibility, working around the `cleanup` issue described above, disabling usage of symlinks on Windows (since they require administrator privileges)n and marking a few tests as broken. Unfortunately the `cleanup` workaround only narrows the Window and does not close it entirely. Phyx- has isolated the `cleanup` problem as being a regression in the `msys2-runtime` package. 2.5.1 apparently works but 2.5.2 seems to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 17:46:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 17:46:10 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.3021bc3e40a48168d2732bc28c8a2c2d@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, so I've been trying to work out how to downgrade our Windows builder to a non-broken version of `msys2-runtime` (namely 2.5.1). It seems that the current installer executable ships with a 2.6 runtime, which is not compatible with the 2.5 series. Consequently it is necessary to use a release from July 2016 instead (http://repo.msys2.org/distrib/x86_64/msys2-base-x86_64-20160719.tar.xz). From this release you can downgrade the runtime with `pacman -U`. Namely I'm using http://repo.msys2.org/msys/x86_64/msys2-runtime-2.5.1-1-x86_64.pkg.tar.xz. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 17:48:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 17:48:51 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism Message-ID: <051.1845a6905973bf302772cb06f664a84f@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RebindableSyntax, NoImplicitPrelude, MagicHash, RankNTypes, PolyKinds, ViewPatterns, TypeInType, FlexibleInstances #-} import Prelude hiding (Eq (..), Num(..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE rep) where (+) :: a -> a -> a fromInteger :: Integer -> a instance P.Num a => Num a where (+) = (P.+) fromInteger = P.fromInteger instance Num Int# where (+) = (+#); fromInteger (fromInteger -> I# n) = n u :: Bool u = isTrue# v_ where v_ :: forall rep (a :: TYPE rep). Num a => a v_ = fromInteger 10 }}} segfaults {{{#!hs $ ./bin/repo/ghc4/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/tMjN.hs GHCi, version 8.1.20160930: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tMjN.hs, interpreted ) Ok, modules loaded: Main. *Main> u True *Main> Segmentation fault (core dumped) $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 18:06:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 18:06:06 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.f0fada6a7522498f0ae6e2587a29e1a6@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): I personally find this beautiful (and it made me think of a solution to something I promised to email you a long time ago Richard, correspondence is not my strong suit) {{{#!hs instance P.Num a => Num (a :: Type) where (+) :: a -> a -> a (+) = (+#) -- ... instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show }}} so I believe this could easily be an “alternate” Prelude, people continue to define instances for `Prelude.Num` which makes them instances of our runtime-representation polymorphic `Num`. A great benefit of `Num` is that I can write {{{#!hs ten :: Num a => a ten = 1 + 2 + 3 + 4 }}} and later define my own type, and it was as if `ten` had been defined with it in mind: {{{#!hs data Exp = I Integer | Exp :+: Exp | ... instance Num Exp where (+) :: Exp -> Exp -> Exp (+) = (:+:) fromInteger :: Integer -> Exp fromInteger = I -- >>> ten :: Exp -- ((I 1 :+: I 2) :+: I 3) :+: I 4 }}} Trouble is `ten` must be lifted (`ten :: Prelude.Num a => a`) so we cannot pass it to `I#`, but we can write {{{#!hs reNum :: (forall a. P.Num a => a) -> (forall rep (b :: TYPE rep). Num b => b) reNum f = fromInteger (f @Integer) ten' :: forall rep (a :: TYPE rep). Num a => a ten' = reNum ten }}} which constant folds the rich structure `((I 1 :+: I 2) :+: I 3) :+: I 4` into `I 10 :: Exp` but it's fine for `I# (ten' :: Int#)` (which does work in HEAD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 18:37:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 18:37:55 -0000 Subject: [GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope In-Reply-To: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> References: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> Message-ID: <060.c186707ede04c03b5a5d32b67c0e616d@haskell.org> #12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | 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 ezyang): I saw that bug, but it looks completely different (a request for name shadowing warnings at the type variable level), but OK ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 18:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 18:41:32 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.144314a4ec78316b6faaa3bc70d87113@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 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 ezyang): Thanks for the diff. Surely whatever problem traceRn has, traceTc has too? Adding a rule for both cases seems useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 19:15:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 19:15:30 -0000 Subject: [GHC] #12719: master branch broken with alex 3.2 Message-ID: <046.5acda0269d9f6f68996eb49b289d17fe@haskell.org> #12719: master branch broken with alex 3.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The build fails with all sorts of type errors. Need to work out what is going on when there is time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 19:25:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 19:25:05 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.478d3275ac2b90251811e78214c5a469@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): The rule doesn't seem to fix anything. I can't reproduce the failing tests on my machine which makes development slow. You are right though that there is also this problem with traceTc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 21:55:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 21:55:10 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.5ce2d402cd737b2a063f04c283f9b97d@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So we're still at it. The current state of things is that, * msys `python-3.4.3` works with `msys2-runtime < 2.5.2` * msys `python-3.4.3`` does not work with runtime 2.5.1 nor 2.5.2 * mingw `python-2.7.11` does not work with either runtime In all cases the failure mode is error 183 during test directory deletion. In light of this it seems likely that there are two bugs: * CPython has a Windows compatibility bug (hence none of the mingw builds work) * `msys2-runtime >= 2.5.2` has a regression While the `msys2-runtime` issue is likely easier to track down since its a regression over a rather small diff, it's unfortunately not the issue we really care about. We'd far prefer to have mingw python working; unfortunately this is a much harder issue to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 22:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 22:10:19 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.d39195023cbb6853f297d03de5e918dc@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx- contributed another invaluable data point: * mingw `python-3.4.3` works with runtime 2.5.1 So it seems that there is very likely a Python regression between 3.4.3 and 3.5.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 22:36:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 22:36:39 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.04a0b1aeb46e567ae65825e10958e458@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx- also tested mingw `python-3.4.3` with runtime 2.5.2. It failed, although perhaps not as frequently as with runtime 2.5.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 22:38:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 22:38:51 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.741a3e7bb4349dd754b5c42bcda8a7be@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx said that his nightly server has been reliably running msys `python-3.4.3` and `msys2-runtime` 2.5.0 for quite some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 22:40:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 22:40:23 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.871c17755c047124857e1d1e1bac3b7b@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Not my nightly, my main development machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 23:02:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 23:02:07 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.5d4bf6e3d2cc4d68e1beea757671cdbf@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx- ran a run on his server to `msys2-runtime` 2.5.0 and mingw `python-3.4.3` and found that it too failed, despite comment:21. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 23:05:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 23:05:34 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.161e13f1c7bde8da17c56d5547a1c8c6@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Two runs with msys `python-3.4.3` and `msys-runtime-2.5.0` passed as clean. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 16 23:36:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 16 Oct 2016 23:36:43 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.f07e091fe9fe3ac66401edfa085cea85@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Apparently this is only an issue with `msys2-runtime >= 1.5.1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 00:08:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 00:08:43 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.6f37f77dd7c80439c2d3fa406846d119@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Phyx-): I believe you mean `msys2-runtime >= 2.5.1` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 00:11:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 00:11:55 -0000 Subject: [GHC] #12720: Remoce ghcii.sh Message-ID: <044.2156db9af47b28addd1e457b901c3291@haskell.org> #12720: Remoce ghcii.sh --------------------------------------+---------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- On Windows we have an extra script `ghcii.sh` that is recommended when we run in a console that does not use `conhost`. e.g mintty from msys2 or the cygwin shell. This is because the sigINT signal is being swallowed by these consoles. I believe we can work around this by listening to Window messages as well. These consoles do their own drawings, which means they load `gdi32.dll`. Which means they have a message pump so should be receiving Window events. See https://msdn.microsoft.com/en- us/library/windows/desktop/ms686016(v=vs.85).aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 00:16:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 00:16:44 -0000 Subject: [GHC] #12721: Implement sigINT handler for Window's timeout.exe Message-ID: <044.42a4ccfd5f9a2869586ed8f0bc527884@haskell.org> #12721: Implement sigINT handler for Window's timeout.exe ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- On linux we current register a sigINT handler and kill the child processed. On Windows we don't. This sometimes leaves dangling processes when the testsuite is interrupted. Causing future failures until the dangling processes are killed. We already specifically create a job group and assign the processors to those jobs. All we have to do is register the handler and kill the process if the handler is called. See https://msdn.microsoft.com/en- us/library/windows/desktop/ms686016(v=vs.85).aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 00:17:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 00:17:20 -0000 Subject: [GHC] #12720: Remoce ghcii.sh In-Reply-To: <044.2156db9af47b28addd1e457b901c3291@haskell.org> References: <044.2156db9af47b28addd1e457b901c3291@haskell.org> Message-ID: <059.00f6b0ae69929d1de69ff4204f03f351@haskell.org> #12720: Remoce ghcii.sh ----------------------------+-------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+-------------------------------------- Changes (by Phyx-): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 01:57:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 01:57:29 -0000 Subject: [GHC] #12722: Compile bug when upgrading stack-1.2.0 on Mac OS X Message-ID: <049.77e656eb700eb090885f46f3408ea940@haskell.org> #12722: Compile bug when upgrading stack-1.2.0 on Mac OS X -------------------------------------+------------------------------------- Reporter: pisomojado | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- output from stack upgrade: {{{ michael at gelato:~/Code/autorefactorer-site$ stack upgrade Fetching package index ...remote: Counting objects: 1, done. remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0 Unpacking objects: 100% (1/1), done. Fetched package index. Populated index cache. store-core-0.2.0.2: configure store-core-0.2.0.2: build http-client-0.5.3.1: configure http-client-0.5.3.1: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build path-0.5.8: configure path-0.5.8: build store-core-0.2.0.2: copy/register th-lift-instances-0.1.7: configure path-0.5.8: copy/register th-lift-instances-0.1.7: build path-io-1.1.0: configure path-io-1.1.0: build th-lift-instances-0.1.7: copy/register th-orphans-0.13.1: configure path-io-1.1.0: copy/register th-orphans-0.13.1: build unicode-transforms-0.1.0.1: configure unicode-transforms-0.1.0.1: build unicode-transforms-0.1.0.1: copy/register optparse-applicative-0.13.0.0: copy/register th-orphans-0.13.1: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-simple-0.0.3: copy/register http-client-0.5.3.1: copy/register http-client-tls-0.3.0: configure http-client-tls-0.3.0: build http-client-tls-0.3.0: copy/register http-conduit-2.2.0: configure http-conduit-2.2.0: build th-utilities-0.2.0.1: copy/register store-0.2.1.2: configure store-0.2.1.2: build http-conduit-2.2.0: copy/register store-0.2.1.2: copy/register stack-1.2.0: configure [1 of 1] Compiling Main ( /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/Setup.hs, /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.2.0... stack-1.2.0: build Preprocessing library stack-1.2.0... [ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 96] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc20328_0/libghc_55.dylib, 5): no suitable image found. Did find: /var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/ghc20328_0/libghc_55.dylib: malformed mach-o: load commands size (47024) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 14 action(s). -- While building package stack-1.2.0 using: /private/var/folders/vy/td7mc44s36g6b_wvdz7258rw0000gn/T/stack- upgrade19320/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 02:15:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 02:15:27 -0000 Subject: [GHC] #12722: Compile bug when upgrading stack-1.2.0 on Mac OS X In-Reply-To: <049.77e656eb700eb090885f46f3408ea940@haskell.org> References: <049.77e656eb700eb090885f46f3408ea940@haskell.org> Message-ID: <064.f8aebf1edb66b75176547f692c8cf5e6@haskell.org> #12722: Compile bug when upgrading stack-1.2.0 on Mac OS X -------------------------------------+------------------------------------- Reporter: pisomojado | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 03:16:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 03:16:04 -0000 Subject: [GHC] #12719: master branch broken with alex 3.2 In-Reply-To: <046.5acda0269d9f6f68996eb49b289d17fe@haskell.org> References: <046.5acda0269d9f6f68996eb49b289d17fe@haskell.org> Message-ID: <061.0ed7665532004d2a3f0abd1a6e164f34@haskell.org> #12719: master branch broken with alex 3.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: upstream Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 bgamari): * status: new => upstream * cc: simonmar (added) Comment: See https://github.com/simonmar/alex/issues/98. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 06:32:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 06:32:10 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.877602023a81840609920200ab132ad8@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:49 awson]: > Can't reproduce this neither with ghc-8.0.1.20160826+llvm-3.7, nor with ghc-8.1.20160921+llvm-4.0(HEAD). I have no segfaults in both cases (tried to increase numLOOPS to 100000 and 200000 -- no segfaults either). > > Perhaps, that was a bug in GHC which was fixed since 8.0.1 release? @awson, Perhaps it has been fixed which would be good - I'm using 64-bit Haskell Platform with stock/stable 8.0.1. I'm also having segfaults with -fllvm and not without even though I don't believe it's using 'Integer' with the following paged Sieve of Eratosthenes code: {{{ {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -rtsopts #-} -- or O2 import Data.Bits import Data.Array.Base import Data.Array.ST (runSTUArray, STUArray(..)) type PrimeType = Int range = 1000000 :: PrimeType szPGBTS = (2^14) * 8 :: PrimeType -- CPU L1 cache in bits szBPBTS = (2^7) * 8 :: PrimeType -- base primes pages can be much smaller primesPages :: PrimeType -> [UArray PrimeType Bool] primesPages szpgbts = pagesFrom 0 szPGBTS bppgs where makePg lowi szbts bps = runSTUArray $ do let limi = lowi + szbts - 1 let nxt = 3 + limi + limi -- last candidate in range cmpsts <- newArray (lowi, limi) False let pbts = fromIntegral szbts let cull (p:ps) = let sqr = p * p in if sqr > nxt then return cmpsts else let pi = fromIntegral p in let cullp c = if c > pbts then return () else do unsafeWrite cmpsts c True cullp (c + pi) in let a = (sqr - 3) `shiftR` 1 in let s = if a >= lowi then fromIntegral (a - lowi) else let r = fromIntegral ((lowi - a) `rem` p) in if r == 0 then 0 else pi - r in do { cullp s; cull ps } if bps == [] then do pg0 <- unsafeFreezeSTUArray cmpsts cull $ listPagePrms [pg0] else cull bps pagesFrom lowi bts bps = let cf lwi = case makePg lwi bts bps of pg -> pg `seq` pg : cf (lwi + bts) in cf lowi bppgs = -- secondary stream of primes listPagePrms (makePg 0 szBPBTS [] : (pagesFrom szBPBTS szBPBTS bppgs)) listPagePrms :: [UArray PrimeType Bool] -> [PrimeType] listPagePrms (hdpg @ (UArray lowi _ rng _) : tlpgs) = let loop i = if i >= rng then listPagePrms tlpgs else if unsafeAt hdpg i then loop (i + 1) else let ii = lowi + fromIntegral i in case 3 + ii + ii of p -> p `seq` p : loop (i + 1) in loop 0 primesPaged :: () -> [PrimeType] primesPaged() = 2 : (listPagePrms $ primesPages szPGBTS) main = print $ length $ takeWhile ((>=) range) $ primesPaged() }}} The above segfaults for the "range" set to a million, but not for some lesser values (ie. a hundred thousand) for '-fllvm' with the same environment as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 06:53:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 06:53:52 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.489f187fb7f078dd6d1da190345c2808@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11746,#11972 | Differential Rev(s): Phab:D2189, Wiki Page: | Phab:D2512 -------------------------------------+------------------------------------- Changes (by akio): * status: new => closed * resolution: => fixed Comment: I believe this ticket can be closed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:42:20 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.63a3dfa74c8151f9c153e46743b7995d@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"692c8df03969ee6a0de5158f05907b16689945d0/ghc" 692c8df0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="692c8df03969ee6a0de5158f05907b16689945d0" Fix shadowing in mkWwBodies This bug, exposed by Trac #12562 was very obscure, and has been lurking for a long time. What happened was that, in the worker/wrapper split a tyvar binder for a worker function accidentally shadowed an in-scope term variable that was mentioned in the body of the function It's jolly hard to provoke, so I have not even attempted to make a test case. There's a Note [Freshen WW arguments] to explain. Interestingly, fixing the bug (which meant fresher type variables) revealed a second lurking bug: I'd failed to apply the substitution to the coercion in the second last case of mkWWArgs, which introduces a Cast. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:42:20 -0000 Subject: [GHC] #12698: GHC panic on pattern synonym In-Reply-To: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> References: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> Message-ID: <066.9206138d0dfce2849797592e216cbae4@haskell.org> #12698: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 Simon Peyton Jones ): In [changeset:"a693d1cb0ee9499af3145d73b1aebe5b6df0da98/ghc" a693d1cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a693d1cb0ee9499af3145d73b1aebe5b6df0da98" Correct order of existentials in pattern synonyms Trac #12698 exposed a nasty bug in the typechecking for pattern synonmys: the existential type variables weren't being put in properly-scoped order. For some reason TcPatSyn.tcCollectEx was colleting them as a set, not as a list! Easily fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:42:20 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.cc1c432d71b5fa10e36dccd6347a21d1@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f7278a9068dab28f50351c18177cc352d6570285/ghc" f7278a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7278a9068dab28f50351c18177cc352d6570285" Fix wrapping order in matchExpectedConTy The wrappers in matchExpectedConTy were being composed back to front, resulting in a Core Lint error. Yikes! This has been here a long time. Fixes Trac #12676. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:42:20 -0000 Subject: [GHC] #12681: Missing fields warning when qualified records are initialized with unqualified field names In-Reply-To: <044.c445f1fd9a044eeb249ef2fce7934ce3@haskell.org> References: <044.c445f1fd9a044eeb249ef2fce7934ce3@haskell.org> Message-ID: <059.67ff25bf743cf1329dd6fe9f37a9d466@haskell.org> #12681: Missing fields warning when qualified records are initialized with unqualified field names -------------------------------------+------------------------------------- Reporter: lyxia | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"179076260624ead5a6c5d96e94f551cfeac9dec9/ghc" 17907626/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="179076260624ead5a6c5d96e94f551cfeac9dec9" Test Trac #12681 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:43:53 -0000 Subject: [GHC] #12698: GHC panic on pattern synonym In-Reply-To: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> References: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> Message-ID: <066.4f7832609994c4b2c7caab24382f3b85@haskell.org> #12698: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms 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 simonpj): * status: new => merge Comment: Merge to 8.0 if poss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:44:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:44:39 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.45f1df8b089deef67b66a280f89aecbd@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Thanks for a great bug report! Merge to 8.0 if poss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:45:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:45:22 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.5850ad0890e5b0ff50c9cbce27cfe465@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): * status: new => merge Comment: Nailed it at last. Thank you for taking so much trouble to making a repro case. Merge to 8.0 if poss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:50:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:50:07 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.9c87c5a51fd5c4056a27d3155b19d509@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 cocreature): Thank you for fixing it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:56:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:56:48 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI Message-ID: <045.8e0096947045c15d555e41eb71d679da@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This leads to the following delightful, five module bug: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a type instance F Int = Bool -- B.hs module B where import A -- C.hs module C where import B -- D.hs module D where import C -- E.hs module E where import D import B }}} Build these modules. Then rename A to A2 (fixing B's import), and build them again. You'll get: {{{ ezyang at sabre:~/Dev/labs/T3871$ ghc --make E.hs [1 of 5] Compiling A2 ( A2.hs, A2.o ) [2 of 5] Compiling B ( B.hs, B.o ) [3 of 5] Compiling C ( C.hs, C.o ) [B changed] [5 of 5] Compiling E ( E.hs, E.o ) [B changed] attempting to use module ‘A’ (./A.hs) which is not loaded }}} The problem is clear: D was not recompiled, but it needs to be, because when the module gets renamed, we need to update its list of family instance modules to rename A to A2. When we don't do this, the subsequent family instance check chokes because it tries to load A. And why did D decide not to get recompiled? Because the ABI hash of B did not change. And that's WRONG. (Also, family instances are really awful, you really do have to rebuild everything when you change them. UGH.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:57:15 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI In-Reply-To: <045.8e0096947045c15d555e41eb71d679da@haskell.org> References: <045.8e0096947045c15d555e41eb71d679da@haskell.org> Message-ID: <060.484d11fd230befdc29ca7fd8a51ed3a1@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -44,1 +44,1 @@ - decide not to get recompiled? Because the ABI hash of B did not change. + decide not to get recompiled? Because the ABI hash of C did not change. New description: This leads to the following delightful, five module bug: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a type instance F Int = Bool -- B.hs module B where import A -- C.hs module C where import B -- D.hs module D where import C -- E.hs module E where import D import B }}} Build these modules. Then rename A to A2 (fixing B's import), and build them again. You'll get: {{{ ezyang at sabre:~/Dev/labs/T3871$ ghc --make E.hs [1 of 5] Compiling A2 ( A2.hs, A2.o ) [2 of 5] Compiling B ( B.hs, B.o ) [3 of 5] Compiling C ( C.hs, C.o ) [B changed] [5 of 5] Compiling E ( E.hs, E.o ) [B changed] attempting to use module ‘A’ (./A.hs) which is not loaded }}} The problem is clear: D was not recompiled, but it needs to be, because when the module gets renamed, we need to update its list of family instance modules to rename A to A2. When we don't do this, the subsequent family instance check chokes because it tries to load A. And why did D decide not to get recompiled? Because the ABI hash of C did not change. And that's WRONG. (Also, family instances are really awful, you really do have to rebuild everything when you change them. UGH.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 07:57:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 07:57:37 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI In-Reply-To: <045.8e0096947045c15d555e41eb71d679da@haskell.org> References: <045.8e0096947045c15d555e41eb71d679da@haskell.org> Message-ID: <060.99c71d895acb75c5fbf3571287b0661f@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -49,0 +49,3 @@ + + This occasionally affected the Cabal project, see + https://github.com/haskell/cabal/issues/3871 New description: This leads to the following delightful, five module bug: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a type instance F Int = Bool -- B.hs module B where import A -- C.hs module C where import B -- D.hs module D where import C -- E.hs module E where import D import B }}} Build these modules. Then rename A to A2 (fixing B's import), and build them again. You'll get: {{{ ezyang at sabre:~/Dev/labs/T3871$ ghc --make E.hs [1 of 5] Compiling A2 ( A2.hs, A2.o ) [2 of 5] Compiling B ( B.hs, B.o ) [3 of 5] Compiling C ( C.hs, C.o ) [B changed] [5 of 5] Compiling E ( E.hs, E.o ) [B changed] attempting to use module ‘A’ (./A.hs) which is not loaded }}} The problem is clear: D was not recompiled, but it needs to be, because when the module gets renamed, we need to update its list of family instance modules to rename A to A2. When we don't do this, the subsequent family instance check chokes because it tries to load A. And why did D decide not to get recompiled? Because the ABI hash of C did not change. And that's WRONG. (Also, family instances are really awful, you really do have to rebuild everything when you change them. UGH.) This occasionally affected the Cabal project, see https://github.com/haskell/cabal/issues/3871 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 08:13:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 08:13:57 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.0e86788eb587a4e833b36948e00c5f30@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Weird. No problems with this also. I tried to increase `range` to `10000000` (10 millions), no problems either. And yes, I mean 64-bit GHCs only. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 08:40:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 08:40:30 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.4403e93bd02533f07f8c257792eb0d84@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -31,5 +31,12 @@ - time. An alternative would be to generate the `ModIface` from the tidied - program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run - over it to add arity and CAF-ref info. (You'd have to do this before - generating the fingerprints.) The advantage of this is that the - `ModIface` can be a lot smaller than the code for the entire module. + time. + + An alternative would be to generate the `ModIface` from the tidied program + ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to + add arity and CAF-ref info. (You'd have to do this before generating the + fingerprints.) The advantage of this is that the `ModIface` can be a lot + smaller than the code for the entire module. + + Another alternative would be to ensure that after `CoreTidy` we treat each + top-level binding one at a time, and pump them right down the pipeline + individually, all the way through code generation. That way we would + avoid creating the STG, or Cmm, for the entire program all at once. New description: At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. Another alternative would be to ensure that after `CoreTidy` we treat each top-level binding one at a time, and pump them right down the pipeline individually, all the way through code generation. That way we would avoid creating the STG, or Cmm, for the entire program all at once. A long-standing wart which needs some careful attention. Simon -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 08:43:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 08:43:09 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.dbc6dd7cd26119a76df125d1377dda8e@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's worth reading `Note [CafInfo and floating]` in `CorePrep`. Here's what I don't understand: 1. I think that local bindings (which may get floated) have by-default a `MayHaveCafRefs` flag. Worth checking. 2. I don't understand why a top-level binding {{{ sat1 = Nothing }}} (with a `MayHaveCafRefs` flag) gives rise to a `Nothing_closure` in the SRT of the binding mentioning `sat`, whereas {{{ sat2 = GHC.Tuple.() }}} (also with a `MayHaveCafRefs` flag) gives rise to a `sat2_closure` entry in he SRT. Why are the two treated differently? 3. In the binding {{{ main = return @ IO GHC.Base.$fMonadIO @ () GHC.Tuple.() }}} I don't understand why we ANF-ise the `GHC.Tuple.()` argument. It's already atomic; no need to create a binding for it. Does the same happen for `Nothing`? '''Simon''', do you have any ideas there? E.g. maybe data constructor closures are in static space and can't get marked by the CAF traversal or something? It'd be good to document it. 4. I don't understand why having those entries in the SRT would cause a crash. Finally, although it woudl be great to understand these things, the Real Solution is #9718, which I have been longing to get done for literally years. I really don't think it's hard; we just need to be a bit careful about memory usage. I'd rather fix #9718 than burn cycles doing very careful jiggery-pokery with `CorePrep` and floating. Fixing #9718 fixes the problem at source, rather than perpetuating it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 09:38:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 09:38:37 -0000 Subject: [GHC] #12724: Be lazier about reducing type-function applications Message-ID: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> #12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this: {{{ f :: F 20 -> F 20 f x = x }}} That ought to typecheck in a trice, right? But if `F` is a type function, GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F 20` unltimately reduces to `Int`, after a long time. Then we get {{{ f = \x . (x |> g1) |> g2 where g1 :: F 20 ~ Int g2 :: Int ~ F 20 }}} Here both `g1` and `g2` are big coercions. So we waste time reducing `F 20` ''and'' we generate giant coercions by doing so. Maybe the optimiser gets rid of them again; more probably not. But it's clearly stupid. This is one reason that the program in #5030 typechecks so slowly. We have {{{ cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU) cnst x = Left (Const x) }}} and there is absolutely no need to reduce either argument of the `Either` to normal form. Richard and I have ideas about how to fix this, but I'm recording it in a ticket. and -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 09:45:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 09:45:16 -0000 Subject: [GHC] #12724: Be lazier about reducing type-function applications In-Reply-To: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> References: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> Message-ID: <061.679a5101712c45c4e46a57c7d90495c4@haskell.org> #12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -30,1 +30,3 @@ - and + + Relevant performance tests are `T3064` and `T5030` in `compiler/perf`. + Doubtless many others too. New description: Consider this: {{{ f :: F 20 -> F 20 f x = x }}} That ought to typecheck in a trice, right? But if `F` is a type function, GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F 20` unltimately reduces to `Int`, after a long time. Then we get {{{ f = \x . (x |> g1) |> g2 where g1 :: F 20 ~ Int g2 :: Int ~ F 20 }}} Here both `g1` and `g2` are big coercions. So we waste time reducing `F 20` ''and'' we generate giant coercions by doing so. Maybe the optimiser gets rid of them again; more probably not. But it's clearly stupid. This is one reason that the program in #5030 typechecks so slowly. We have {{{ cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU) cnst x = Left (Const x) }}} and there is absolutely no need to reduce either argument of the `Either` to normal form. Richard and I have ideas about how to fix this, but I'm recording it in a ticket. Relevant performance tests are `T3064` and `T5030` in `compiler/perf`. Doubtless many others too. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 12:49:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 12:49:45 -0000 Subject: [GHC] #12725: T7037 is broken on Windows Message-ID: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> #12725: T7037 is broken on Windows --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- `T7037` appears to fail on Windows. Namely, `stdout` appears to be empty, whereas the expected output is `"ok"`. I had suspected that the issue was the `execv` call failing but this doesn't seem to be thew case; no code after `execv` is executed. A problem for another day... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 13:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 13:08:39 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.d6f0558e6148a7dbaba7dba5fbfd7e36@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 13:12:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 13:12:26 -0000 Subject: [GHC] #12720: Remove ghcii.sh (was: Remoce ghcii.sh) In-Reply-To: <044.2156db9af47b28addd1e457b901c3291@haskell.org> References: <044.2156db9af47b28addd1e457b901c3291@haskell.org> Message-ID: <059.a6e7b5ca263e0d8b33a6c58196f7df2e@haskell.org> #12720: Remove ghcii.sh ----------------------------+-------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+-------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 13:42:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 13:42:30 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.8fc7e3ba17864339b9509eb480d2fb65@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: This really isn't fixed per se; we just found a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 13:43:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 13:43:35 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.362f8fe913f7d07256136601cfc05795@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => upstream Comment: I've opened `msys2-packages` [[https://github.com/Alexpux/MSYS2-packages/issues/707|Issue #707]] to track this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 14:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 14:54:26 -0000 Subject: [GHC] #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi Message-ID: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi -------------------------------------+------------------------------------- Reporter: robjhen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: raspberry pi | Operating System: Linux Architecture: arm | Type of failure: GHC doesn't work | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == System and compiler version == System: Raspberry Pi 2 running Raspbian Jessie (September 2016 release); LLVM 3.7 installed. GHC: GHC 8.0.1 ARMv7 binary downloaded from GHC webpage (ghc-8.0.1-armv7-deb8-linux.tar.xz). GCC version 4.9.2 (Raspbian 4.9.2-10) == Details == GHCi works perfectly, however 'ghc --make' does not work at all. The following minimal test program fails to compile: {{{#!hs main :: IO () main = putStrLn "Hello!" }}} Here are the first few lines of the compiler output: {{{ pi at raspberrypi:~/haskell/test $ ~/opt/ghc-8.0.1/bin/ghc --make test.hs [1 of 1] Compiling Main ( test.hs, test.o ) /tmp/ghc2094_0/ghc_6.s: Assembler messages: /tmp/ghc2094_0/ghc_6.s:40:0: error: Error: selected processor does not support ARM mode `movw r7,:lower16:stg_bh_upd_frame_info' }}} See attachment for full compiler output with '-v'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 14:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 14:56:14 -0000 Subject: [GHC] #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi In-Reply-To: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> References: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> Message-ID: <061.56d8c79ccfb62362fa195f5cb1949778@haskell.org> #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi -------------------------------------+------------------------------------- Reporter: robjhen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: raspberry pi Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work | Test Case: at all | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by robjhen): * Attachment "output.txt" added. Full verbose compiler output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 14:56:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 14:56:48 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.05ac378097d57ab78a543b76032aa1cb@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): I forgot to mention that stdout is only empty when the test is run via the testsuite driver (e.g. `make test TEST=T7037`). Running `make T3037`directly produces `"ok"` as expected. Presumably there is something funny going on with the testsuite driver's redirection of stdout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 15:12:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 15:12:29 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.e55785fb02c65dc02312ede1dd2d4fcc@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): It looks like Phab:D1234 is relevant here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 15:23:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 15:23:02 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.7908402c086d57ffbe5fd75b85e145b0@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Unfortunately my naive attempt at a minimal reproduction case failed, {{{#!bash $ cat >test.py <test.c < int main() { printf("hi\n"); return 0; } EOF $ gcc -o test.exe test.c $ python test.py }}} Never seems to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 15:28:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 15:28:31 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.6bc733beba734b66a483f6c3905dcdff@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Adapting the above to call the `T7037_main.exe` executable produced by the testsuite also fails to replicate the failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 16:05:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 16:05:35 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy Message-ID: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Oddly this only happens on our build server, not on my local machine. On compilation, I get: {{{ [187 of 273] Compiling Query.Order ( Query/Order.hs, dist/build/Query/Order.o ) Query/Order.hs:340:1: warning: [-Wredundant-constraints] • Redundant constraint: MonadBaseControl IO m • In the type signature for: updateOrdersSuccess :: (MonadBaseControl IO m, MonadTransaction m) => m () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): piResultTy Maybe Int64 a1_a4WiL Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The configuration parameters are: {{{ configureFlags: --verbose --prefix=/nix/store /qxfjd5jxr593dn43i3659s86d0rdllyv-circuithub-api-0.0.4 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc --package-db=/tmp/nix-build-circuithub-api-0.0.4.drv-0/package.conf.d --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --disable-shared --enable-library-vanilla --disable- executable-dynamic --disable-tests }}} I've attached Query/Order.hs, but you won't be able to compile it stand- alone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 16:06:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 16:06:00 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.ed34c15c696e738966567fcaed12f811@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 ocharles): * Attachment "Order.hs" added. Query.Order -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 16:11:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 16:11:41 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.7ed4f895ec68eb444d433fb301c770e3@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): This is a definite bug. It'll be hard to do much about this without the ability to reproduce the bug. Could you compile everything with `-dore-lint`? Maybe it's already fixed. cf #12676 Any chance you can try with HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.dcb701f1c6259432ed34978364178005@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9cb4459893c1c56553b413786cea3171b4e665ca/ghc" 9cb44598/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cb4459893c1c56553b413786cea3171b4e665ca" testsuite: Work around #12554 It seems that Python 2.7.11 and "recent" msys2 releases are broken, holding open file locks unexpected. This causes rmtree to intermittently fail. Even worse, it would fail silently (since we pass ignore_errors=True), causing makedirs to fail later. We now explicitly check for the existence of the test directory before attempting to delete it and disable ignore_errors. Moreover, on Windows we now try multiple times to rmtree the testdir, working around the apparently msys bug. This is all just terrible, but Phyx and I spent several hours trying to track down the issue to no available. The workaround is better than nothing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12712: break011 is broken on Windows In-Reply-To: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> References: <046.625cebc98263ea38795f8428b7bfe04f@haskell.org> Message-ID: <061.9188e852252bd7e5eac920ded465f15d@haskell.org> #12712: break011 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: break011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"deed4189b5c84a5dfbe3dca3be7968d66f2a67f4/ghc" deed4189/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="deed4189b5c84a5dfbe3dca3be7968d66f2a67f4" testsuite: Mark break011 as broken See #12712. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.56f2fe905a32e8d4d113698dea9f0a70@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"17d696f1a8dcc28074886a2830036144eced6d87/ghc" 17d696f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17d696f1a8dcc28074886a2830036144eced6d87" validate: Allow user to override Python interpreter Due to #12554 and #12661 we must be quite picky about our choice of Python interpreter on Windows. Allow the user to override it. Test Plan: `PYTHON=/usr/bin/python2 ./validate` on Windows Reviewers: austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2603 GHC Trac Issues: #12554, #12661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.b1d76984a94f592277b380fb2e4ad4a3@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"17d696f1a8dcc28074886a2830036144eced6d87/ghc" 17d696f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17d696f1a8dcc28074886a2830036144eced6d87" validate: Allow user to override Python interpreter Due to #12554 and #12661 we must be quite picky about our choice of Python interpreter on Windows. Allow the user to override it. Test Plan: `PYTHON=/usr/bin/python2 ./validate` on Windows Reviewers: austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2603 GHC Trac Issues: #12554, #12661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.9958f309bc101f27737c3d3e0b4839ea@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2864ad79ab44f5ca039c30dc3dec816c77dd5cfa/ghc" 2864ad7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2864ad79ab44f5ca039c30dc3dec816c77dd5cfa" testsuite/driver: Allow threading on Windows It seems that threading now works fine. The only caveat here is that it makes some race conditions more likely (e.g. #12554), although these also appear to affect single-threaded runs. Test Plan: Validate on Windows Reviewers: austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2600 GHC Trac Issues: #10510 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.ecb7f643cac0a1311f846b86c198c103@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: python Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7d2df32091dfe94f4da34868a64bea56ca74843e/ghc" 7d2df320/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7d2df32091dfe94f4da34868a64bea56ca74843e" testsuite/driver: More Unicode awareness Explicitly specify utf8 encoding in a few spots which were failing on Windows with Python 3. Test Plan: Validate Reviewers: austin, thomie Differential Revision: https://phabricator.haskell.org/D2602 GHC Trac Issues: #9184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.505a0c42fc0b7d7447231316ddaf46f2@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"c5c6d80d2129b259809606387d0ca9dbb16dcfc5/ghc" c5c6d80/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5c6d80d2129b259809606387d0ca9dbb16dcfc5" testsuite: Mark T7037 as broken on Windows Due to #12725. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #10510: Testsuite driver does not run tests in parallel on Windows In-Reply-To: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> References: <045.f7051a2be634cd79e52b8850db4fc44f@haskell.org> Message-ID: <060.2de458419dfd54ac209b57f3c2773837@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows ---------------------------------+---------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"2864ad79ab44f5ca039c30dc3dec816c77dd5cfa/ghc" 2864ad7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2864ad79ab44f5ca039c30dc3dec816c77dd5cfa" testsuite/driver: Allow threading on Windows It seems that threading now works fine. The only caveat here is that it makes some race conditions more likely (e.g. #12554), although these also appear to affect single-threaded runs. Test Plan: Validate on Windows Reviewers: austin, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2600 GHC Trac Issues: #10510 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 19:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 19:02:18 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.86aaf0930a7fef60b7ebc5283cdafbc2@haskell.org> #12714: T9405 fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"332543587eea41825ad7ad5addcb0de6b3bfa2f1/ghc" 3325435/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="332543587eea41825ad7ad5addcb0de6b3bfa2f1" testsuite: Mark T9405 as broken on Windows There seems to be a runtime system bug here, as described in #12714. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 20:07:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 20:07:23 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.25f7012f8c539fa04879b442a8d1f526@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 20:53:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 20:53:22 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI In-Reply-To: <045.8e0096947045c15d555e41eb71d679da@haskell.org> References: <045.8e0096947045c15d555e41eb71d679da@haskell.org> Message-ID: <060.e5549730f2e2b0e6ba76f951adbff168@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -11,1 +11,1 @@ - module B where + module B (module A) where New description: This leads to the following delightful, five module bug: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a type instance F Int = Bool -- B.hs module B (module A) where import A -- C.hs module C where import B -- D.hs module D where import C -- E.hs module E where import D import B }}} Build these modules. Then rename A to A2 (fixing B's import), and build them again. You'll get: {{{ ezyang at sabre:~/Dev/labs/T3871$ ghc --make E.hs [1 of 5] Compiling A2 ( A2.hs, A2.o ) [2 of 5] Compiling B ( B.hs, B.o ) [3 of 5] Compiling C ( C.hs, C.o ) [B changed] [5 of 5] Compiling E ( E.hs, E.o ) [B changed] attempting to use module ‘A’ (./A.hs) which is not loaded }}} The problem is clear: D was not recompiled, but it needs to be, because when the module gets renamed, we need to update its list of family instance modules to rename A to A2. When we don't do this, the subsequent family instance check chokes because it tries to load A. And why did D decide not to get recompiled? Because the ABI hash of C did not change. And that's WRONG. (Also, family instances are really awful, you really do have to rebuild everything when you change them. UGH.) This occasionally affected the Cabal project, see https://github.com/haskell/cabal/issues/3871 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:01:39 -0000 Subject: [GHC] #12724: Be lazier about reducing type-function applications In-Reply-To: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> References: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> Message-ID: <061.ddb31d0b040b2a765409bec7e2ed86de@haskell.org> #12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 goldfire): Here is the basic idea we had: keep `CFunEqCan`s in a lower-priority wing of the work-list, and then solve them only when necessary. When we see a type function application like `F 20` in a type, we ''flatten'' it to produce a flatten-unification-variable, fuv, and a constraint `[W] F 20 ~ fuv`. It is this constraint that would be de- prioritized. If the program can be type-checked without ever solving the `CFunEqCan`, then we do not need to reduce the type function. When a `CFunEqCan` comes up as the work item, we try to solve it only if it is ''active''. An ''active'' `CFunEqCan` involves an fuv that: 1. Is an argument to the class in an inert class constraint, OR 2. Is an argument to the type family in an active `CFunEqCan`, OR 3. Is at the top level of an inert equality If a `CFunEqCan` is not active (that is, if it's ''passive''), then just throw it right into the inert set without trying to solve. The inert set will have a new place to store passive `CFunEqCan`s; if it were to become active (by one of the conditions above becoming satisfied), then it must get kicked out. We think that an efficient way of implementing this scheme is by reference counting, essentially, where each fuv is mapped (in some data structure in the `TcSEnv`) to a count of places where it is active. When the count drops to zero, the associated `CFunEqCan` becomes passive. We would then have to increment and decrement counters when adding to and kicking out from the inert set. Note that we have to be careful to making the refcount wibbles as efficient as possible, because they will happen a lot. For example, we can't just get the free variables of a constraint and then look for fuvs, as that would allocate space to store the fv set. Instead, we must write a new function that extracts only fuvs. It remains to be seen if this will be a real performance improvement, as there will be a cost everyone has to pay to speed up the type family case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:10:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:10:10 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI In-Reply-To: <045.8e0096947045c15d555e41eb71d679da@haskell.org> References: <045.8e0096947045c15d555e41eb71d679da@haskell.org> Message-ID: <060.5c21f17410d3ca6dc448fd3d80a15ac1@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2607 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:10:37 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.367d7b4ddff47af5bcfba52e45fcaf8b@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hjarvi): upvote -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:11:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:11:51 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.5094bc805fd9a63f6a9fc0ec7172e389@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hjarvi): * cc: hjarvi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:17:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:17:45 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.c827b379b00dadd18ee6a78a54e60b2c@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by thomie): The version or type (msys2/mingw) of `gcc` seems to have something to do with it. I can reproduce the problem with the following version of `gcc`: {{{ "C:\msys64\opt\ghc\8.0.0.20160421\lib/../mingw/bin/gcc.exe" -v Using built-in specs. COLLECT_GCC=C:\msys64\opt\ghc\8.0.0.20160421\mingw\bin/realgcc.exe COLLECT_LTO_WRAPPER=C:/msys64/opt/ghc/8.0.0.20160421/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0 /lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-5.2.0/configure --prefix=/mingw64 --with-local- prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header- dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --with- gxx-include-dir=/mingw64/include/c++/5.2.0 --enable-bootstrap --with- arch=x86-64 --with-tune=generic --enable- languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable- static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable- libstdcxx-pch --disable-libstdcxx-debug --enable-version-specific-runtime- libs --disable-isl-version-check --enable-lto --enable-libgomp --disable- multilib --enable-checking=release --disable-rpath --disable- win32-registry --disable-nls --disable-werror --disable-symvers --with- libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev3, Built by MSYS2 project' --with-bugurl=http://sourceforge.net/projects/msys2 --with- gnu-as --with-gnu-ld Thread model: posix gcc version 5.2.0 (Rev3, Built by MSYS2 project) }}} ok.c: {{{ #include int main() { printf("ok\n"); return 0; } }}} main.c: {{{ #include int main(int argc, char *argv[]) { char * args[2] = {"ok", NULL}; execv("./ok", args); } }}} test.py: {{{ import subprocess import time stdout='test.out' def test(f): with open(stdout, 'w') as fout: subprocess.call([f], stdout=fout) with open(stdout, 'r') as fin: print('1:', fin.read().strip()) time.sleep(0.1) with open(stdout, 'r') as fin: print('2:', fin.read().strip()) test('./main') }}} run: {{{ $ "C:\msys64\opt\ghc\8.0.0.20160421\lib/../mingw/bin/gcc.exe" -o main main.c $ "C:\msys64\opt\ghc\8.0.0.20160421\lib/../mingw/bin/gcc.exe" -o ok ok.c $ python test.py ('1:', '') # expected: ok ('2:', 'ok') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:17:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:17:54 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.a5704237f8334b865d6428aa81346321@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hjarvi): * cc: hjarvi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:41:54 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.090eadc181837f4e62b05b9cdf10fade@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:26 hjarvi]: > upvote Do you have an example of an application which is particularly badly affected by this issue? It would be quite helpful if you could provide a testcase if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:48:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:48:34 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows Message-ID: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows --------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I have seen the `setnumcapabilities001` test fail at least once on Windows ([[https://phabricator.haskell.org/harbormaster/build/14178/?l=0]]). It seems that the assertion `ASSERT(n_idle == 0);` in `Schedule.scheduleDoGC` is to blame in this particular case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 21:54:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 21:54:49 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.72a35e846c4b3c532e81a8c0b8357ee5@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by bgamari: @@ -4,1 +4,5 @@ - is to blame in this particular case. + is to blame in this particular case, + {{{ + setnumcapabilities001.exe: internal error: ASSERTION FAILED: file + rts\Schedule.c, line 1636 + }}} New description: I have seen the `setnumcapabilities001` test fail at least once on Windows ([[https://phabricator.haskell.org/harbormaster/build/14178/?l=0]]). It seems that the assertion `ASSERT(n_idle == 0);` in `Schedule.scheduleDoGC` is to blame in this particular case, {{{ setnumcapabilities001.exe: internal error: ASSERTION FAILED: file rts\Schedule.c, line 1636 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 22:04:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 22:04:52 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.035bcaa624e7fadf64e1f98dd0d6da6e@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I'm not sure why the extra syntax is needed, i.e. how is `let b ~ Foo a` different from `b ~ Foo a`? I'm intending, as hsyl20 indicated, to do the former, but apparently using the `b ~ Foo a` implies, and is more general than, `let b ~ Foo a`. Is there no way for GHC to turn the signature `forall a b . (b ~ Foo a) => a -> b` into `forall a . (let b ~ Foo a) => a -> b` or even `forall a . a -> Foo a`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 22:27:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 22:27:18 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.c53a31a5defd45fa39b78c319984cf1a@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I tried reproducing this with cf5eec3eaa638719fd9768c20271f8aa2b2eac1f on a 2-socket, 24-core machine I have access to. I was unable to see anything like the system time numbers like reported in comment:17, {{{#!bash $ cat >T8224.hs <T8224a.hs < forkIO $ return () threadDelay (4 * 1000 * 1000) EOF $ inplace/bin/ghc-stage2 -threaded -rtsopts T8224a.hs $ time ./T8224a +RTS -N32 real 0m4.018s user 0m0.160s sys 0m0.028s }}} All-in-all this doesn't seem terribly unreasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 22:56:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 22:56:16 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.f1782a4ead8b6d89f35271d0cbe1dc0b@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): * type: bug => task Comment: Hmm, somehow I missed this earlier. I agree that ticket form is a bit daunting. Unfortunately Trac doesn't really provide us with many good options for fixing this short of removing fields. I, for one, have used most of the fields at one point or another and would be reluctant to remove any of them. That being being said, recently mpickering has been evaluating the feasibility of moving GHC's ticket tracking to Phabricator, which, at least on this front, would be a significant improvement over Trac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 23:02:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 23:02:15 -0000 Subject: [GHC] #12044: Remove sortWith in favor of sortOn In-Reply-To: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> References: <043.a68fedd475aea8c3d9f6732a967a3997@haskell.org> Message-ID: <058.b3f88d648011fe79986e0c5e137426dd@haskell.org> #12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: cblp Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #2659 | Differential Rev(s): Phab:D2587 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Somebody should investigate and document when one should use `sortOn` or `sortWith`. In general if the mapping function is expensive to compute then you should probably be using `sortOn`, as it only needs to compute it once for each element. `sortWith`, on the other hand must compute the mapping function for every comparison that it performs. Beyond that general intuition it's hard to give any specific prescription. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 23:05:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 23:05:56 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax Message-ID: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC disallows to define a newtype of an unlifted type (`newtype A = A Int#`). However, this restriction is not enforced when the newtype is defined using GADT syntax: {{{ newtype A where A :: Int# -> A }}} For example, I can derive Show for A and on my machine `main = print (A 0#)` segfaults. Tested on GHC 8.0.1 and master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 17 23:26:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 17 Oct 2016 23:26:45 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.7db7e2ed6243a90566495c7b27d6c4d6@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Changes (by akio): * differential: D2554 => Phab:D2554, Phab:D2605 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 00:38:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 00:38:21 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.f4d22b71f74e3d29761dead8ad6310d2@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I've rebased nomeata's branch: https://github.com/takano- akio/ghc/compare/afdde48...f8eb150 Some nofib results: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- mandel +1.9% -25.0% 0.047 0.047 0.0% gcd +2.0% -21.6% 0.030 0.031 0.0% k-nucleotide +1.7% -18.0% +3.4% +2.7% 0.0% wave4main +2.0% +12.3% 0.179 0.179 0.0% kahan +2.0% +7.8% +1.4% +1.3% 0.0% solid +2.0% -6.4% 0.081 0.081 0.0% sphere +2.0% +5.8% 0.040 0.040 0.0% hpg +2.0% +4.1% 0.102 0.102 0.0% symalg +1.9% +3.6% 0.007 0.007 0.0% gamteb +2.4% -4.8% 0.026 0.026 0.0% -------------------------------------------------------------------------------- Min +1.5% -25.0% -0.6% -0.4% -20.0% Max +2.8% +12.3% +12.7% +12.8% +12.0% Geometric Mean +2.0% -0.5% +5.0% +4.7% +0.2% }}} I'll look into the allocation regressions next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 02:03:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 02:03:39 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.580ba7f4942b991756f1a047ded30c58@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:51 awson]: > Weird. No problems with this also. I tried to increase `range` to `10000000` (10 millions), no problems either. When it works, the program will output the number of primes up to trillions if you give it enough time, but this simple version works best for ranges up to about 16 billion ;) > And yes, I mean 64-bit GHCs only. Well, it's not too much of a problem if it is fixed in HEAD as 8.2.1 will take care of it, but we need to verify that 8.0.1 standard has the problem on your Windows machine and I need to verify that HEAD fixes the problem on mine. Any suggestions on how to get a development release for Windows 64-bit that you show as working without going through hoops to compile it on my machine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 02:49:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 02:49:50 -0000 Subject: [GHC] #12730: Pattern synonym signature fails with unlifted type Message-ID: <051.2c91bfc5f6856413eaae1aa6a5bc0ff4@haskell.org> #12730: Pattern synonym signature fails with unlifted type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs pattern P2# a b = (# a, b #) }}} works but adding a type signture makes it fail {{{#!hs -- tp0w.hs:130:25-34: error: … -- • Expecting a lifted type, but ‘(# a, b #)’ is unlifted -- • In the type ‘(# a, b #)’ -- Compilation failed. pattern P2# :: a -> b -> (# a, b #) pattern P2# a b = (# a, b #) }}} Same with these {{{#!hs pattern True :: Int# pattern True = 1# pattern False :: Int# pattern False = 0# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 03:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 03:19:01 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.a666a4693f151b358c635ed1453fc258@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Oh, that’s an old branch. I’m happy that a second pair of eyes looks at it. How tedious was it to rebase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 03:53:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 03:53:37 -0000 Subject: [GHC] #12731: Generic type class has type family; leads to big dep_finsts Message-ID: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> #12731: Generic type class has type family; leads to big dep_finsts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to determine a good explanation for simonpj's question in Phab:D2607, I noticed that `dep_finsts` was a lot larger than I would have ordinarily expected it to be: it included many modules that did not have the `TypeFamilies` extension enabled for them. For example, for one module in Cabal, here's "family instance modules": {{{ family instance modules: Distribution.Compat.Semigroup Distribution.Compiler Distribution.ModuleName Distribution.Package Distribution.Simple.Compiler Distribution.System Distribution.Utils.ShortText Distribution.Verbosity Distribution.Version Language.Haskell.Extension Control.Applicative Data.Complex Data.Either Data.Functor.Const Data.Functor.Identity Data.List.NonEmpty Data.Monoid Data.Semigroup Data.Type.Equality Data.Version Data.Void GHC.Exts GHC.Generics GHC.IO.Exception GHC.TypeLits Data.IntMap.Base Data.IntSet.Base Data.Map.Base Data.Sequence Data.Set.Base Text.PrettyPrint.Annotated.HughesPJ Text.PrettyPrint.HughesPJ }}} Do we *really* have this many type family instances in base and Cabal? I was flummoxed, until I realized that the Generic type class defines a type family! {{{ -- | Representable types of kind *. -- This class is derivable in GHC with the DeriveGeneric flag on. class Generic a where -- | Generic representation type type Rep a :: * -> * -- | Convert from the datatype to its representation from :: a -> (Rep a) x -- | Convert from the representation to the datatype to :: (Rep a) x -> a }}} The upshot is that if you derive Generic, you have agreed to a perpetual interface file size tax on every module which transitively depends on your module, as well as lots of fruitless pairwise consistency checking. Ick, especially considering that it's fairly common practice to slap a Generic on every data type you define. This is a case where we would gain a lot if we could put a local restriction on Generic instances so that individual instances are guaranteed not to overlap, e.g., like one of the rules that Rust uses (http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan- impls/) Then we'd avoid balling up a big transitive closure of all modules that wrote `deriving Generic`. Since non-overlapness is guaranteed by construction, we'd no longer need an eager check. Related #5224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 05:47:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 05:47:42 -0000 Subject: [GHC] #12732: GHC bug Message-ID: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A frog told me about this {{{#!hs (a ... b) xs | a == x , (l, _:r) <- break (== x) xs = l ++ [x] }}} {{{ baldur at Loki:~$ ghci -fobject-code -fdefer-typed-holes -ignore-dot-ghci /tmp/tnVL.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tnVL.hs, /tmp/tnVL.o ) /tmp/tnVL.hs:2:10: warning: [-Wtyped-holes] Variable not in scope: x /tmp/tnVL.hs:3:27: warning: [-Wtyped-holes] Variable not in scope: x /tmp/tnVL.hs:4:11: warning: [-Wtyped-holes] Variable not in scope: x ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dEq_a26w local binds for: $trModule $trModule1_r29y $trModule2_r2a9 x_r2aa x1_r2ab x2_r2ac a2_s2ah b_s2ai xs_s2aj fail_s2ak Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} I managed to find a more minimal example {{{#!hs u a | a == x = undefined }}} doesn't trigger error in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 05:50:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 05:50:50 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax In-Reply-To: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> References: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> Message-ID: <062.1f73ec1a24255aa6737c83ea0afd7310@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): See UnliftedDataTypes ([https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Proposal3:Allownewtypesoverunliftedtypes Proposal 3: Allow newtypes over unlifted types]) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 06:07:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 06:07:32 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly Message-ID: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Phab:D2607, simonpj asked why we didn't also put class instances in the export hash. Why indeed. In the course of investigating, I discovered another bug in how we handle orphan recompilation. Unfortunately, this bug needs two packages to manifest. {{{ -- p/P.hs module P where instance Show (a -> b) where --instance Show (IO a) where -- q/Q.hs module Q where import P -- q/Q2.hs module Q2 where import Q }}} Put in some default Cabal files, with q depending on p, and then build the entire kaboodle. Then edit `p/P.hs` to uncomment the second orphan instance. Rebuild. {{{ ezyang at sabre:~/Dev/labs/orph$ cabal new-build q -w ghc-head In order, the following will be built (use -v for more details): - p-0.1.0.0 (lib) (file P.hs changed) - q-0.1.0.0 (lib) (dependency rebuilt) Preprocessing library p-0.1.0.0... [1 of 1] Compiling P ( P.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/p-0.1.0.0/build/P.o ) P.hs:2:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (a -> b)’ P.hs:3:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (IO a)’ module Q2 where Preprocessing library q-0.1.0.0... [1 of 2] Compiling Q ( Q.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/q-0.1.0.0/build/Q.o ) [P changed] ezyang at sabre:~/Dev/labs/orph$ }}} Notice: Q2 never got rebuilt. This is wrong wrong wrong: P changed, and we need to rebuild Q2! Here are the hashes for Q.hi before and after: {{{ -- Before interface Q 80120161016 interface hash: 2ffc06a1552565a73c888110ab4cf8df ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 -- After interface Q 80120161016 interface hash: 009db9e5ecbe49e36b7bf38e02087e75 ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 }}} The orphan hash didn't get updated. At the moment, when we compute the orphan hash, we only consider the orphan hashes from the home package. Here's the comment justifying it: {{{ -- the export hash of a module depends on the orphan hashes of the -- orphan modules below us in the dependency tree. This is the way -- that changes in orphans get propagated all the way up the -- dependency tree. We only care about orphan modules in the current -- package, because changes to orphans outside this package will be -- tracked by the usage on the ABI hash of package modules that we import. }}} It is true that we know to rebuild Q.hs when P.hs changes. But that is not much solace for Q2.hs... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 06:22:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 06:22:56 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.35e114dfaaec20c3c37bf543b3f1dba9@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 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: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -75,1 +75,1 @@ - The orphan hash didn't get updated. + The ABI hash didn't get updated. @@ -77,1 +77,1 @@ - At the moment, when we compute the orphan hash, we only consider the + At the moment, when we compute the export hash, we only consider the New description: In Phab:D2607, simonpj asked why we didn't also put class instances in the export hash. Why indeed. In the course of investigating, I discovered another bug in how we handle orphan recompilation. Unfortunately, this bug needs two packages to manifest. {{{ -- p/P.hs module P where instance Show (a -> b) where --instance Show (IO a) where -- q/Q.hs module Q where import P -- q/Q2.hs module Q2 where import Q }}} Put in some default Cabal files, with q depending on p, and then build the entire kaboodle. Then edit `p/P.hs` to uncomment the second orphan instance. Rebuild. {{{ ezyang at sabre:~/Dev/labs/orph$ cabal new-build q -w ghc-head In order, the following will be built (use -v for more details): - p-0.1.0.0 (lib) (file P.hs changed) - q-0.1.0.0 (lib) (dependency rebuilt) Preprocessing library p-0.1.0.0... [1 of 1] Compiling P ( P.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/p-0.1.0.0/build/P.o ) P.hs:2:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (a -> b)’ P.hs:3:10: warning: [-Wmissing-methods] • No explicit implementation for either ‘showsPrec’ or ‘show’ • In the instance declaration for ‘Show (IO a)’ module Q2 where Preprocessing library q-0.1.0.0... [1 of 2] Compiling Q ( Q.hs, /srv/code/labs/orph/dist- newstyle/build/x86_64-linux/ghc-8.1.20161016/q-0.1.0.0/build/Q.o ) [P changed] ezyang at sabre:~/Dev/labs/orph$ }}} Notice: Q2 never got rebuilt. This is wrong wrong wrong: P changed, and we need to rebuild Q2! Here are the hashes for Q.hi before and after: {{{ -- Before interface Q 80120161016 interface hash: 2ffc06a1552565a73c888110ab4cf8df ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 -- After interface Q 80120161016 interface hash: 009db9e5ecbe49e36b7bf38e02087e75 ABI hash: b2768862866252ea5a63401d2aa05aaa export-list hash: 092acc280445a8bcc96904afb8b766b0 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: f01bb78d3c47152bc5253f256b2a60d3 }}} The ABI hash didn't get updated. At the moment, when we compute the export hash, we only consider the orphan hashes from the home package. Here's the comment justifying it: {{{ -- the export hash of a module depends on the orphan hashes of the -- orphan modules below us in the dependency tree. This is the way -- that changes in orphans get propagated all the way up the -- dependency tree. We only care about orphan modules in the current -- package, because changes to orphans outside this package will be -- tracked by the usage on the ABI hash of package modules that we import. }}} It is true that we know to rebuild Q.hs when P.hs changes. But that is not much solace for Q2.hs... -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 06:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 06:28:55 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.00998f9a02016bf8cf3bb904fee9cf6a@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.1 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 ezyang): Suggested fix: compute the export hash by hashing together the orphan hashes of ALL transitively reachable orphan modules, not just the ones from the home package. But perhaps this will have some negative performance implication? (Perhaps not too bad; we only pay for orphans, and there are not too many of them. We pay a lot more for family instances.) Another possibility would be to maintain a "transitive orphan hash" which is the orphan hash and the orphan hashes of all transitively imported orphan modules in a module. Then, for imports for external packages, we only put the orphan hash of direct imports into our export hash. Then we wouldn't have to probe all transitively imported orphans; just direct imports--the downside is that if any of these transitive orphan hashes change, our export hash would change, even if the final effective orphans in scope stayed the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 06:41:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 06:41:56 -0000 Subject: [GHC] #11214: Remove JavaScriptFFI from --supported-extensions list In-Reply-To: <044.186ef3fe83fb53d5e2a992d9a7def87d@haskell.org> References: <044.186ef3fe83fb53d5e2a992d9a7def87d@haskell.org> Message-ID: <059.553477793ef26f7de8f63be203bb0480@haskell.org> #11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1609 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): see also https://github.com/haskell/cabal/pull/3997 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 07:07:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 07:07:32 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.a71b844312ca5e5106363e6624dadd50@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2610 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2610 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 07:14:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 07:14:29 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.af19a8b8a8ace94f81eaf598fc486199@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by awson): Well, I've downloaded 8.0.1 release, tried it and all your examples immediately started to segfault, but after I replaced distributed binutils with the correct one all started to work flawlessly, no segfaults altogether for all your examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 07:15:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 07:15:43 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.f0985e90d20b97f2fdd27e47ab69e670@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:53 nomeata]: > How tedious was it to rebase? It took me a few days, but in the process I learned a lot about nested CPR and about the demand analyzer in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 08:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 08:47:08 -0000 Subject: [GHC] #12723: Family instance modules are not fingerprinted in ABI In-Reply-To: <045.8e0096947045c15d555e41eb71d679da@haskell.org> References: <045.8e0096947045c15d555e41eb71d679da@haskell.org> Message-ID: <060.ff1ea2f47858bd1fd3bbdaba2f5f49d4@haskell.org> #12723: Family instance modules are not fingerprinted in ABI -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2607 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"8fa2cdb16c4db8141b889f2364d8e5fccc62cde3/ghc" 8fa2cdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fa2cdb16c4db8141b889f2364d8e5fccc62cde3" Track dep_finsts in exports hash, as it affects downstream deps. Summary: I also added some more comments about the orphan and family instance hashing business. Fixes #12723. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2607 GHC Trac Issues: #12723 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 09:15:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 09:15:44 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.81cbb2144c7745d4d68c19e39d51f1b4@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by simonmar): * db1: p (depends on q) * db2: q (depends on r from db3) * db3: r * db4: r (shadows r from db3) I presume you mean that db3:r and db4:r have different ABIs, and q was built against db3:r. We are given these in the order db1, db3, db4, db2. Now, since q's dependency doesn't say which r it requires, we have to pick one, and the only sensible strategy is to pick the rightmost (db4:r). This is the wrong r, so we can get segfaults. Given that we can get segfaults even trying to do clever shadowing, I'm going to suggest that we don't do clever shadowing at all. * Just merge databases from left to right. When there are multiple packages with the same key, we get the rightmost one. We would accept the small possibility that if someone has somehow managed to create two packages with the same key but different ABIs (which is difficult with determinism) then GHC can produce a segfaulting binary. Too bad. It's unlikely, and as a user you can fix it by deleting or rebuilding packages. Furthermore it was always possible to screw up like this because the ABI hash is not a complete specification of a package - there are semantic differences not captured by the ABI hash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 11:04:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 11:04:44 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow Message-ID: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! I don't have a minimal example, but I've got a very clear strange bahavior: We've got a function: {{{ nstar3 :: ( ExprCons t layers m, Bindable t m, Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , ExprInferable t layers m) => m (Binding (PrimExpr2' t layers Star)) nstar3 = Self.put . anyLayout2 =<<& (nstar2 >>= mkBinding) }}} If I use it in a different function and use following explicit type, I get the error: {{{ test_gr3 :: ( ExprCons t layers m, Bindable t m, ExprInferable t layers m , MonadIO m, Show bind, Show (PrimExpr2' t layers Star), layers~'[Data, Type] , Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , bind ~ Binding (PrimExpr2' t layers Star) ) => m bind test_gr3 = do sref <- nstar3 }}} error (while using the function and evaluating monads): {{{ • Reduction stack overflow; size = 201 When simplifying the following type: MonadFix (Self.SelfBuilderT (Binding (Expr2 t0 '[Data, Type] AnyLayout)) m) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the second argument of ‘($)’, namely ‘(test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @TermType @Net $ (test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @InfLayers @'[Data, Type] $ runInferenceT2 @TermType @Net $ (test_gr3)’ }}} What is "funny" is that if I change the type of `test_gr3` to a very similar one, I just replace the part `=> m bind` with manually expanded one `m (Binding (PrimExpr2' t layers Star))` everything compiles fine. It would be really hard to get minimal example out of it – it uses nested mfixes and will take much time to cut it down. The question is – can we locate the error based on the description? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 11:09:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 11:09:29 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.0084e7c7a46877a81167ef5269333165@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Thanks. I think that's been fixed now. With HEAD I get {{{ bash$ c:/code/HEAD/inplace/bin/ghc-stage1 -c T12732.hs T12732.hs:4:11: error: Variable not in scope: x T12732.hs:5:28: error: Variable not in scope: x T12732.hs:6:12: error: Variable not in scope: x }}} I'm not in a position to try with the 8.0 branch today; could someone try? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 11:21:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 11:21:45 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.adc005e76b1e1e20cb7b743e860c9076@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I know how hard it can be to boil out a repro case, but it's difficult to debug this kind of thing without it. One that might give some insight is to try `-ddump-cs-trace` which gives you soe idea of what the constraint solver is doing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 11:37:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 11:37:01 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.beb5178c0d075b591add78ba64d6392c@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- @@ -26,2 +26,2 @@ - test_gr3 = do - sref <- nstar3 + test_gr3 = nstar3 + New description: Hello! I don't have a minimal example, but I've got a very clear strange bahavior: We've got a function: {{{ nstar3 :: ( ExprCons t layers m, Bindable t m, Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , ExprInferable t layers m) => m (Binding (PrimExpr2' t layers Star)) nstar3 = Self.put . anyLayout2 =<<& (nstar2 >>= mkBinding) }}} If I use it in a different function and use following explicit type, I get the error: {{{ test_gr3 :: ( ExprCons t layers m, Bindable t m, ExprInferable t layers m , MonadIO m, Show bind, Show (PrimExpr2' t layers Star), layers~'[Data, Type] , Self.MonadSelfBuilder (Binding (Expr2 t layers AnyLayout)) m , bind ~ Binding (PrimExpr2' t layers Star) ) => m bind test_gr3 = nstar3 }}} error (while using the function and evaluating monads): {{{ • Reduction stack overflow; size = 201 When simplifying the following type: MonadFix (Self.SelfBuilderT (Binding (Expr2 t0 '[Data, Type] AnyLayout)) m) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the second argument of ‘($)’, namely ‘(test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @TermType @Net $ (test_gr3)’ In the second argument of ‘($)’, namely ‘runInferenceT2 @InfLayers @'[Data, Type] $ runInferenceT2 @TermType @Net $ (test_gr3)’ }}} What is "funny" is that if I change the type of `test_gr3` to a very similar one, I just replace the part `=> m bind` with manually expanded one `m (Binding (PrimExpr2' t layers Star))` everything compiles fine. It would be really hard to get minimal example out of it – it uses nested mfixes and will take much time to cut it down. The question is – can we locate the error based on the description? -- Comment (by danilo2): I know @Simon, and I'll try to help as much as possible. When passing `-ddump-cs-trace` to stack as `--ghc-options` I don't get any additional compilation output - both in terminal as well in the stack compilation log file. Does anybody know if stack blocks it somehow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 11:42:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 11:42:28 -0000 Subject: [GHC] #12730: Pattern synonym signature fails with unlifted type In-Reply-To: <051.2c91bfc5f6856413eaae1aa6a5bc0ff4@haskell.org> References: <051.2c91bfc5f6856413eaae1aa6a5bc0ff4@haskell.org> Message-ID: <066.7a9d2f112fe3b4f50efc748f46d165bb@haskell.org> #12730: Pattern synonym signature fails with unlifted type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Thanks. This works ok in HEAD. I have not checked the 8.0 branch. Looks like a dup of #12094, which is fixed. Can someone check and close? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 12:02:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 12:02:39 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.7142192418bebbb28ec9e9c10ee20485@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by simonpj): Phab:D2554 is abandoned; let's remove it from the ticket sinceit is now irrelevant (I assume). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 12:57:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 12:57:58 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.6a1d4a2bb0814ba29afa9f73be59190b@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: osa1 (added) Comment: I wonder why there's a consistent 2% increase in binary size; I was not expecting that. I have not looked at the code... when you are ready, seeing it all as one Phab diff (not lots) would be helpful. Omer may be thinking about nested CPR, and has an implementation on a branch somewhere. This is a particular instance of nested CPR, so it'd be good to sync up with him (cc'd). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 13:20:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 13:20:17 -0000 Subject: [GHC] #12731: Generic type class has type family; leads to big dep_finsts In-Reply-To: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> References: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> Message-ID: <060.f595dd00eea12c58480935849eef69f8@haskell.org> #12731: Generic type class has type family; leads to big dep_finsts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 goldfire): What a great blog post to link to. (Although it did remind me of reading Neal Stephenson's novel ''Anathem'', which takes place in an alternate universe where just about all technical concepts have been renamed.) I will summarize it: The author proposes and does an in-depth comparison of several approaches that can be used to avoid incoherence of either type families or classes (it's the same problem) by doing local checks instead of a check at module-import-graph join points. All of these rules prohibit orphan instances of any kind, but are otherwise much subtler than I would have guessed. While we could explore this possibility (does anyone use orphan type family instances?), I see a simpler approach: treat `Generic` like we do `Typeable`, by requiring that GHC provide the instances. Does anyone hand- write `Generic` instances? If we know that GHC has written the instances, then we can be sure of coherence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 14:05:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 14:05:07 -0000 Subject: [GHC] #12616: type synonyms confuse generalized newtype deriving role checking In-Reply-To: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> References: <050.1272ec2c15cc52ea318899f7c06dd470@haskell.org> Message-ID: <065.661ca7f2140f9926365519fb01819121@haskell.org> #12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: goldfire Type: bug | Status: closed Priority: low | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: generalized | newtype deriving roles rankntypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T12616 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as c93ad554c9f9788b3e2ec45fa4d0131101721536. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:09:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:09:23 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.665be0bc25534c5b624ae013e79b6935@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: UnboxedSums 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 simonpj): * owner: => osa1 * priority: normal => high * milestone: => 8.2.1 Comment: Omer might you look at this? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:12:53 -0000 Subject: [GHC] #12719: master branch broken with alex 3.2 In-Reply-To: <046.5acda0269d9f6f68996eb49b289d17fe@haskell.org> References: <046.5acda0269d9f6f68996eb49b289d17fe@haskell.org> Message-ID: <061.12fe1801558644c08408442f8e45d651@haskell.org> #12719: master branch broken with alex 3.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: upstream => closed * resolution: => fixed Comment: This was fixed in alex 3.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:23:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:23:08 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.b65b64793444a63bea82227d7fe6c64d@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): I mentioned this to Herbert and he said that while it isn't necessarily possible to remove fields from the default "new ticket" page, it should be possible to add some in the page template to inform submitters that they are under no obligation to fill in all of the fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:31:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:31:47 -0000 Subject: [GHC] #12735: Evaluate the feasibility of using lld for linking Message-ID: <046.512cf8539c4832daf355de78db41faba@haskell.org> #12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [DynamicLinkingDebate]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker]. Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:32:08 -0000 Subject: [GHC] #12735: Evaluate the feasibility of using lld for linking In-Reply-To: <046.512cf8539c4832daf355de78db41faba@haskell.org> References: <046.512cf8539c4832daf355de78db41faba@haskell.org> Message-ID: <061.e8618407d8b2c5d0af0c31fb9b21fc45@haskell.org> #12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -4,1 +4,1 @@ - [DynamicLinkingDebate]). + [[DynamicLinkingDebate]]). New description: Our runtime system's linker a represents a significant amount of rather tricky code. We have in the past attempted to jettison it by moving to dynamic linking, although this lead to its own set of issues (see [[DynamicLinkingDebate]]). Another approach would be to let someone else implement our linker for us. While in the past linkers were rather monolithic things, today there exists LLVM's `lld` [http://lld.llvm.org/|linker]. Like the other LLVM projects, its design is quite modular and can be used as a library. It seems likely that it could be made to do our bidding with enough effort. The question, of course, is whether this effort is greater than the effort we currently spend on the runtime linker. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:54:26 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.75385b6fd69dc12eed4de6f36d3c7af8@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 goldfire): That might be helpful.... even a little more direction would be an improvement. Thanks for looking! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 15:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 15:56:41 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.63df9f12a369b52912ef81747cf8d65b@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by GordonBGood): Replying to [comment:53 awson]: > Well, I've downloaded 8.0.1 release, tried it and all your examples immediately started to segfault, but after I replaced distributed binutils with the correct one all started to work flawlessly, no segfaults altogether for all your examples. So, Yes, I was unable to compile anything to run at all without segfaults using -fllvm on Windows 64-bit until I updated MSYS2 with pacman update so as to update to binutils 2.27-2, then downgraded LLVM from 3.8 back to 3.7.0-6, which is where I am sitting now with this problem. I think that one difference between our setups is that my path finds the MSYS2 bindir first before the mingw that comes with GHC 8.0.1, and perhaps some of those GHC mingw files have been patched or are versions that work with GHC 8.0.1 whereas the up-to-date MSYS2 ones aren't quite compatible. This would explain why 'Integer' has problems as I notice that MSYS2 has updated GMP files. I can move the LLVM 3.7 and binutils files into the GHC mingw folder and temporarily remove MSYS2 bindir from the path, but I need to know what binutil files were patched for binutils 2.27-2 or if I should just replace all of them. Another possible difference is that I am using the MSYS2 LLVM version 3.7.0 where you might be using the LLVM version 3.7.1 which may have some differences. I don't have a copy of LLVM 3.7.1 and don't know how to get the crucial two files 'llc.exe' and 'opt.exe' without compiling it as most binary distros have been replaced with newer versions. However, I did find a copy of a binary distro for MSYS2 mingw x86_64 LLVM 3.7.0-9 which I will try. It seems that this is just another case of incompatibilities between GHC and the versions of programs it requires such as specific versions of LLVM but perhaps others, which hopefully will be fixed with GHC 8.2.1 distributing versions that are known to work and automatically setting the path to use those versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 16:12:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 16:12:40 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.20d428abe30089c8ee85fb4119c43ce6@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): I've added a bit of text at the top of the new ticket page, > Thanks for your ticket! Don't worry if you can't fill in all of the fields, just tell us what you know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 17:10:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 17:10:50 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.0eeeeaa8ecd0061296428d4dcd0e0874@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Phyx-): This is a good testcase and it illustrates the problem nicely. I don't think it's GCC, I think ultimately, it's some emulation layer somewhere. `execv` is emulated somewhere, not by calling Windows's `CreateProcess` but probably some other posix function. I suspect it's somewhere in https://github.com/mirror/newlib-cygwin but that wouldn't explain the mingw version of GCC. If you replace `execv` with `CreateProcess` the example works correctly in all compilers {{{ #include #include int main(int argc, char *argv[]) { TCHAR * args[2] = {"ok", NULL}; STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); // Start the child process. if (!CreateProcess("ok.exe", // No module name (use command line) args[0], // Command line NULL, // Process handle not inheritable NULL, // Thread handle not inheritable FALSE, // Set handle inheritance to FALSE 0, // No creation flags NULL, // Use parent's environment block NULL, // Use parent's starting directory &si, // Pointer to STARTUPINFO structure &pi) // Pointer to PROCESS_INFORMATION structure ) { return 1; } // Wait until child process exits. WaitForSingleObject(pi.hProcess, INFINITE); // Close process and thread handles. CloseHandle(pi.hProcess); CloseHandle(pi.hThread); return 0; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 17:36:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 17:36:57 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.b1ea14cdda18f3f8cdd06e2c4af3d590@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D2570 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 17:43:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 17:43:21 -0000 Subject: [GHC] #12731: Generic type class has type family; leads to big dep_finsts In-Reply-To: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> References: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> Message-ID: <060.7167ff44f3156c7a36ced4239d894682@haskell.org> #12731: Generic type class has type family; leads to big dep_finsts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 ezyang): A quick grep of Hackage suggests it happens very rarely. I found one case in module-management: {{{ #if MIN_VERSION_Cabal(1,21,1) instance (Ord k, Generic k, Generic v) => Generic (Map k v) where type Rep (Map k v) = Rep [(k, v)] from = from . toList to = fromList . to #else }}} This is actually a pretty reasonable instance as far as things go, but I am sure I would not lose sleep if it got axed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 17:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 17:45:00 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.4ab1e1fd399c097c41587767e259f9b9@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): OK, I think this is a plan that we can actually do for 8.0.2 :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 18:19:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 18:19:08 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.7192f0ac4e8d6ccdadcb3aeda186bf25@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 goldfire): Thanks for adding that. It's helpful, though I imagine 90% of visitors will skip over it. Is it possible to use styling (italics, etc.) in field names? If a visitor sees that some fields are italicized or grayed or xxx, they might look around to find the key. Actually, it would be pretty awesome if we could apply a slight graying to the fields that we don't expect visitors to fill out. I imagine that all tickets all the time would have this graying, but a color change would, I think, be less jarring to us regulars than, say, italics would be. And the graying has just the right connotation to visitors. (We would also add a sentence at the top explaining, for those who look.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 20:26:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 20:26:38 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.8573e77de93486e4be22565dacb9466d@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): > Actually, it would be pretty awesome if we could apply a slight graying to the fields that we don't expect visitors to fill out. I imagine that all tickets all the time would have this graying, but a color change would, I think, be less jarring to us regulars than, say, italics would be. And the graying has just the right connotation to visitors. (We would also add a sentence at the top explaining, for those who look.) I think this should be pretty easily done. The next question is what fields in particular do we want users to provide? I suggest the following, * Priority * Version * Operating system * Architecture * Type of failure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 21:41:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 21:41:22 -0000 Subject: [GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified Message-ID: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (FFI) | Keywords: | Operating System: Windows ffi,registers,sse2,clobber,xmm | Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: https://github.com/bavis-m/raycast | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the [https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx MSDN], in the Microsoft x64 architecture function calls must preserve the SSE2 registers in the range XMM6-XMM15. The Haskell FFI can produce a function pointer via dynamic wrapper that, when called from MSVC x64 C code, does not preserve these registers, causing further floating-point operations in the C code to fail. I can reproduce this error in [https://github.com/bavis-m/raycast this project], which is a DOOM-style raycasting engine written in Haskell, that imports a C DLL with glue for rendering and window management. The Haskell executable generates a FunPtr to a frame update function using the dynamic import mechanism, and passes this to a long-lived C function that runs the update loop. Any time this update function is called from the C loop, subsequent floating point operations produce incorrect results (in this case, the next operations compute a view matrix for the OpenGL window). The output on every frame showing the view matrix should be: {{{ viewM: 0.003125 0.000000 0.000000 -1.000000 0.000000 0.004167 0.000000 -1.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 }}} Running the raycaster with the Release version of the DLL causes the value of this matrix to be corrupted. There is a patch provided (stub.patch in the root folder) that turns the Haskell update function into an empty stub. This causes the program to work. When stepping through the assembly code with this patch applied, I can see in the function prologue where the XMM registers are saved. Without the patch, these registers are not saved. Running the Debug version does not show this error; the register allocation must be different. I have been attempting to create a much simpler test case to reveal this code-generation issue, however it has been difficult. Even seemingly trivial changes can cause the bug to not show up, it is clearly dependent on the register allocation used internally to produce the assembly code. Instructions for building the project are in the readme. (You will need the Haskell Stack Tool, and Visual Studio 15). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 21:54:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 21:54:48 -0000 Subject: [GHC] #12664: System.Environment.withArgs and friends leak memory In-Reply-To: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> References: <047.7978a92d3c75c43fb5eb8747e9360932@haskell.org> Message-ID: <062.e53ef9dacaa2adbf36fd8da440b018da@haskell.org> #12664: System.Environment.withArgs and friends leak memory -------------------------------------+------------------------------------- Reporter: simonmar | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as b08ffec0aa9cf88ff47fd71d0c6e61d3a31d7b0d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 21:57:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 21:57:19 -0000 Subject: [GHC] #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap In-Reply-To: <045.54937ce05252b15889a7d80403561924@haskell.org> References: <045.54937ce05252b15889a7d80403561924@haskell.org> Message-ID: <060.f124d13170467825da12fc8f1ece0e0e@haskell.org> #12653: reexported-modules sometimes gets mangled, causes problems for bootstrap -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as bdfb90125009e269b2fbe7f1a7622cc5ca1cd52f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 18 22:32:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 18 Oct 2016 22:32:46 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 Message-ID: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Fresh validate from 5eab189b329344630f76b8751c1289ce480ca46b on x86_64 Linux: {{{ =====> T12227(normal) 1 of 1 [0, 0, 0] cd ./perf/compiler && "/home/hs01/ezyang/ghc-validate/inplace/test spaces/ghc-stage2" -c T12227.hs -fforce-recomp -dno-debug-output -fshow- warning-groups -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn- missed-specialisations -fno-ghci-history -O2 -ddump-hi -ddump-to-file +RTS -M1G +RTS -V0 -tT12227.comp.stats --machine-readable -RTS > T12227.comp.stderr 2>&1 bytes allocated value is too high: Expected T12227(normal) bytes allocated: 1822822016 +/-5% Lower bound T12227(normal) bytes allocated: 1731680915 Upper bound T12227(normal) bytes allocated: 1913963117 Actual T12227(normal) bytes allocated: 9256914200 Deviation T12227(normal) bytes allocated: 407.8 % *** unexpected stat test failure for T12227(normal) }}} That's a pretty awful regression, if it is real. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:10:47 -0000 Subject: [GHC] #12738: GHC drops -optl flags Message-ID: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a regression between GHC 7.10 and GHC 8.0. Repro script: {{{ GHC_ROOT=$HOME/local/ghc-8.0.1-facebook # built 8.0.1 branch, fails with recent HEAD as well GHC=$GHC_ROOT/inplace/bin/ghc-stage2 GPP=g++ touch build_info.o # irrelevant "$GHC" -no-auto-link-packages -pgml"$GPP" -o a.out build_info.o -optl- Xlinker -optl$GHC_ROOT/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.0.0.a -optl-Xlinker -optl-u -optl-Xlinker -optlghczmprim_GHCziTypes_Izh_static_info -v }}} Output from GHC 7.10 (expected): {{{ Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4 Using binary package database: /usr/local/haskell/ghc-7.10.2-x86_64/lib/ghc-7.10.2/package.conf.d/package.cache Using binary package database: /home/bnitka/.ghc/x86_64-linux-7.10.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 wired-in package base mapped to base-4.8.1.0-4f7206fd964c629946bb89db72c80011 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-90e8393d65f4ae44cb2026177a257f28 wired-in package ghc mapped to ghc-7.10.2-787f1a784665fb3ac2a1be1d9d85245b wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc2775839_0 *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc2775839_0/ghc_1.c -o /tmp/ghc2775839_0/ghc_2.o -I/usr/local/haskell/ghc-7.10.2-x86_64/lib/ghc-7.10.2/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc2775839_0/ghc_3.s -o /tmp/ghc2775839_0/ghc_4.o -I/usr/local/haskell/ghc-7.10.2-x86_64/lib/ghc-7.10.2/include *** Linker: 'g++' '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as- needed -Xlinker /home/bnitka/local/ghc-8.0.1-facebook/libraries/ghc-prim /dist-install/build/libHSghc-prim-0.5.0.0.a -Xlinker -u -Xlinker ghczmprim_GHCziTypes_Izh_static_info -o a.out build_info.o /tmp/ghc2775839_0/ghc_2.o /tmp/ghc2775839_0/ghc_4.o build_info.o: file not recognized: File truncated collect2: ld returned 1 exit status *** Deleting temp files: Deleting: /tmp/ghc2775839_0/ghc_4.o /tmp/ghc2775839_0/ghc_3.s /tmp/ghc2775839_0/ghc_2.o /tmp/ghc2775839_0/ghc_1.c *** Deleting temp dirs: Deleting: /tmp/ghc2775839_0 }}} Output from GHC 8.0: {{{ Glasgow Haskell Compiler, Version 8.0.1.20160729, stage 2 booted by GHC version 7.10.2 Using binary package database: /data/users/bnitka/ghc-8.0.1-facebook/inplace/lib/package.conf.d/package.cache loading package database /data/users/bnitka/ghc-8.0.1-facebook/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1.20160729 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc2778573_0 *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc2778573_0/ghc_1.c -o /tmp/ghc2778573_0/ghc_2.o -I/data/users/bnitka/ghc-8.0.1-facebook/rts/dist/build -I/data/users/bnitka/ghc-8.0.1-facebook/includes -I/data/users/bnitka/ghc-8.0.1-facebook/includes/dist- derivedconstants/header *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc2778573_0/ghc_4.s -o /tmp/ghc2778573_0/ghc_5.o *** Linker: 'g++' '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as- needed -Xlinker -Xlinker -u -Xlinker ghczmprim_GHCziTypes_Izh_static_info -o a.out -Wl,--gc-sections build_info.o /tmp/ghc2778573_0/ghc_2.o /tmp/ghc2778573_0/ghc_5.o /home/bnitka/local/ghc-8.0.1-facebook/libraries /ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a g++: ghczmprim_GHCziTypes_Izh_static_info: No such file or directory *** Deleting temp files: Deleting: /tmp/ghc2778573_0/ghc_7.rsp /tmp/ghc2778573_0/ghc_6.rsp /tmp/ghc2778573_0/ghc_5.o /tmp/ghc2778573_0/ghc_4.s /tmp/ghc2778573_0/ghc_3.rsp /tmp/ghc2778573_0/ghc_2.o /tmp/ghc2778573_0/ghc_1.c *** Deleting temp dirs: Deleting: /tmp/ghc2778573_0 `g++' failed in phase `Linker'. (Exit code: 1) }}} The relevant difference is in the flags passed to `g++`. {{{ 'g++' '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as- needed -Xlinker /home/bnitka/local/ghc-8.0.1-facebook/libraries/ghc-prim /dist-install/build/libHSghc-prim-0.5.0.0.a -Xlinker -u -Xlinker ghczmprim_GHCziTypes_Izh_static_info -o a.out build_info.o /tmp/ghc2775839_0/ghc_2.o /tmp/ghc2775839_0/ghc_4.o }}} vs {{{ 'g++' '-Wl,--hash-size=31' -Wl,--reduce-memory-overheads -Wl,--no-as- needed -Xlinker -Xlinker -u -Xlinker ghczmprim_GHCziTypes_Izh_static_info -o a.out -Wl,--gc-sections build_info.o /tmp/ghc2778573_0/ghc_2.o /tmp/ghc2778573_0/ghc_5.o /home/bnitka/local/ghc-8.0.1-facebook/libraries /ghc-prim/dist-install/build/libHSghc-prim-0.5.0.0.a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:21:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:21:29 -0000 Subject: [GHC] #12698: GHC panic on pattern synonym In-Reply-To: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> References: <051.23c7909ab25babe414e15e0d6c5c48ce@haskell.org> Message-ID: <066.e777f7cd7fcaa5bac3544cc2f29d0f75@haskell.org> #12698: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms 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 bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 5c02b842fa64bb06766d4e89615af84bc4db992b. That being said, I am strangely unable to reproduce the reported crash with 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:22:04 -0000 Subject: [GHC] #12676: Panic with piResultTys1 again In-Reply-To: <046.654ae7ec185238832f995e60e758edd9@haskell.org> References: <046.654ae7ec185238832f995e60e758edd9@haskell.org> Message-ID: <061.7b5d5a899059a62ae41087b2634c872e@haskell.org> #12676: Panic with piResultTys1 again -------------------------------------+------------------------------------- Reporter: pjmagni | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as bfaa770fdf97954e776f2d877270a59ec1bdc73d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:23:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:23:09 -0000 Subject: [GHC] #12589: GHC panic with defer-typed-holes In-Reply-To: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> References: <051.1ebcdc23cc88a24785e3b5ab5953310d@haskell.org> Message-ID: <066.86c76a41881bcbba0f8586eb8bbbcdee@haskell.org> #12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12589 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Test merged to `ghc-8.0` as 9467dfa8cc63de5742a27caf0cdab997156c7409. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:23:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:23:25 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.95c7b352e890fd54c6592fa45bd51c1d@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 danilo2): Ok, @Simon: 1) There are some special cases using stack regarding how it outputs its dump files, the docs for stack have been updated: https://github.com/commercialhaskell/stack/issues/2720 2) I was cutting down the example this evening. It took some time, but I've got it. It could be probably much simpler, but I think it is small enough to put it here, so here goes the example file we can test to investigate the error! :) {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeApplications #-} module Main where import Prelude import Control.Applicative import Control.Monad.Fix import Control.Monad.Trans.Identity import Control.Monad.Trans data A data B data Net data Type data Layer4 t l data TermStore -- Helpers: Stack data Stack layers (t :: * -> *) where SLayer :: t l -> Stack ls t -> Stack (l ': ls) t SNull :: Stack '[] t instance ( Constructor m (t l) , Constructor m (Stack ls t)) => Constructor m (Stack (l ': ls) t) instance Monad m => Constructor m (Stack '[] t) -- Helpers: Expr newtype Expr t layers = Expr (TermStack t layers) type TermStack t layers = Stack layers (Layer4 (Expr t layers)) -- Helpers: Funny typeclass class Monad m => Constructor m t instance ( Monad m, expr ~ Expr t layers, Constructor m (TermStack t layers) ) => Constructor m (Layer4 expr Type) -- HERE IS A FUNNY BEHAVIOR: the commented line raises context reduction stack overflow test_gr :: ( Constructor m (TermStack t layers), Inferable A layers m, Inferable B t m , bind ~ Expr t layers -- ) => m (Expr t layers) ) => m bind test_gr = undefined -- Explicit information about a type which could be infered class Monad m => Inferable (cls :: *) (t :: k) m | cls m -> t newtype KnownTypex (cls :: *) (t :: k) (m :: * -> *) (a :: *) = KnownTypex (IdentityT m a) deriving (Show, Functor, Monad, MonadIO, MonadFix, MonadTrans, Applicative, Alternative) instance {-# OVERLAPPABLE #-} (t ~ t', Monad m) => Inferable cls t (KnownTypex cls t' m) instance {-# OVERLAPPABLE #-} (Inferable cls t n, MonadTrans m, Monad (m n)) => Inferable cls t (m n) runInferenceTx :: forall cls t m a. KnownTypex cls t m a -> m a runInferenceTx = undefined -- running it test_ghc_err :: (MonadIO m, MonadFix m) => m (Expr Net '[Type]) test_ghc_err = runInferenceTx @B @Net $ runInferenceTx @A @'[Type] $ (test_gr) main :: IO () main = return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:23:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:23:54 -0000 Subject: [GHC] #12562: GHC panic on rebuild (idInfo r_XsTP) In-Reply-To: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> References: <049.c0d6aa30fef6e477b7d26d60ee73d3da@haskell.org> Message-ID: <064.ae7a2288c95b626cc9d3863ae6a066ca@haskell.org> #12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 8ab454d9a39655d34664be6e65a67e1697dc17bf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:24:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:24:24 -0000 Subject: [GHC] #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings In-Reply-To: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> References: <050.ffc2a8bf9799443e1119102b57db908a@haskell.org> Message-ID: <065.5e86725f3c9aec0bcce13304afe63934@haskell.org> #12688: derived Show instances aren't protected from RebindableSyntax+OverloadedStrings -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | rebindablesyntax overloadedstrings | deriving show string Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T12688 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2591 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as d7a1f682af766e6c1529932b24bada9053d5c4da. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:24:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:24:50 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.537ef3f7a3010ff922b9eb280216a26a@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12411 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged test to `ghc-8.0` as d84a824cebe94711528727bcb587bfc369ec36a2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:25:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:25:16 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.2321ca42fbaad69489b851df1909f92e@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T12411 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 00:25:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 00:25:45 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.568995c44ec43d7d573004634897a64d@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 01:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 01:29:47 -0000 Subject: [GHC] #12739: Failure installing elm-init-1.0.5 (ExitFailure (-6)) Message-ID: <044.d04b081fdc88360a67572c2b270dd90a@haskell.org> #12739: Failure installing elm-init-1.0.5 (ExitFailure (-6)) --------------------------------------+--------------------------------- Reporter: rofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- In a new directory I ran: cabal sandbox init cabal update cabal install elm-init I got the following: Resolving dependencies... Notice: installing into a sandbox located at /home/rofer/Apps/elm-init/.cabal-sandbox Downloading base-compat-0.9.1... Configuring base-unicode-symbols-0.2.2.4... Downloading binary-0.8.4.1... Configuring fail-4.9.0.0... Configuring filepath-1.4.1.0... Configuring ghc-boot-th-8.0.1... Configuring primitive-0.6.1.0... Configuring transformers-compat-0.5.1.3... Downloading pretty-1.1.3.4... Configuring base-compat-0.9.1... Downloading time-locale-compat-0.1.1.3... Configuring binary-0.8.4.1... Building base-unicode-symbols-0.2.2.4... Building fail-4.9.0.0... Building ghc-boot-th-8.0.1... Building filepath-1.4.1.0... Building primitive-0.6.1.0... Building transformers-compat-0.5.1.3... Building binary-0.8.4.1... Building base-compat-0.9.1... Installed fail-4.9.0.0 Configuring time-locale-compat-0.1.1.3... Building time-locale-compat-0.1.1.3... Configuring pretty-1.1.3.4... Installed base-unicode-symbols-0.2.2.4 Building pretty-1.1.3.4... Installed time-locale-compat-0.1.1.3 Installed filepath-1.4.1.0 Downloading directory-1.2.7.0... Configuring directory-1.2.7.0... Installed primitive-0.6.1.0 Building directory-1.2.7.0... Configuring vector-0.11.0.0... Building vector-0.11.0.0... Installed ghc-boot-th-8.0.1 Installed base-compat-0.9.1 Installed pretty-1.1.3.4 Downloading template-haskell-2.11.0.0... Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Installed directory-1.2.7.0 Configuring process-1.4.2.0... Installed transformers-compat-0.5.1.3 Building process-1.4.2.0... Installed process-1.4.2.0 Installed binary-0.8.4.1 Configuring text-1.2.2.1... Building text-1.2.2.1... Downloading template-haskell-2.11.0.0... [66/181]Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Installed directory-1.2.7.0 Configuring process-1.4.2.0... Installed transformers-compat-0.5.1.3 Building process-1.4.2.0... Installed process-1.4.2.0 Installed binary-0.8.4.1 Configuring text-1.2.2.1... Building text-1.2.2.1... Installed template-haskell-2.11.0.0 Downloading cmdargs-0.10.14... Downloading file-embed-0.0.10... Configuring file-embed-0.0.10... Downloading tagged-0.8.5... Configuring cmdargs-0.10.14... Configuring tagged-0.8.5... Building file-embed-0.0.10... Building cmdargs-0.10.14... Building tagged-0.8.5... Installed file-embed-0.0.10 Installed tagged-0.8.5 Installed cmdargs-0.10.14 Installed text-1.2.2.1 Configuring hashable-1.2.4.0... Building hashable-1.2.4.0... Installed vector-0.11.0.0 Installed hashable-1.2.4.0 Downloading nats-1.1.1... Downloading scientific-0.3.4.9... Configuring scientific-0.3.4.9... Downloading unordered-containers-0.2.7.1... Configuring nats-1.1.1... Configuring unordered-containers-0.2.7.1... Building scientific-0.3.4.9... Building nats-1.1.1... Building unordered-containers-0.2.7.1... Installed nats-1.1.1 Installed scientific-0.3.4.9 Installed unordered-containers-0.2.7.1 Downloading semigroups-0.18.2... Configuring semigroups-0.18.2... Building semigroups-0.18.2... Installed semigroups-0.18.2 Downloading attoparsec-0.13.1.0... Configuring attoparsec-0.13.1.0... Building attoparsec-0.13.1.0... Installed attoparsec-0.13.1.0 Downloading aeson-1.0.2.0... Configuring aeson-1.0.2.0... Building aeson-1.0.2.0... Installed aeson-1.0.2.0 Downloading aeson-pretty-0.8.2... Configuring aeson-pretty-0.8.2... Building aeson-pretty-0.8.2... Installed aeson-pretty-0.8.2 Downloading elm-init-1.0.5... Configuring elm-init-1.0.5... Building elm-init-1.0.5... Failed to install elm-init-1.0.5 Build log ( /home/rofer/Apps/elm-init/.cabal-sandbox/logs/elm- init-1.0.5.log ): cabal: Entering directory '/tmp/cabal-tmp-27520/elm-init-1.0.5' Configuring elm-init-1.0.5... Building elm-init-1.0.5... Preprocessing executable 'elm-init' for elm-init-1.0.5... [1 of 5] Compiling ElmInit.Util ( src/ElmInit/Util.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Util.p_o ) [2 of 5] Compiling ElmInit.Interact ( src/ElmInit/Interact.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Interact.p_o ) src/ElmInit/Interact.hs:10:1: Warning: The import of ‘<*>’ from module ‘Control.Applicative’ is redundant [3 of 5] Compiling ElmInit.Types ( src/ElmInit/Types.hs, dist/dist- sandbox-7912c192/build/elm-init/elm-init-tmp/ElmInit/Types.p_o ) src/ElmInit/Types.hs:87:1: Warning: Defined but not used: ‘emptyDecisions’ [4 of 5] Compiling ElmInit ( src/ElmInit.hs, dist/dist-sandbox- 7912c192/build/elm-init/elm-init-tmp/ElmInit.p_o ) [5 of 5] Compiling Main ( src/Main.hs, dist/dist-sandbox- 7912c192/build/elm-init/elm-init-tmp/Main.p_o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package filepath-1.4.1.0 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.7.0 ... linking ... done. Loading package process-1.4.2.0 ... linking ... done. Loading package ghc-boot-th-8.0.1 ... linking ... done. Loading package pretty-1.1.3.4 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package file-embed-0.0.10 ... linking ... done. Loading package base-unicode-symbols-0.2.2.4 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package fail-4.9.0.0 ... linking ... done. Loading package binary-0.8.4.1 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.4.0 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package primitive-0.6.1.0 ... linking ... done. Loading package vector-0.11.0.0 ... linking ... done. Loading package scientific-0.3.4.9 ... linking ... done. Loading package nats-1.1.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package transformers-compat-0.5.1.3 ... linking ... done. Loading package tagged-0.8.5 ... linking ... done. Loading package unordered-containers-0.2.7.1 ... linking ... done. Loading package semigroups-0.18.2 ... linking ... done. Loading package attoparsec-0.13.1.0 ... linking ... done. Loading package base-compat-0.9.1 ... linking ... done. Loading package dlist-0.7.1 ... linking ... done. Loading package time-locale-compat-0.1.1.3 ... linking ... done. Loading package aeson-1.0.2.0 ... linking ... done. Loading package aeson-pretty-0.8.2 ... linking ... done. ghc: internal error: stg_ap_pp_ret (GHC version 7.8.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/tmp/cabal-tmp-27520/elm-init-1.0.5' cabal: Error: some packages failed to install: elm-init-1.0.5 failed during the building phase. The exception was: ExitFailure (-6) I'm on Fedora 23 (4.7.6-100.fc23.x86_64). Let me know if you need anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:15:19 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.1276224649ae3a05596762bd88843a83@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 goldfire): Agreed on those fields. But while we're here, can we tweak Type of failure? I would want to add "Poor/confusing error message" and change "Compile-time crash" to "Compile-time crash or panic". The former is a very common source of bug reports, and I wouldn't want someone reporting a panic to panic for not seeing "panic" in the list. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:35:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:35:11 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.f5586cab32c49a998dbdf8f5da6cbcd1@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): > I would want to add "Poor/confusing error message" and change "Compile- time crash" to "Compile-time crash or panic". The former is a very common source of bug reports, and I wouldn't want someone reporting a panic to panic for not seeing "panic" in the list. Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:46:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:46:09 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.0715ff14169cd37f9d30063b1922f357@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 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 bgamari): Arg. I just looked more carefully at styling the fields of the new ticket form and unfortunately it doesn't look like this will be possible afterall. The problem is that the form itself is generated and the generator provides no `id` or `class` attributes on which to hang a CSS style. Short of maintaining a fork of Trac I'm not sure I see a great way around this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:46:30 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.e04a0d26b319085a5559088500b55ce3@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2610 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3866481f228b28687c4021d9deb16e2138fdc008/ghc" 3866481f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3866481f228b28687c4021d9deb16e2138fdc008" Compute export hash based on ALL transitive orphan modules. Previously we pruned out orphan modules from external packages but this was wrong. Fixes #12733 (which has more discussion.) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2610 GHC Trac Issues: #12733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:46:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:46:46 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.23d8a51fc47c75bb49107a9217d559bc@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2610 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:46:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:46:52 -0000 Subject: [GHC] #12733: Orphan hashes are not being propagated correctly In-Reply-To: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> References: <045.aa9085bab326ac5116b61755a09eecfe@haskell.org> Message-ID: <060.2a4faaceed7b7b5048ddebc75d57aeac@haskell.org> #12733: Orphan hashes are not being propagated correctly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2610 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 02:57:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 02:57:07 -0000 Subject: [GHC] #12140: Clarify Trac menus for new reporters In-Reply-To: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> References: <047.3f74f47fb595547574689cfded0e6a0c@haskell.org> Message-ID: <062.a31512366d7ad8d2a9dc3a4ddb406247@haskell.org> #12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: wontfix | 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 goldfire): * status: new => closed * resolution: => wontfix Comment: Bah. Oh well. We tried. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 03:43:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 03:43:10 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.9d42997d7964cfc87bc2ca4bf7c29677@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: phab:D2450, phab:D2514 => phab:D2613 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 08:22:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 08:22:07 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.f3c76e35533113fc1d8f58ad722b3ba8@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): One way to help disentangle the difference between generativity and nominal distinctness is to look at the meaning of abstract types in signatures in an elaboration to a simpler language like Haskell! When I write a unit: {{{ unit p where signature A where data T data S module M where import A f :: T ~ S => a -> b f x = x }}} I am effectively defining a Haskell program along the lines (with a little cheating to have structural records): {{{ p :: forall t s. { f :: forall a b. t ~ s => a -> b } p = { f = \x -> x } -- ill-typed }}} When I am typechecking the body of p, `t ~ s` clearly does not hold, as `t` and `s` are both skolem variables and aren't available for unification. But that doesn't mean that we can treat the body of `f` as inaccessible: obviously if I invoke p as `p @Int @Int`, `Int ~ Int` is provable. What Backpack takes advantage of is the outrageous coincidence between skolem variables and abstract types. This should not at all be surprising, since abstract types are existential types, and (∃x. τ) -> τ' is equivalent to ∀x. (τ -> τ'). We want to treat abstract types like skolem variables, and I conjecture that the rules for OutsideIn(X) are compatible with this treatment, except for a few simplification rules (like eager failure when a given does not canonicalize). This would be good to pose formally and check with the paper. I think this also explains the confusing tension between "abstract data is generative" but "type synonyms are not generative, and thus should not be allowed to implement abstract data". Skolem variables are extremely well behaved: they can only be instantiated by types, so if we have `s :: * -> *` no one is going to set `s ~ S`, where `type S a = ...`. `S` is just not a valid type. And of course, all types are "generative" in the sense described earlier. (Instances (and the need for abstract types to be implemented without type families) are a giant fly in the ointment, but we are punting on soundness in this case *anyway*, so I am not inclined to look to closely at the matter.) The claim that T does not unify with S, EVER (as is the case in an hs-boot file) is a very unnatural claim that would be difficult to translate into Haskell via this elaboration. I would argue this is more of an artifact of how we have implemented hs-boot files over anything else (if we had shaping, this "nominal distinctness" wouldn't even hold there.) tl;dr: Abstract types in signatures are skolem variables spelled with capital letters; the rules for inference with abstract types are the same as the rules for inference with skolem variables (modulo early failure when givens fail to canonicalize). You can instantiate skolem variables with whatever you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 08:24:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 08:24:41 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.bf1c93ee77905bd7b6212d2d3a92099c@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 simonmar): * cc: Phyx- (added) Comment: I'm suspicious of this: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/SysTools.hs;02f2f21ce4a9969406cf1772dc5955a97386777a$918-933 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 11:24:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 11:24:04 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax In-Reply-To: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> References: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> Message-ID: <062.c87ad6fe1e39d5b82616f766751715c5@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1f09c16c38a2112322d8eab95cd1269daaf5a818/ghc" 1f09c16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09c16c38a2112322d8eab95cd1269daaf5a818" Test for newtype with unboxed argument Newtypes cannot (currently) have an unboxed argument type. But Trac #12729 showed that this was only being checked for newtypes in H98 syntax; in GADT snytax they were let through. This patch moves the test to checkValidDataCon, where it properly belongs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 11:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 11:25:07 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax In-Reply-To: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> References: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> Message-ID: <062.3544aad2b33970fc299ea89469d6dc8c@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T12729 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T12729 Comment: Good bug report thanks. Easily fixed. Merge to 8.0. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 11:26:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 11:26:10 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.74b0572b3b6c1987ca54ef42e9daef4c@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: hsyl20@… (added) Comment: Sylvain, this your patch. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 11:37:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 11:37:46 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.5190da0b97a808665c3492bc76c67892@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. I can reproduce, thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 11:52:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 11:52:03 -0000 Subject: [GHC] #12716: Suggest ScopedTypeVariables when type variable not in scope In-Reply-To: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> References: <045.4174a0264cca18f1dfc5ee9ce8258cb0@haskell.org> Message-ID: <060.b4a458c6430535f57192478670b6a446@haskell.org> #12716: Suggest ScopedTypeVariables when type variable not in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | 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 simonpj): I would love someone to work on this a bit. In Edward's example above, it would be relatively easy to put 'a' in the environment with a flag to say "Not really in scope unless you use `ScopedTypeVariables`. But there is more thinking to do. What if he'd written {{{ f :: forall a. a -> a f x = let g :: a -> a g _ = x in g x }}} Here the programmer probably intended the inner `a -> a` to be scoped by the `forall`; but as it stands, without `ScopedTypeVariables` it means {{{ g :: forall a. a->a }}} which will then be rejected by the type checker. I suggest that * `ExplicitForAll` should imply `ScopedTypeVariables`. (The reverse is already true!) * 'RankNTypes` should imply `ScopedTypeVariables`. (`RankNTypes` already implies `ExplicitForAll`, so the earlier bullet would imply this one.) You could always say `ExplicitForAll, NoScopedTypeVariables` if you really wanted. That still leaves #9244 and friends wanting a better error message/suggestion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:05:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:05:58 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.e9506e4be940a46bc76639afa54818bf@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 Phyx-): Yes that function does not recognize libraries passed to the linker via `-optl` or `-Xlinker` flags, only `-l` and giving the archive file as a normal argument. This was an oversight on my part. The whole reason this is even needed is because of how GHC is combining arguments from packages and libraries and commandline (https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/SysTools.hs;02f2f21ce4a9969406cf1772dc5955a97386777a$913). Especially when a core package has library dependencies like base and rts. What it was attempting to prevent, is for symbols from libraries which the user didn't specify but are added due to another dependency are used during linking to resolve symbols instead of ones you provide in your link command (or vice versa). Particularly without this you would always link against the wrong `main` on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:20:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:20:36 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.bf9a6aaeef06f7bd9b9213c71610aa2c@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 niteria): * owner: => niteria Comment: I have a patch that retains `-Xlinker` flags, in the same way that 8c1ceddd50158f79f9ff103f8f34be9856d4da1d does. I'm just crafting a test now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:26:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:26:19 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.7239ffc30e1769c3d44c2e46cfa0cd78@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 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 Phyx-): Thanks, Sorry for the breakage. Do you know if there are any other ways to pass library arguments to the linker than these 4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:39:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:39:57 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.3160f4fee341772e8fa00cb0157fc927@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): Very interesting observations. I agree! Note that skolem variables even have the "don't fail eagerly in a given" behavior that you want. I really like this way of thinking about it all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:46:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:46:11 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.89ab6de056391dcc95a6434a16d51a15@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The patch the Edward cites is not the first that shows this failure. I've seen this is a few other cases and have been meaning to track it down. Last time I looked at this I determined that 2756af87aebee769ffca959adc4b9dc607a49fdb was the first failing commit, although ran out of time before I could replicate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:57:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:57:53 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.884d1bd0616a2c61837d745e9bcaf61b@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I think I know what this is, just testing a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 12:58:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 12:58:07 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.d1c78e62abbf6e0af92547c699205549@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonmar): * milestone: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 13:22:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 13:22:35 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.5c644637efb3ddae98d2555015742857@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2617 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonmar): * differential: => Phab:D2617 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 13:33:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 13:33:01 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.d36b48667fd05ba38c2eb567de0a9ca8@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2cb8cc26df6af431d30b6964710ea2d859ca2bcd/ghc" 2cb8cc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cb8cc26df6af431d30b6964710ea2d859ca2bcd" StgCmmPrim: Add missing write barrier. On architectures with weak memory consistency a write barrier is needed before the write to the pointer array. Fixes #12469 Test Plan: rebuilt Stackage nightly twice on powerpc64le Reviewers: hvr, rrnewton, erikd, austin, simonmar, bgamari Reviewed By: erikd, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2525 GHC Trac Issues: #12469 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 13:45:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 13:45:53 -0000 Subject: [GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified In-Reply-To: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> References: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> Message-ID: <060.730d12edcb26517ceb9bd76b1a6bbf27@haskell.org> #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.3 Resolution: | Keywords: | ffi,registers,sse2,clobber,xmm Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | https://github.com/bavis-m/raycast Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Reading the doc {{{ XMM6:XMM15, YMM6:YMM15 Nonvolatile (XMM), Volatile (upper half of YMM) Must be preserved as needed by callee. YMM registers must be preserved as needed by caller. }}} It looks like if you have the callee clobber ymm6-16 you can get the caller to handle the save / restore Alternatively, a simple wrapper around the Haskell functions could explicitly read xmm6-16 before entering the Haskell call and set the values after return. So that should at least fix it with a simple read call and set sequence on the c side That said, sounds like this indeed a bug, though the xmm vs ymm caller vs callee stuff is kinda gross and definitely a bug in the wrappers/stubs generated for the windows platform. Please share if the near term work around helps. I realize it adds an extra indirection in the Haskell call, but probably simplest way to fix it this week? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 13:47:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 13:47:47 -0000 Subject: [GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified In-Reply-To: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> References: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> Message-ID: <060.7bb51e9056a5bc7314da8cf744debe87@haskell.org> #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.3 Resolution: | Keywords: | ffi,registers,sse2,clobber,xmm Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | https://github.com/bavis-m/raycast Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): To clarify: you could also compile your c code to assume it's in an avx/avx2 microarchtiecture to see if that works. But if you wanna support sse2 targets a teeny bit of xmm read write code might help -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 14:32:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 14:32:29 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.e79a45d4cab2901c680be5105420b953@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I don't think my patch caused this failure: T12227 doesn't even use the FFI. 2756af87aebee769ffca959adc4b9dc607a49fdb is the patch adding the failing test in ghc-8.0 branch. If it is the first failing commit as @bgamari says, we should check patches from master that have not been cherry-picked into the ghc-8.0 branch (a priori committed in master before 89a8be71a3715c948cebcb19ac81f84da0e6270e if it validates). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 17:32:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 17:32:33 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.be4d3dfc9edfc8385eb42bf8a0414bbe@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed the patch I cited in comment:2 is the patch that adds the failing test. Sadly I don't seeing any relevant patches to `compiler/util/Pretty.hs` missing from `ghc-8.0`. Tracking this one down may be a bit tricky. Thankfully the difference is quite large, so comparing ticky profiles from `ghc-8.0` and `master` around the time should be illuminating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 17:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 17:45:49 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.ab312aa2b5b855a80a95e472afaeddcc@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Is it quadratic even for the simplest case? I have `A.gen.sh`: {{{ N=$1 echo "module A where" echo echo "data X = X" for i in $(seq 1 $N); do echo " | X$i"; done echo echo "instance Enum X where" for i in $(seq 1 $N); do echo " toEnum $i = X$i"; done for i in $(seq 1 $N); do echo " fromEnum X$i = $i"; done }}} Trying to compile for a datatype with 4000 constructors gives me: {{{ $ ./A.gen.sh 4000 > A.hs && ./inplace/bin/ghc-stage2 -dno-debug-output A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:8006:3: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘fromEnum’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} This is not a made up example, we actually have enumeration types with 10k constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 18:19:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 18:19:43 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.900319a210aa38aef2de73b573f54f35@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks Richard! I hope we see you again when you have time for some hacking. I had a look at this and the result is Phab:D2609. There is a bit more to it that comment:41 suggests. In addition to what I describe there I also needed to track down a few places outside of the simplifier where unfoldings were being force. The first place I encountered was `OccurAnalyse`, which wants to look a free variables of unfoldings. There are two ways I can envision fixing this, * Have occurrence analysis pretend there are no unfoldings if `-fignore- interface-pragmas` is passed. Note that this is a bit of a lie: we would be ignoring all unfoldings, not just those from interface files (since we can't tell the difference between the two under the current scheme). * Skip occurrence analysis altogether. If we are going to disable inlining entirely then (I think) it serves little purpose. Simon, perhaps you could weigh in here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 20:08:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 20:08:02 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.172eb963f861e7c4e6ef95a1ebb6bac2@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): I'm struggling to get this. Seems to me that anything based on ABI is fishy since ABI is not a reliable indicator of identity. The 'id' field is for identity and the proper solution is to make that strong enough to be a proper identity. I'm sympathetic to @simonmar's point that it's nice to be able to just union all dbs. And that should work just fine provided that ids are strong enough. If your use case could in principle be handled by coping all the package.db/*.conf files from all the DBs into one DB then you're in a situation where there is only one instance of any pkgid already, and unordered unioning is fine. If we're using weak package ids, as in Simon's example in comment:30 then we're in deep trouble already. There's no way to know which r instance the q package needs. So if I understand correctly, @ezyang is proposing a kludge for this situation where we additionally record and stash the ABI use it also on all edges. But the ABI isn't enough. The proper solution imho is to distinguish the two 'r' instances by giving them different ids. But it doesn't sound like the situation @niteria has looks like this, right? I assume that you've got the ids actually unique, and you're not relying on shadowing. Your example would work just fine with unioning presumably. I don't mind ABI tracking as an additional sanity check (and it tells you when you could plausibly deliberately try switching deps without re- compiling), but I don't think we should be using it for anything important like disambiguating as part of db merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 20:19:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 20:19:37 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.950a2516cd997fc6524900a945b2e9ec@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > But it doesn't sound like the situation @niteria has looks like this, right? I assume that you've got the ids actually unique, and you're not relying on shadowing. Your example would work just fine with unioning presumably. Yes, I'm not relying on shadowing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 20:20:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 20:20:35 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.64b9483baf869d1dd1734ea1d6d44fef@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Small update: I have a branch implementing non-compressing `ConApp` that validates and with no significant effect on the program runtimes. And already now, two perf test cases (#9961 and #9233) improved! So there might be something in here for us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 20:45:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 20:45:13 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.04905cb98723b6442732eed73e5990a1@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): According to ticky, it looks like the primary differences between `master` (namely 2cb8cc26df6af431d30b6964710ea2d859ca2bcd) and `ghc-8.0` (namely a32221830e478bb7c282ff325d9f62cc16af40da, which is admittedly quite far removed chronologically from the cherry-picked commit) are indeed in `Pretty`, {{{ | Change | alloc A | alloc B | name | |---------------|-----------|------------|------------------------------------------------------------------| | +3474432240.0 | 262333536 | 3736765776 | beside (ghc:Pretty) | | +951367008.0 | 221431440 | 1172798448 | $waboveNest (ghc:Pretty) | | +140163848.0 | 91135776 | 231299624 | (ghc:Coercion.coercionKind_go) | | +118356184.0 | 63778576 | 182134760 | $wsplitAtList (ghc:Util.) | | +111367360.0 | 640 | 111368000 | $w$cput_6 (ghc:Binary.) | | +94517880.0 | 18616520 | 113134400 | $wunpack (ghc:Encoding) | | +85860960.0 | 13610200 | 99471160 | $windent (ghc:Pretty) | | +45853128.0 | 13206856 | 59059984 | $s$wget1 (ghc:Pretty) | | +31953400.0 | 8224616 | 40178016 | $wsep1 (ghc:Pretty.) | | +29843944.0 | 8127648 | 37971592 | $wpprName (ghc:Name.) | | +29057288.0 | 20964736 | 50022024 | $wsubstTyWith (ghc:TyCoRep.) | | +22840864.0 | 11732016 | 34572880 | $wtyCoFVsOfType (ghc:TyCoRep.) | | +22640112.0 | 17493648 | 40133760 | (ghc:TyCon.expandSynTyCon_maybe) | | +22354288.0 | 5551864 | 27906152 | $wlay2 (ghc:Pretty) | | +19673016.0 | 14129160 | 33802176 | (ghc:Unify.liftCoMatch) | | +16728760.0 | 9231400 | 25960160 | (ghc:Unify.ty_co_match) | | +15683720.0 | 9053800 | 24737520 | $wcoercionKindRole (ghc:Coercion.) | | +15627024.0 | 3566736 | 19193760 | (ghc:IfaceType.toIfaceTcArgs_go) | | +15499856.0 | 3545152 | 19045008 | $wget (ghc:Pretty) | | +15113200.0 | 5327048 | 20440248 | (ghc:IfaceType.toIfaceType) | | +14813696.0 | 3417088 | 18230784 | $wppr_iface_tc_app (ghc:IfaceType) | | +14507168.0 | 2747264 | 17254432 | (ghc:Name.pprModulePrefix) | | +13158528.0 | 2774064 | 15932592 | $wxs1 (ghc:Pretty) | | +12767416.0 | 5934000 | 18701416 | (ghc:OptCoercion.opt_co4) | | +11420416.0 | 2612848 | 14033264 | $wlay1 (ghc:Pretty) | | +11400448.0 | 7529920 | 18930368 | $ssubst_ty (ghc:TyCoRep.composeTCvSubst_) | | +10744600.0 | 79480 | 10824080 | $w$cput_7 (ghc:IfaceType.) | | +10555272.0 | 3780088 | 14335360 | (ghc:IfaceType.toIfaceTcArgs) | | +10380952.0 | 6663952 | 17044904 | isAxiom_maybe (ghc:OptCoercion) | ... }}} Working on why this is the case will require some more effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 21:37:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 21:37:20 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.d8c554c8a6151e6d404689ba92ed25cd@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): I guess I should also add, the OutsideIn(X) paper has no discussion of higher kinded types (`a :: * -> *`), so I guess any such comparison will have to be limited to the code actually in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 21:47:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 21:47:34 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.1c961eb233972220b4f9412028b893b6@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 ezyang): Richard, do you know where in the typechecker is the handling for skolem variables to "not fail eagerly in a given"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 21:48:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 21:48:45 -0000 Subject: [GHC] #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems Message-ID: <046.91b5890d1ed5d2d28b55eb580654ca09@haskell.org> #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems -------------------------------------+------------------------------------- Reporter: gliptak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I downloaded http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-x86_64-deb8-linux.tar.xz and running configure on Alpine Linux (musl based) failed. The immediate cause seems to be that ghc-* files are not linked statically. {{{ /tmp/ghc-8.0.1 # file utils/ghc-cabal/dist-install/build/tmp/ghc-cabal utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6359ffd9a860387d6f91c40dccceaddd493f7a54, not stripped /tmp/ghc-8.0.1 # file utils/ghc-pwd/dist-install/build/tmp/ghc-pwd utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9fcf1bc38db049d6bafc6e611c09b6700071bfbb, not stripped }}} Could static linkage be considered for these helpers allowing them to run on non-glibc setups? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 21:55:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 21:55:13 -0000 Subject: [GHC] #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems In-Reply-To: <046.91b5890d1ed5d2d28b55eb580654ca09@haskell.org> References: <046.91b5890d1ed5d2d28b55eb580654ca09@haskell.org> Message-ID: <061.3edea88d5993a1e205d25112817ba005@haskell.org> #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems -------------------------------------+------------------------------------- Reporter: gliptak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): But that's a binary distribution and the ghc binary itself is also dynamically linked against glibc. What good would it do you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 19 22:02:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 19 Oct 2016 22:02:58 -0000 Subject: [GHC] #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems In-Reply-To: <046.91b5890d1ed5d2d28b55eb580654ca09@haskell.org> References: <046.91b5890d1ed5d2d28b55eb580654ca09@haskell.org> Message-ID: <061.b73c55e99a6f33eb03749716a075680d@haskell.org> #12740: generic Linux installer contains dynamically linked helpers failing to run on non glibc systems -------------------------------------+------------------------------------- Reporter: gliptak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gliptak): Could a static binary distribution made available than? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 00:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 00:58:39 -0000 Subject: [GHC] #12741: --numa doesn't work even if libnuma is available Message-ID: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> #12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The configure script set USE_LIBNUMA to 1 if numa exists however the code checks for HAVE_LIBNUMA. From the main directory, {{{ ./configure && make clean && make boot && make cd nofib/parallel/queens ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded ./Main 15 +RTS -N24 -s -A64m --numa }}} It fails saying {{{ Main: --numa: OS reports NUMA is not available }}} https://phabricator.haskell.org/D2329 introduced this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 01:13:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 01:13:40 -0000 Subject: [GHC] #12741: --numa doesn't work even if libnuma is available In-Reply-To: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> References: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> Message-ID: <061.138524bb6688d642cbf927aa1a135d85@haskell.org> #12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darshan): * owner: => darshan * differential: => D2620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 07:57:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 07:57:24 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.6e489e72a22c19ef12f7aacc437e9b99@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @duncan in practice the keys will often be strong enough. However, there are a couple of reasons why we can end up with package builds that have the same key but are incompatible. * Prior to GHC 8.0.2 non-determinism meant that the key did not determine the ABI * We don't want the key to be a function of the source code, because that would entail too much recompilation during development. For this reason, the GHC build system picks deterministic package keys, and I believe Cabal doesn't hash the source code to compute the package key (but I just gave up trying to confirm that after trawling through the Cabal source code for a few minutes which seems to have got terrifyingly complex since I last looked at it!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 09:36:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 09:36:34 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.ad795ce9fbe89b30d00fa849d6800d99@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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 Iceland_jack): [http://cs.brynmawr.edu/~rae/papers/2016/thesis/eisenberg-thesis-draft.pdf Eisenberg]: > A ''data family'' defines a family of datatypes. An example shows best how this works: > > {{{#!hs > data family Array a -- compact storage of elements of type a > data instance Array Bool = MkArrayBool ByteArray > data instance Array Int = MkArrayInt (Vector Int) > }}} > > With such a definition, we can have a different runtime representation for `Array Bool` than we do for `Array Int`, something not possible with more traditional parameterized types. The part about **runtime representation** made me wonder if you could define {{{#!hs -- × × × FAILS × × × data family Array a :: TYPE rep }}} I dunno about the instances, maybe using [https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Proposal3:Allownewtypesoverunliftedtypes Proposal 3: Allow newtypes over unlifted types] {{{#!hs newtype instance Array Int# :: TYPE PtrRepUnlifted where MkInt# :: ByteArray# -> Array Int# newtype instance Array (##) :: TYPE IntRep where MkInt# :: Int# -> Array (##) }}} I don't really understand representation polymorphism, may suffer from same problem as #11471. ---- {{{#!hs -- WORKS FINE data family Array (a :: TYPE rep) :: Type -- × × × FAILS × × × -- -- Unexpected type ‘Int#’ data Array Int# -- Should this fail? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 12:56:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 12:56:28 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.7ce41bdc8244fbb3a7d1ce0dc1178cc7@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): I've compared the resulting Core. The difference is that the version with INLINE recomputes `((2 ^ (8 :: Int) - 1)` every time, while the manually inlined version uses a value computed just once (note that the value is of type `Word32` --- I haven't verified that it matters). In the source code the constant is, e.g., here: https://github.com/LambdaHack/LambdaHack/blob /ghc-bug-12603/Game/LambdaHack/Common/Color.hs#L94 Here are the relevant snippets of Core. {{{ 379842537fadd870f9dd3304e0182c0b attrCharFromW1 :: Word32 {- Unfolding: (case $wf 2## 8# of ww { DEFAULT -> W32# (narrow32Word# (minusWord# ww 1##)) }) -} 0a91b1a84599352c004a37572b9588c1 $wf :: Word# -> Int# -> Word# {- Arity: 2, HasNoCafRefs, Strictness: , Inline: [0] -} 41b3e215bf375441beb5fb607472bd73 $wattrCharFromW32 :: Word# -> (# Attr, Char# #) {- Arity: 1, Strictness: , Inline: [0], Unfolding: (\ (ww :: Word#) -> case attrCharFromW1 of wild1 { W32# y# -> let { x :: Int# = word2Int# (and# (uncheckedShiftRL# ww 8#) y#) } in case tagToEnum# @ Bool (>=# x 0#) of wild { False -> case $fBinaryColor3 x ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Bool (<=# x 15#) of wild2 { False -> case $fBinaryColor3 x ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Color x of dt { DEFAULT -> let { x1 :: Int# = word2Int# (and# ww y#) } in case tagToEnum# @ Bool (>=# x1 0#) of wild3 { False -> case $fBinaryColor3 x1 ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Bool (<=# x1 15#) of wild4 { False -> case $fBinaryColor3 x1 ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Color x1 of dt1 { DEFAULT -> let { i# :: Int# = word2Int# (uncheckedShiftRL# ww 16#) } in case tagToEnum# @ Bool (leWord# (int2Word# i#) 1114111##) of wild5 { False -> case chr2 i# ret_ty (# Attr, Char# #) of {} True -> (# Attr dt dt1, chr# i# #) } } } } } } } }) -} 8b854d1c31d32d5f70ae60f00eb8d52b $wattrCharFromW32' :: Word# -> (# Attr, Char# #) {- Arity: 1, Strictness: , Inline: [0], Unfolding: (\ (ww :: Word#) -> case $wf 2## 8# of ww1 { DEFAULT -> let { x :: Int# = word2Int# (and# (uncheckedShiftRL# ww 8#) (narrow32Word# (minusWord# ww1 1##))) } in case tagToEnum# @ Bool (>=# x 0#) of wild { False -> case $fBinaryColor3 x ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Bool (<=# x 15#) of wild1 { False -> case $fBinaryColor3 x ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Color x of dt { DEFAULT -> let { x1 :: Int# = word2Int# (and# ww (narrow32Word# (minusWord# ww1 1##))) } in case tagToEnum# @ Bool (>=# x1 0#) of wild2 { False -> case $fBinaryColor3 x1 ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Bool (<=# x1 15#) of wild3 { False -> case $fBinaryColor3 x1 ret_ty (# Attr, Char# #) of {} True -> case tagToEnum# @ Color x1 of dt1 { DEFAULT -> let { i# :: Int# = word2Int# (uncheckedShiftRL# ww 16#) } in case tagToEnum# @ Bool (leWord# (int2Word# i#) 1114111##) of wild4 { False -> case chr2 i# ret_ty (# Attr, Char# #) of {} True -> (# Attr dt dt1, chr# i# #) } } } } } } } }) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 13:50:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 13:50:02 -0000 Subject: [GHC] #12742: Instantiation of invisible type family arguments is too eager Message-ID: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> #12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module looks, to me, like it should be accepted: {{{ {-# LANGUAGE TypeInType, RankNTypes, TypeFamilies #-} module Bug where import Data.Kind type family F :: forall k2. (k1, k2) data T :: (forall k2. (Bool, k2)) -> Type type S = T F }}} But it's not. The problem is that `TcHsType.handle_tyfams` eagerly instantiates ''all'' invisible arguments to a type family at every occurrence. Instead, it should instantiate only those that are counted in the TF's arity -- that is, those "before the colon". Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 14:19:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 14:19:46 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.76f801767fbadbfb95fee361c7847dae@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 goldfire): There isn't a specific spot. An equality between skolems would end up in `TcCanonical.canEqTyVarTyVar` which just builds the equality. Because tyvar equalities are never absolutely insoluble, the skolem case isn't separated out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 14:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 14:44:41 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.f7c2b4cd9447755d6f8866dab3c7f30b@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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 goldfire): Replying to [comment:5 Iceland_jack]: > > The part about **runtime representation** made me wonder if you could define > > {{{#!hs > -- × × × FAILS × × × > data family Array a :: TYPE rep > }}} > > I dunno about the instances, maybe using [https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Proposal3:Allownewtypesoverunliftedtypes Proposal 3: Allow newtypes over unlifted types] While there's nothing very wrong about the data family definition, the instances would be a problem, because we don't yet have a way to make user-written unlifted types. It would indeed be useful to have this, but we don't. So I think this kind of construct is best off waiting until we solve the simpler case of normal unlifted datatypes before we try unlifted data families. > ---- > > {{{#!hs > -- WORKS FINE > data family Array (a :: TYPE rep) :: Type > > -- × × × FAILS × × × > -- > -- Unexpected type ‘Int#’ > data Array Int# > -- Should this fail? > }}} You just want to say `data instance Array Int#`, which indeed works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 16:02:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 16:02:32 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.112e24a1a894ff4e0402c7f23d2b9507@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 carter): Cool! I hope to dig into what's been afoot here at hac phi ! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 17:08:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 17:08:55 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.9f3c3989e91a8e78445b58b31272aef7@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 osa1): @nomeata, how much did the benchmarks improve, exactly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 17:48:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 17:48:44 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.0444c449309430f9dea9c820cf8706bd@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Replying to [comment:32 osa1]: > @nomeata, how much did the benchmarks improve, exactly? See https://perf.haskell.org/ghc/#revision/1c4c64385bbc315deaff203fbebc423ce79f3f93: Weird, the numbers have changed again. 9961 improves by 13%, but 9233 is suddenly missing from the report. Might be a gipeda bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 18:55:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 18:55:41 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.1b4eab8b9692a66a9ad7f98133ea6add@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 osa1): 13% is great. Can Gipeda show residency too? IIRC at some of the perf tests were causing a lot of trouble not because of allocations but because of residency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 19:17:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 19:17:20 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.cfe91c0b2a20753ddaccfaac6ef1d685@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): > Can Gipeda show residency too? It could, but does not now. Isn’t residency far too flaky and dependent on flags? I’m very warily of introducing noise from not very helpful tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 19:22:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 19:22:56 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.44b8070fa3aa659cc241f72dc0103b82@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): I now I remember, I was seeing similar problems in GHC 8 quite a few times and I've just stumbled on another, unrelated one. I have a big local function used only once. When I INLINE the function, I get 3,421,310,504 bytes allocated in the heap (runtime 5.32s, but there is much wider measurement error margin that with allocation), when I NOINLINE it, I get 2,932,616,792 (5.17s) and when I leave it alone (I guess GHC inlines it somehow differently), I get 4,309,699,560 (5.57s). This is with `-O1` and generally nothing special in the .cabal file. Alternating between `-A1m` and -A99m` has almost no effect on total allocation, though it has on GC, which however scales proportionally to the total allocation in each case. (BTW, in a prof the left-alone version wins; the numbers are, respectively: 5,315,881,616 bytes allocated in the heap, 4,916,409,824, 4,738,887,896.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 19:38:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 19:38:09 -0000 Subject: [GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb In-Reply-To: <045.b9ace2f66b6a60a932a378c060eb5914@haskell.org> References: <045.b9ace2f66b6a60a932a378c060eb5914@haskell.org> Message-ID: <060.5e485686fbb39efa4eb23422f1900f05@haskell.org> #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ---------------------------------+---------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11627 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by thomie): You need the profiling libraries. Make sure `BUILD_PROF_LIBS=YES`, for example by setting it in `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 19:45:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 19:45:52 -0000 Subject: [GHC] #12679: Permit abstract data types in signatures that don't have kind * In-Reply-To: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> References: <045.64aae4be1a207d327011ceaa4d3b0ee7@haskell.org> Message-ID: <060.d10377d219c529d72aedd98a03d8bf11@haskell.org> #12679: Permit abstract data types in signatures that don't have kind * -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2595 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"7e77c4b2ee08d7f88df8ba47537640ec1bd70bfe/ghc" 7e77c4b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e77c4b2ee08d7f88df8ba47537640ec1bd70bfe" Support constraint synonym implementations of abstract classes. Summary: Test Plan: validate Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2595 GHC Trac Issues: #12679 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 19:45:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 19:45:52 -0000 Subject: [GHC] #12680: Permit type equality instances in signatures In-Reply-To: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> References: <045.f43e87d0363290d9306073b79ddd03f0@haskell.org> Message-ID: <060.7df66d872d3e63ce8112482ec83c0dc1@haskell.org> #12680: Permit type equality instances in signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack 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 Edward Z. Yang ): In [changeset:"518f28959ec56cf27d6a8096a14a6ce9bc8b9816/ghc" 518f2895/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="518f28959ec56cf27d6a8096a14a6ce9bc8b9816" New story for abstract data types in hsig files. Summary: In the old implementation of hsig files, we directly reused the implementation of abstract data types from hs-boot files. However, this was WRONG. Consider the following program (an abridged version of bkpfail24): {-# LANGUAGE GADTs #-} unit p where signature H1 where data T signature H2 where data T module M where import qualified H1 import qualified H2 f :: H1.T ~ H2.T => a -> b f x = x Prior to this patch, M was accepted, because the type inference engine concluded that H1.T ~ H2.T does not hold (indeed, *presently*, it does not). However, if we subsequently instantiate p with the same module for H1 and H2, H1.T ~ H2.T does hold! Unsound. The key is that abstract types from signatures need to be treated like *skolem variables*, since you can interpret a Backpack unit as a record which is universally quantified over all of its abstract types, as such (with some fake syntax for structural records): p :: forall t1 t2. { f :: t1 ~ t2 => a -> b } p = { f = \x -> x } -- ill-typed Clearly t1 ~ t2 is not solvable inside p, and also clearly it could be true at some point in the future, so we better not treat the lambda expression after f as inaccessible. The fix seems to be simple: do NOT eagerly fail when trying to simplify the given constraints. Instead, treat H1.T ~ H2.T as an irreducible constraint (rather than an insoluble one); this causes GHC to treat f as accessible--now we will typecheck the rest of the function (and correctly fail). Per the OutsideIn(X) paper, it's always sound to fail less when simplifying givens. We do NOT apply this fix to hs-boot files, where abstract data is also guaranteed to be nominally distinct (since it can't be implemented via a reexport or a type synonym.) This is a somewhat unnatural state of affairs (there's no way to really interpret this in Haskell land) but no reason to change behavior. I deleted "representationally distinct abstract data", which is never used anywhere in GHC. In the process of constructing this fix, I also realized our implementation of type synonym matching against abstract data was not sufficiently restrictive. In order for a type synonym T to be well-formed type, it must be a nullary synonym (i.e., type T :: * -> *, not type T a = ...). Furthermore, since we use abstract data when defining instances, they must not have any type family applications. More details in #12680. This probably deserves some sort of short paper report. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 21:44:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 21:44:24 -0000 Subject: [GHC] #12741: --numa doesn't work even if libnuma is available In-Reply-To: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> References: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> Message-ID: <061.86eb6e4e14d9aca6f877ccc9cd33f124@haskell.org> #12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: D2620 => Phab:D2620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 22:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 22:01:16 -0000 Subject: [GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified In-Reply-To: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> References: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> Message-ID: <060.63c0e0a4fc44ebd72d20f8d482be694e@haskell.org> #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.3 Resolution: | Keywords: | ffi,registers,sse2,clobber,xmm Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | https://github.com/bavis-m/raycast Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bavism): Replying to [comment:1 carter]: > Reading the doc > {{{ > XMM6:XMM15, YMM6:YMM15 > Nonvolatile (XMM), Volatile (upper half of YMM) > Must be preserved as needed by callee. YMM registers must be preserved as needed by caller. > > }}} > > It looks like if you have the callee clobber ymm6-16 you can get the caller to handle the save / restore > Alternatively, a simple wrapper around the Haskell functions could explicitly read xmm6-16 before entering the Haskell call and set the values after return. So that should at least fix it with a simple read call and set sequence on the c side > > That said, sounds like this indeed a bug, though the xmm vs ymm caller vs callee stuff is kinda gross and definitely a bug in the wrappers/stubs generated for the windows platform. > > Please share if the near term work around helps. I realize it adds an extra indirection in the Haskell call, but probably simplest way to fix it this week? Turns out this was much more difficult than I initially anticipated, as MSVC does not allow inline assembly in x64 projects :(. I have pushed up a workaround to a new branch in that project, {{{fixasm}}}, that directs Visual Studio to build a new file, stub.asm, which exposes a stub function for calling a Haskell function pointer. The stub function saves XMM6-XMM15. This causes the Haskell function to not clobber the registers, and everything works correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 20 23:53:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 20 Oct 2016 23:53:15 -0000 Subject: [GHC] #12743: Profiling wrongly attributes allocations to a function with Int# result Message-ID: <054.1923e0d95768e23aa19ab4d1277adb39@haskell.org> #12743: Profiling wrongly attributes allocations to a function with Int# result -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Profiling can't decide whether the given function allocates or not at all. The code snippet says it all: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts -- ghc -prof --make bork.hs -fprof-auto -O1 -- ./bork +RTS -s -P -RTS main = do let f :: Int -> Int# -- {-# NOINLINE f #-} f x = case x `div` 17 of I# i -> i -- {-# NOINLINE g #-} g h = sum $ map (\y -> I# (h y)) [0..1000000] g f `seq` return () -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 73.6 93.3 159 224000328 -- main.f Main 24.1 6.7 52 16000016 -- main.g.\ Main 2.3 0.0 5 0 -- When either of the NOINLINE is enabled, the profile becomes: -- COST CENTRE MODULE %time %alloc ticks bytes -- main.g Main 72.9 93.3 161 224000328 -- main.f Main 16.7 0.0 37 0 -- main.g.\ Main 10.4 6.7 23 16000016 -- So, does f actually allocate or not? -- Profiling is quite a bit less useful if it can't answer that reliably, -- because in larger code snippets it's hard to decide from source -- or from Core/STG. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 00:18:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 00:18:37 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.1a497b30541d84139842c58df6a61b0d@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 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 Iceland_jack): Replying to [comment:6 goldfire]: > So I think this kind of construct is best off waiting until we solve the simpler case of normal unlifted datatypes before we try unlifted data families. Awesome! Maybe you can combine them into fixed point that is rep-poly ;) > You just want to say `data instance Array Int#`, which indeed works fine. Haha oops. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 00:33:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 00:33:04 -0000 Subject: [GHC] #12744: Register Allocator Unit Tests Message-ID: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> #12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the backend only has end-to-end tests and I think it would benefit from some unit tests starting with (for no special reason) the register allocator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 00:35:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 00:35:06 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats Message-ID: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12744 Differential Rev(s): Phab:D2621 | Wiki Page: -------------------------------------+------------------------------------- I'm trying to write a unit test for the graph coloring register allocator and to start I'm trying to write a function (mostly modeled on hscCompileCmmFile and cmmNativeGen) that will compile a cmm file and return register allocation stats (that can then be asserted against). It should be less cumbersome to use than cmmNativeGen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 00:36:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 00:36:54 -0000 Subject: [GHC] #12744: Register Allocator Unit Tests In-Reply-To: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> References: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> Message-ID: <061.3aca3504580d7b1600861dd1991fd768@haskell.org> #12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * related: => #12745 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 03:02:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 03:02:06 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) Message-ID: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Affected versions: ghc 8.0.1 and ghc git master as of 21 Oct 2016 (c23dc61) It compiles fine on first time but fails to compile on second attempt. Using -fforce-recomp recompiles both files and bug is not triggered. {{{ % ls A.hs B.hs % cat A.hs }}} {{{#!hs module A where import B foo a = case a of Foo -> True _ -> False }}} {{{ % cat B.hs }}} {{{#!hs {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} module B where pattern Foo = 0x00000001 :: Int }}} {{{ % ghc -O2 A.hs ; touch A.hs ; ghc -O2 A.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/iface/BuildTyCl.hs:195:404 in ghc:BuildTyCl [] ~ [] [] ~ [] Int ~ Int [] ~ [] [] ~ [] [] ~ [Void#] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 03:55:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 03:55:31 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.213279ff0ff3d626683dca58404f2d34@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I couldn't reproduce this with the released GHC 8.0.1. Do you think it only happens with devel2 builds? Any idea why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 03:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 03:59:08 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.4b2a507ef92a2b5712f90fbaa62acc37@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): I suspect that some assertions are not enabled outside of devel2 builds. I'm trying to make a devel2 build because there is a random compilation failure in our codebase which I can't reproduce at the moment but when compiling one of the prerequisites I'm getting this assert failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 03:59:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 03:59:52 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.1fd736342d815d2046a0ec3dc078bfc7@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high Comment: Aha, that makes sense. This seems mildly alarming... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 04:58:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 04:58:42 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.f7a583ff94f3c2a32f05f9231234432b@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 08:03:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 08:03:25 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.34d1207f9a4eb8b6a13cd88b436126be@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): > When I INLINE the function, I get 3,421,310,504 bytes allocated in the heap (runtime 5.32s, but there is much wider measurement error margin that with allocation), when I NOINLINE it, I get 2,932,616,792 (5.17s) and when I leave it alone (I guess GHC inlines it somehow differently), I get 4,309,699,560 (5.57s). This isn't necessarily surprising. Consider {{{ module M( f, g, h ) where f x = BIG g x = (f x, True) h x = ...(g x)... }}} Without an INLINE on `f`, GHC won't inline it (because it's big). But `g` is small, so it'll get inlined into `h`, and good things may happen because `h` can see the pair and `True`. But if you add an `INLINE` pragma to `f`, then `g` becomes big, so GHC won't inline it. These effects can be large, and are very hard to predict. GHC makes no guarantees, I'm afraid. It's a bit more puzzling that you say your big function is called only once; so it might come down to a race as to whether `f` gets auto-inlined before `g` does. That's a bit mysterious I admit. However a difference between 2.9G and 4.3G is very large, and it would be great to get more insight into why. I use `-ticky` to investigate this kind of thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 08:08:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 08:08:54 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.85534a3934d641dfcda19151f80bfa53@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): > I've compared the resulting Core. The difference is that the version with INLINE recomputes `((2 ^ (8 :: Int) - 1)` every time, while the manually inlined version uses a value computed just once. Here's how that could happen: {{{ f x y = (expensive x) + y g x ys = map (f x) ys }}} Executed as-is each call to `(f x yi)` will evaluate `(expensive x)` afresh. In this particular example it'd be better if GHC transformed to {{{ f x = let v = expensive x in \y -> v + y }}} but GHC's full laziness transformation never separates adjacent lambdas. (Doing so can be very bad in other ways.) But if you INLINE f we get {{{ g x ys = map (\y -> expensive x + y) ys }}} and now full laziness ''can'' float `(expensive x)` outwards. To make your program robust, I'd write `f` with the local let-binding as I do above. Then it shouldn't repeatedly evaluate `(expensive x)` regardless of optimisation or inlining. I'm guessing a bit of course. It could just be a bug. I'm really swamped right now, but maybe I've given you enough to investigate further. If you think it's a bug, it'd be really helpful to boil out a smaller example with full repro instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 08:16:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 08:16:14 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.3f0e9de9d120e438184a3e97a6030132@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 09:00:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 09:00:27 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.40fbf8948c50acc64821150c106a2256@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * owner: => tjakway -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 09:00:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 09:00:37 -0000 Subject: [GHC] #12744: Register Allocator Unit Tests In-Reply-To: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> References: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> Message-ID: <061.366ef74dcf4ef44978d3c5df63165b86@haskell.org> #12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * owner: => tjakway -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 11:25:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 11:25:56 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better Message-ID: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- INLINE vs NOINLE vs for this function https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client/UI/DrawM.hs#L145 produces distinct figures in all three cases. See https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be , and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 11:26:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 11:26:34 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.858f181d2d1c7758b7246b15b2d5bbc7@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): Replying to [comment:8 simonpj]: > > When I INLINE[...], when I NOINLINE it [...] and when I leave it alone [... > > This isn't necessarily surprising. Consider [...] Thank you for the example. I've fixed the inlining status of all enclosing or competing functions in the module, but the strange behaviour persists. Now I suspect the complaints I have may not be related after all: 1. not floating out constants with INLINE as opposed to identical manual inlining; 2. erratic/unpredictable/surprising/buggy behaviour of INLINE vs NOINLINE vs 3. three different figures for these, instead of two. I've just opened a feature request ticket for 3: https://ghc.haskell.org/trac/ghc/ticket/12747#ticket. This comment is about 2. If I find a smaller or simpler example for 2 and it's still as surprising, I will open a new bug report for it. As you point out, it's possible that 2 is not a bug, but just an exemplification of GHC being smarter than either us. > But if you add an `INLINE` pragma to `f`, then `g` becomes big, so GHC won't inline it. [...] > These effects can be large, and are very hard to predict. GHC makes no guarantees, I'm afraid. The guarantee that would help greatly would be that the behaviour of the program with neither INLINE nor NOINLINE for function `f` is the same as the behaviour with INLINE or that with NOINLINE. It would help tremendously with profiling experiments, because then I could fix the state of inlining of `f` and tune `g` and `h` without worry that inlining of `f` changes silently. But if `f` has the lowest allocation only without any pragmas at all, I can't fix it. See the feature request. > It's a bit more puzzling that you say your big function is called only once I meant syntactically (even taking into account inlining of any other functions). But it's called inside a loop. It's referenced exactly once and fully applied, here: https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client/UI/DrawM.hs#L273 > However a difference between 2.9G and 4.3G is very large, and it would be great to get more insight into why. I use `-ticky` to investigate this kind of thing. Thank you for the tips. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 11:34:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 11:34:06 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi Message-ID: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> #12748: BFD linker issue with GHCi ------------------------------------------+------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Linking) | Version: 8.0.1 Keywords: bfd,linker,ghci | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+------------------------------- On my project, GHCi seems to hang waiting for the BFD linker to complete the link of `libghc_1.so`. The hanging command has the form: `/usr/bin/ld @/tmp/ccHQ8Uzc` Using gdb, it seems the BFD linker `ld` is looping (infinitely?) into `bfd_elf_link_add_symbols`. I have tried to use the GOLD linker `ld.gold` instead on the `ccHQ8Uzc` file (removing the unsupported parameters `--hash-size=31` and `--reduce- memory-overhead`) and it links instantly. Could it be that GHC 8.0.1 generates too many symbols for the BFD linker or something like this? The BFD linker worked with GHC 7.10.3. I build the project with stack, the hanging happens with `stack repl` (GHCi's prompt never shows): {{{ @(Stack/Exec.hs:76:10) 2016-10-21 12:57:53.747332: [debug] Creating process: /usr/bin/ghc --interactive -i -odir=/home/hsyl20/travail/code/ViperVM/.stack-work/odir -hidir=/home/hsyl20/travail/code/ViperVM/.stack-work/odir -hide-all- packages -i/home/hsyl20/travail/code/ViperVM/src/lib -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -stubdir=/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build /home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/src/lib/ViperVM/Arch/X86_64/Linux/syscall.o /home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/src/lib/ViperVM/Arch/X86_64/cpuid.o -package-id=base-4.9.0.0 -package-id=containers-0.5.7.1 -package- id=list-t-1-z6InD0gw7C2QDNkG2mqUf -package- id=stm-2.4.4.1-9HlGYelGmT69YkepeDjuRg -package-id=stm- containers-0.2.15-JTVESCf1d8uCXyJbMCLfQJ -package-id=stm- linkedlist-0.1.0.0-GCpyrfjLFyWFZy8qotX7VW -package- id=hashable-1.2.4.0-GnltDttmBjG9qGzcjuPOH4 -package- id=cereal-0.5.3.0-JHJQkHEuvBGFx8XwIB7eX0 -package-id=bytestring-0.10.8.1 -package-id=system-fileio-0.3.16.3-EDef2a4Ximk1z04PLLp95q -package-id =system-filepath-0.4.13.4-24DUGoIUqZu3MxGDhYLfCN -package- id=pureMD5-2.1.3-HBUMOqRjfoe6ZpLefZBT34 -package- id=text-1.2.2.1-FgcR4Xf0VlEHD9HLxzq9WJ -package-id=filepath-1.4.1.0 -package-id=either-4.4.1.1-H4kagIugHGeIf0psi4Z0to -package- id=vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6 -package-id=directory-1.2.6.2 -package-id=megaparsec-5.0.1-25EMPYC0AB61WKE0MffPOR -package- id=transformers-0.5.2.0 -package-id=unix-2.7.2.0 -package- id=criterion-1.1.1.0-Hq6Gg6oBMXcJvBdkiC2CBq -package-id=c-storable- deriving-0.1.3-DIL5UpBe3Em7XwOYU01lXH -package- id=pqueue-1.3.1.1-A3EjwMk8dUf7l1Swzqrred -package- id=mtl-2.2.1-6qsR1PHUy5lL47Hpoa4jCM -package-id=template-haskell-2.11.0.0 -package-id=text-format-0.3.1.1-IMczxQgUdKA8it9OEumLMx -package- id=diagrams-1.3.0.1-9gEbAUMmu7DEIEOtgBTN65 -package-id=diagrams- lib-1.3.1.4-EWFz1jRqz29KScpInBNJM4 -package-id=diagrams- core-1.3.0.8-GGXo5v7JBpPFzOrVLJC9nc -package-id=diagrams- rasterific-1.3.1.8-2NQiYfE0qFP7UFNV120Viv -package- id=JuicyPixels-3.2.8-GcqBxM3ZIJ83rYx9ygJ0bm -package- id=loop-0.3.0-98VH1UqsOHy2KxBxA55ICY -package- id=Rasterific-0.6.1.1-3xSOfexAru5AQFIj4yXZ8f -package- id=colour-2.3.3-1clKnMqHWhQAElTFd8Ydyp -package-id=file- embed-0.0.10-IXfudWSq57y1Athysk5ifZ -i/home/hsyl20/travail/code/ViperVM/src/apps -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Disass/Disass-tmp -i/home/hsyl20/travail/code/ViperVM/src/apps/Elf -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ElfWeb/ElfWeb-tmp -package-id =happstack-server-7.4.6.2-8UX7Pc8fxznJjPPJjgBwca -package- id=lucid-2.9.6-FZpI2dlNE9n8QXjEeTfhJW -package-id=optparse- applicative-0.12.1.0-4FckWvtE7Gp1EYdm7OVbJw -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/MemoryTest/MemoryTest-tmp -i/home/hsyl20/travail/code/ViperVM/src/apps/PlatformWeb -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/PlatformWeb/PlatformWeb-tmp -package-id=blaze-html-0.8.1.2-2ceCZ3Fm7x67ZwaaR7uQ3C -package-id=blaze- markup-0.7.1.0-BKRb0wHFpEyDJWTsyjQqnp -package- id=network-2.6.3.1-G4Up1CPKbp7DeFsnywOnGG -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/TestSyscalls/TestSyscalls-tmp -i/home/hsyl20/travail/code/ViperVM/src/apps/X86Web -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/X86Web/X86Web-tmp -package- id=HTTP-4000.3.3-Fl4VtSZsPE4A3kSlCM2M0U -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/gunzip/gunzip-tmp -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/huffman/huffman-tmp -i/home/hsyl20/travail/code/ViperVM/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/udev/udev-tmp -i/home/hsyl20/travail/code/dynamic-linker-template -i/home/hsyl20/travail/code/dynamic-linker-template/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen -i/home/hsyl20/travail/code/dynamic-linker-template/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -stubdir=/home/hsyl20/travail/code/dynamic-linker-template/.stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build -Wall -Wall -Wall -Wall -Wall -Wall -Wall -Wall -Wall -Wall -Wall -optP-include -optP/tmp/ghci13379/cabal_macros.h -ghci-script=/tmp/ghci13379/ghci-script @(System/Process/Run.hs:103:5) GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help }}} This is on ArchLinux, binutils-2.27, stack 1.2.0, GHC 8.0.1. Steps to reproduce (I don't have a smaller reproducing example for now): {{{ git clone https://github.com/hsyl20/ViperVM cd ViperVM stack repl # wait... the compilation is quite long # press enter when stack asks for the main module to load }}} `stack build` doesn't trigger this linker issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 11:35:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 11:35:53 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.42a6369cf59fcf77f3e92f69c9f3c51c@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 MikolajKonarski): Actually, a weaker guarantee would still be very useful and may be preferable: the above for functions that are referred to only once and, generalizing, for functions that may be inlined in many places, let be equivalent to INLINABLE and a certain set of `inline` and `noinline` at each occurrence of the function. Right now this weaker condition doesn't hold, because the function from the test is referred to only once (taking into account any other inlining). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 12:06:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 12:06:30 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.5364ae84ef7aeed3d574617970683086@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): > The guarantee that would help greatly would be that the behaviour of the program with neither INLINE nor NOINLINE for function f is the same as the behaviour with INLINE or that with NOINLINE. I think that's very problematic. Currently GHC decides on a call-site-by- call-site basis whether to inline a given function. See module `CoreUnfold` and in particular `callSiteInline`. You could change it to do something different but I believe that'd make GHC generate either bigger code or slower code or both. But do try! INLINE/NOINLINE let you take control; otherwise you are letting GHC decide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 12:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 12:45:32 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.65e1f3311261c9c67ce38a19c00b65cf@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): > I think that's very problematic. Currently GHC decides on a call-site- by-call-site basis whether to inline a given function.[...] When there is only one call site, IMHO it's reasonable that the outcome should be reproducible with either INLINE or NOINLINE (and it is not currently, see above). > INLINE/NOINLINE let you take control; otherwise you are letting GHC decide. I'm all for letting GHC outsmart me, but I'd like to be able to then fix the result GHC came up with and tweak it further or tweak other bits of code, keeping this part constant, or stick to it in order to debug my program with slightly varying other portions of code or easily come up with a minimized example for a GHC bug, without GHC sneakily intefering. Currently I can't. Let's move the discussion to ​https://ghc.haskell.org/trac/ghc/ticket/12747#ticket where I also suggest that INLINABLE+inline+noinline should let the programmer reproduce GHC choices in the multi-call-site case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 12:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 12:52:22 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.396d4d44a28bb1a704e5bebebdf4af29@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -3,1 +3,1 @@ - https://github.com/LambdaHack/LambdaHack/blob/master/Game/LambdaHack/Client/UI/DrawM.hs#L145 + https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145 New description: INLINE vs NOINLE vs for this function https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145 produces distinct figures in all three cases. See https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be , and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:17:17 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.41f7afe55da40f473aaf063e26bb2ef0@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): That's strange – maybe we're using some strange pattern, but our team is getting this error very often recently and we're using hacks to make it working just by expanding variables to full types. In this case I'll raise the priority of this bug. If anyone don't agree, feel free to lower it – it just slows down our workflow much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:17:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:17:30 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.52cd00ebd72b77ca18ed391295ca69da@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:23:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:23:28 -0000 Subject: [GHC] #12734: Unexpected context reduction stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.dd92e8e0df952269f0d9df2779e87a3f@haskell.org> #12734: Unexpected context reduction stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: highest => high Comment: @danilo2 Could one of your team perhaps investigate this problem further? If you want it to be quickly fixed then an analysis of what is going on would be very helpful. I don't think this should be marked as highest priority as that is usually reserved for released blocking bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:45:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:45:42 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.057f109651e436af8f8e8df603f15d52@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be great if someone had time to really look at this. I think gkaracha has probably now moved on; is that true George? It's not just a question of making a one-line fix; you'd have to dig into the algorithm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:47:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:47:33 -0000 Subject: [GHC] #12749: Typechecker regression involving RankNTypes Message-ID: <050.ba26f8465d511f962d827ef210be9368@haskell.org> #12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles on GHC 7.0.4 through 7.10.3, but not with GHC 8.0.1, 8.0.2, or HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where type NatTrans f g = forall x. f x -> g x -- NatTrans analog of id applyNT :: NatTrans f g -> NatTrans f g applyNT x = x b :: Bool b = True eitherToMaybe :: NatTrans (Either a) Maybe eitherToMaybe (Left _) = Nothing eitherToMaybe (Right x) = Just x trans :: NatTrans (Either a) Maybe -> NatTrans (Either a) Maybe trans x = x applyNTCheck :: NatTrans (Either a) Maybe applyNTCheck = (if b then trans else applyNT) eitherToMaybe }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:21:27: error: • Couldn't match type ‘NatTrans (Either a) Maybe’ with ‘Either a0 x0 -> Maybe x0’ Expected type: (Either a0 x0 -> Maybe x0) -> Either a x -> Maybe x Actual type: NatTrans (Either a) Maybe -> Either a x -> Maybe x • In the expression: trans In the expression: if b then trans else applyNT In the expression: (if b then trans else applyNT) eitherToMaybe • Relevant bindings include applyNTCheck :: Either a x -> Maybe x (bound at Bug.hs:21:1) }}} (Originally spotted [https://github.com/ku-fpg/natural- transformation/pull/13#issuecomment-255378141 here].) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:53:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:53:23 -0000 Subject: [GHC] #12750: hGetContents leads to late/silent failures Message-ID: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> #12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: | Owner: massimo.zaniboni | Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error| Blocking: | Related Tickets: #9236 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the same problem described in the closed ticket #9236 This is a test-case https://github.com/massimo- zaniboni/ghc_lazy_file_content_error I tried with ghc 7.10.3 and 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:54:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:54:27 -0000 Subject: [GHC] #12749: Typechecker regression involving RankNTypes In-Reply-To: <050.ba26f8465d511f962d827ef210be9368@haskell.org> References: <050.ba26f8465d511f962d827ef210be9368@haskell.org> Message-ID: <065.ac0390112b08963a7d59941390d8287b@haskell.org> #12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): I wonder how and "Getting rid of -XImpredicativeTypes" https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html comments are related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 13:58:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 13:58:26 -0000 Subject: [GHC] #12750: hGetContents leads to late/silent failures In-Reply-To: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> References: <055.02b0ce27a4ad95b6dc1329386bb592bb@haskell.org> Message-ID: <070.b15016434c1fa4606b2e5e0d50214b2b@haskell.org> #12750: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: massimo.zaniboni | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | https://github.com/massimo- | zaniboni/ghc_lazy_file_content_error Blocked By: | Blocking: Related Tickets: #9236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by massimo.zaniboni): Probably it is better if (when I have time) I insert the test-case inside the testsuites of GHC, and not as an external repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:30:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:30:19 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.c5430eb564ac02a3c9e2191a66f1fbbc@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): Phew, you goaded me into spending some extra time and using some extra pragmas, I managed to concoct a tiny example that reproduces the original problem (many times slower with INLINE vs manual inlining that exactly mimics the supposed GHC behaviour; allocation the same). I haven't checked, but most probably in the INLINE version, the constants are not floated out, just as in the Core of the original problem show above. {{{ import Data.Bits (unsafeShiftR, (.&.)) import Data.Word (Word32) -- ghc --make Main.hs -O1; ./Main +RTS -s -RTS seqFrame2 :: [AttrW32] -> IO () {-# NOINLINE seqFrame2 #-} seqFrame2 l = do let crux = attrCharFromW32 -- Total time 2.052s ( 2.072s elapsed) -- let crux = attrCharFromW32' -- Total time 7.896s ( 7.929s elapsed) mapM_ (\a -> crux a `seq` return ()) l main :: IO () main = seqFrame2 $ replicate 100000000 $ AttrW32 0 data Attr = Attr !Int !Int --- bangs here are essential newtype AttrW32 = AttrW32 {attrW32 :: Word32} attrCharFromW32 :: AttrW32 -> Attr {-# NOINLINE attrCharFromW32 #-} attrCharFromW32 w = Attr (fromEnum $ unsafeShiftR (attrW32 w) 8 .&. (2 ^ (8 :: Int) - 1)) (fromEnum $ attrW32 w .&. (2 ^ (8 :: Int) - 1)) fgFromW32 :: AttrW32 -> Int {-# INLINE fgFromW32 #-} fgFromW32 w = fromEnum $ unsafeShiftR (attrW32 w) 8 .&. (2 ^ (8 :: Int) - 1) bgFromW32 :: AttrW32 -> Int {-# INLINE bgFromW32 #-} bgFromW32 w = fromEnum $ attrW32 w .&. (2 ^ (8 :: Int) - 1) attrCharFromW32' :: AttrW32 -> Attr {-# NOINLINE attrCharFromW32' #-} attrCharFromW32' w = Attr (fgFromW32 w) (bgFromW32 w) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:40:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:40:13 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.a6e75378e86f65b851ef681344783e98@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): Terrific, thanks. So what change do I make to the source code to exhibit the change in perf? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:44:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:44:46 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.e83ea07d53e24f1f80b6e7f5eceda96d@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): It seems that the loop in the linker is not infinite but that it will take a long time. Here are the linked packages and the time to link up to some packages (from the bottom up): {{{ ----- HTTP-4000.3.3-Fl4VtSZsPE4A3kSlCM2M0U-ghc8.0.1 ----- lucid-2.9.6-FZpI2dlNE9n8QXjEeTfhJW-ghc8.0.1 ----- happstack-server-7.4.6.2-8UX7Pc8fxznJjPPJjgBwca-ghc8.0.1 ----- xhtml-3000.2.1-ghc8.0.1 ----- utf8-string-1.0.1.1-2T8mBCuEDlXDo8zed8Onw4-ghc8.0.1 ----- time-compat-0.1.0.3-3baQeqpui17BDAvomZYiih-ghc8.0.1 ----- threads-0.5.1.4-KS41fYDpDlm1BvjwZbbSK6-ghc8.0.1 ----- sendfile-0.7.9-3VAtD7YE7bbEbbTKNhrN1c-ghc8.0.1 ----- network-uri-2.6.1.0-8yR4gjnzE4eDGhJR7PHfVJ-ghc8.0.1 ----- html-1.0.1.2-Jj2JgpzqaYBEsxjiTkT0Vw-ghc8.0.1 ----- hslogger-1.2.10-6Ih3VN3QBbAJ6pLH6h3KNu-ghc8.0.1 > 2128s network-2.6.3.1-G4Up1CPKbp7DeFsnywOnGG-ghc8.0.1 ----- extensible-exceptions-0.1.1.4-3h0ykvvAO915cRhUyj3rRV-ghc8.0.1 ----- blaze-html-0.8.1.2-2ceCZ3Fm7x67ZwaaR7uQ3C-ghc8.0.1 ----- blaze-markup-0.7.1.0-BKRb0wHFpEyDJWTsyjQqnp-ghc8.0.1 ----- file-embed-0.0.10-IXfudWSq57y1Athysk5ifZ-ghc8.0.1 ----- loop-0.3.0-98VH1UqsOHy2KxBxA55ICY-ghc8.0.1 ----- diagrams-svg-1.4.0.3-FphjbXW7TZSAwXXOYkXY74-ghc8.0.1 ----- svg-builder-0.1.0.1-CvxGiuGBpW3JJl8eWFlgQU-ghc8.0.1 ----- old-time-1.1.0.3-IcvdkJUsE9M8t3io8peAEp-ghc8.0.1 ----- base64-bytestring-1.0.0.1-In9M41tLtcS9QYt3QpGpNY-ghc8.0.1 ----- diagrams-rasterific-1.3.1.8-2NQiYfE0qFP7UFNV120Viv-ghc8.0.1 ----- Rasterific-0.6.1.1-3xSOfexAru5AQFIj4yXZ8f-ghc8.0.1 ----- FontyFruity-0.5.3.2-1YzwX3JO76u7ntpUxhGpcT-ghc8.0.1 ----- xml-1.3.14-rYbwgRBahsKh5Xn1LyTeP-ghc8.0.1 495,13s diagrams-contrib-1.3.0.12-BVQVFc3zAIebigwBRjBcg-ghc8.0.1 ----- split-0.2.3.1-IJKK4pOCYGKud0jZImZke-ghc8.0.1 ----- force-layout-0.4.0.5-CkQAJNRWbYI3c8zBWjDsz7-ghc8.0.1 289,77s diagrams-lib-1.3.1.4-EWFz1jRqz29KScpInBNJM4-ghc8.0.1 ----- intervals-0.7.2-7abOKU77U9GirBl7dVRy8-ghc8.0.1 ----- fsnotify-0.2.1-LnY2OginHk88niUbIC7bDm-ghc8.0.1 ----- unix-compat-0.4.2.0-GNHotEMWE5dJ4oYFhgibIV-ghc8.0.1 ----- hinotify-0.3.8.1-Gq67SHpnhelljPBDnXAk3-ghc8.0.1 ----- async-2.1.0-IGx6TJY2BPOHCk3x4WAuIK-ghc8.0.1 ----- fingertree-0.1.1.0-C6YFXKIQXOA6HvmvFT5gT9-ghc8.0.1 ----- diagrams-solve-0.1.0.1-8TpiRrVfWtp4FIaKLscasl-ghc8.0.1 ----- active-0.2.0.10-ET7kEDhlbPi7zo4qIXMEd6-ghc8.0.1 78,53s JuicyPixels-3.2.8-GcqBxM3ZIJ83rYx9ygJ0bm-ghc8.0.1 ----- zlib-0.6.1.1-IKN2DpYEe8r3bYFvs7BDUW-ghc8.0.1 63,90s diagrams-core-1.3.0.8-GGXo5v7JBpPFzOrVLJC9nc-ghc8.0.1 48,34s linear-1.20.5-LFB054YYRYQCVL3hUFEZct-ghc8.0.1 ----- bytes-0.15.2-EQMQclPImIpKkG0m1f3ql5-ghc8.0.1 ----- lens-4.14-2LZrGLWR827Eaze7Qa59gb-ghc8.0.1 ----- reflection-2.1.2-J1ZzlxijzaHGRixYxgxlf9-ghc8.0.1 ----- kan-extensions-5.0.1-JxnJF79ehCQ1iWfDSDGjll-ghc8.0.1 ----- dual-tree-0.2.0.9-J1URg6eEwyVm9LEtYsrpQ-ghc8.0.1 33,69s newtype-0.2-6DnlyeREupYF8x0b7VMCgm-ghc8.0.1 ----- monoid-extras-0.4.2-D4VPpDMGnd9Hf6LE8J7Aiv-ghc8.0.1 ----- groups-0.4.0.0-53wMJ09LBR64aEJqWveBMG-ghc8.0.1 ----- adjunctions-4.3-DdaVzHtQIdKKcIMAtenkpN-ghc8.0.1 ----- data-default-0.7.1.1-ZpKfkXGfJa8c8Q6OFbvrr-ghc8.0.1 ----- data-default-instances-old-locale-0.0.1-5zxcPmpqjG6FhGl1vmzEjZ- ghc8.0.1 ----- data-default-instances-dlist-0.0.1-DV8IBZIcilKKBwjHagMU7-ghc8.0.1 ----- data-default-instances- containers-0.0.1-6YgqkE3UWFzLQIGXZZRkO7-ghc8.0.1 ----- data-default-class-0.1.2.0-6eetmQ6CbQOLoXb6k5kODu-ghc8.0.1 23,34s colour-2.3.3-1clKnMqHWhQAElTFd8Ydyp-ghc8.0.1 ----- circle-packing-0.1.0.5-KgymD5nt1dV2mqSNFjQ9xq-ghc8.0.1 ----- text-format-0.3.1.1-IMczxQgUdKA8it9OEumLMx-ghc8.0.1 22,29s old-locale-1.0.0.7-6glXNhHF891B41ZfuI8hU8-ghc8.0.1 ----- double-conversion-2.0.1.0-Ep4L30s0FWQLbRRekNTc0u-ghc8.0.1 ----- pqueue-1.3.1.1-A3EjwMk8dUf7l1Swzqrred-ghc8.0.1 ----- c-storable-deriving-0.1.3-DIL5UpBe3Em7XwOYU01lXH-ghc8.0.1 ----- criterion-1.1.1.0-Hq6Gg6oBMXcJvBdkiC2CBq-ghc8.0.1 ----- statistics-0.13.3.0-KJVgU6t2auG33XIktKXx0i-ghc8.0.1 ----- vector-binary-instances-0.2.3.2-5646KxzN3hJ80s4tOK0y7f-ghc8.0.1 ----- vector-algorithms-0.7.0.1-7hkZdPzlc60Fe3nqzzgmcD-ghc8.0.1 15,29s monad-par-0.3.4.8-K7CIv8BXjrxuiIj0uUi92-ghc8.0.1 ----- parallel-3.2.1.0-6VcN0yUHtcs831TgbJiSSi-ghc8.0.1 ----- monad-par-extras-0.3.3-4NSJC48GnVF68j1ZuIgmiE-ghc8.0.1 ----- abstract-par-0.3.3-I2gvKCBAweu3uYwWNazPJ0-ghc8.0.1 ----- abstract-deque-0.3-7e2WwN8ZV7qFTjGkaUX2qO-ghc8.0.1 ----- math-functions-0.2.0.2-IKucf2F6PPp7GCACitUv0c-ghc8.0.1 ----- vector-th-unbox-0.2.1.6-GMTpzttBvqGAEXamQ10jEK-ghc8.0.1 ----- erf-2.0.0.0-9HTdBV7htNjASgIJAT55AC-ghc8.0.1 ----- parsec-3.1.11-IYEP8Lv1S9x5FeUQxGPDBY-ghc8.0.1 ----- optparse-applicative-0.12.1.0-4FckWvtE7Gp1EYdm7OVbJw-ghc8.0.1 11,56s process-1.4.2.0-ghc8.0.1 ----- mwc-random-0.13.4.0-CH6ozsPFZjwVSNwmEz44J-ghc8.0.1 ----- hastache-0.6.1-FvV3RixlMRQIqgysVmReXH-ghc8.0.1 ----- ieee754-0.7.8-hSToga77ICuzAtDrK6Dj-ghc8.0.1 ----- cassava-0.4.5.0-LCutYytXWri1WnJj44KTfC-ghc8.0.1 10,37s blaze-builder-0.4.0.2-2VmGHau0mFrAjwd4n28WWF-ghc8.0.1 ----- ansi-wl-pprint-0.6.7.3-BxXaXM4de7bF6SGXMvMtbC-ghc8.0.1 ----- ansi-terminal-0.6.2.3-AKTYR0nthhUCHW4HMZvJFX-ghc8.0.1 ----- aeson-0.11.2.1-3PFLXPeWBg946S5O4IgJJV-ghc8.0.1 ----- unordered-containers-0.2.7.1-6Q3w38ZivLTB9nLFgf8RUI-ghc8.0.1 ----- syb-0.6-C65vWCsht6A8uLstpQIXyj-ghc8.0.1 ----- attoparsec-0.13.1.0-8poMzD5ooNXJ4NDLaelDWq-ghc8.0.1 ----- Glob-0.7.12-6ONSkI0W8EPI2F7ftZDeCU-ghc8.0.1 ----- dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv-ghc8.0.1 ----- megaparsec-5.0.1-25EMPYC0AB61WKE0MffPOR-ghc8.0.1 ----- scientific-0.3.4.9-Ghl8M4Ey2fMI7e1yk2TuuH-ghc8.0.1 3,02s directory-1.2.6.2-ghc8.0.1 ----- vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6-ghc8.0.1 ----- either-4.4.1.1-H4kagIugHGeIf0psi4Z0to-ghc8.0.1 ----- free-4.12.4-LcxMyZIxIoo6h2gqXah9QK-ghc8.0.1 ----- semigroupoids-5.1-5WI5yrkqR6b5vppUpisNlN-ghc8.0.1 ----- profunctors-5.2-CUL7kUu4nBbDVNmgOaH64k-ghc8.0.1 ----- prelude-extras-0.4.0.3-FAyB4iuuM7cHXdrLMZtdXq-ghc8.0.1 0,51s exceptions-0.8.3-5cAKIsqc1DD7jaNW3zLxAN-ghc8.0.1 ----- bifunctors-5.4.1-EBkHk3WI7L87dRJGvKP176-ghc8.0.1 ----- comonad-5-1roHbXsedY6KUNYFgPJLp6-ghc8.0.1 ----- distributive-0.5.0.2-2AokE99FpE59iSGkvIRYC4-ghc8.0.1 ----- contravariant-1.4-89BvpwBnlCJ6iFzBGVF7XO-ghc8.0.1 ----- void-0.7.1-BXitqvas4xpGkaFQbixoM1-ghc8.0.1 ----- semigroups-0.18.2-2lmUSJvrDkM6JBURGRclWz-ghc8.0.1 ----- StateVar-1.1.0.4-49DJlv5H4c7r7bJPDG6IK-ghc8.0.1 0,26s base-orphans-0.5.4-5IQvrjd7gNP548VkOOyIq6-ghc8.0.1 ----- MonadRandom-0.4.2.3-8TfCm6PGvGYB7omozORhov-ghc8.0.1 0,25s random-1.1-54KmMHXjttlERYcr1mvsAe-ghc8.0.1 ----- filepath-1.4.1.0-ghc8.0.1 ----- pureMD5-2.1.3-HBUMOqRjfoe6ZpLefZBT34-ghc8.0.1 0,19s crypto-api-0.13.2-JdUN2vdBIpq1NKgk9NRujQ-ghc8.0.1 ----- tagged-0.8.5-I7Gu0uzBLkQJCVUvdvwKKq-ghc8.0.1 ----- template-haskell-2.11.0.0-ghc8.0.1 0,15s pretty-1.1.3.3-ghc8.0.1 ----- ghc-boot-th-8.0.1-ghc8.0.1 0,13s entropy-0.3.7-54dsRvsNlllHvcIX99CGiD-ghc8.0.1 ----- system-fileio-0.3.16.3-EDef2a4Ximk1z04PLLp95q-ghc8.0.1 ----- unix-2.7.2.0-ghc8.0.1 ----- time-1.6.0.1-ghc8.0.1 ----- system-filepath-0.4.13.4-24DUGoIUqZu3MxGDhYLfCN-ghc8.0.1 0,09s cereal-0.5.3.0-JHJQkHEuvBGFx8XwIB7eX0-ghc8.0.1 ----- stm-linkedlist-0.1.0.0-GCpyrfjLFyWFZy8qotX7VW-ghc8.0.1 ----- stm-containers-0.2.15-JTVESCf1d8uCXyJbMCLfQJ-ghc8.0.1 ----- primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa-ghc8.0.1 ----- hashable-1.2.4.0-GnltDttmBjG9qGzcjuPOH4-ghc8.0.1 ----- text-1.2.2.1-FgcR4Xf0VlEHD9HLxzq9WJ-ghc8.0.1 0,06s binary-0.8.3.0-ghc8.0.1 ----- bytestring-0.10.8.1-ghc8.0.1 ----- focus-0.1.5-AwR3EdodPlZ3ltP8aTid4C-ghc8.0.1 ----- list-t-1-z6InD0gw7C2QDNkG2mqUf-ghc8.0.1 ----- monad-control-1.0.1.0-CVvkY5Vr2NNGCNJRXug3iR-ghc8.0.1 ----- transformers-base-0.4.4-LWS58Nywv1PJoy1IFDbvS4-ghc8.0.1 ----- stm-2.4.4.1-9HlGYelGmT69YkepeDjuRg-ghc8.0.1 ----- mmorph-1.0.6-3xsw6wg6Vs2JmwrJVsaYA0-ghc8.0.1 ----- transformers-compat-0.5.1.4-81lZyuOJOvsD0zyCv2TKld-ghc8.0.1 ----- mtl-2.2.1-6qsR1PHUy5lL47Hpoa4jCM-ghc8.0.1 0,06s transformers-0.5.2.0-ghc8.0.1 ----- base-prelude-1.0.1.1-50PByGWQp6O3J1SglYyZmP-ghc8.0.1 ----- containers-0.5.7.1-ghc8.0.1 ----- deepseq-1.4.2.0-ghc8.0.1 ----- array-0.5.1.1-ghc8.0.1 ----- base-4.9.0.0-ghc8.0.1 ----- integer-gmp-1.0.0.1-ghc8.0.1 ----- ghc-prim-0.5.0.0-ghc8.0.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:48:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:48:27 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.b98bbb47c7fc4f7ed5610413df0a6733@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): In line `let crux = attrCharFromW32` you add prime at the end and it should be ~4 times slower, as indicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:51:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:51:30 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.431392c64b6b74c392af9547c9c48f62@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 simonpj): Thanks. Sorry for missing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:56:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:56:07 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.06ab41a3f1310b579c99393cf99766e4@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:15 niteria]: > Is it quadratic even for the simplest case? Yes, indeed it is, but I don't think that this is the problem here (the previous algorithm is quadratic in this case too, yet lazily). From all the problems we have seen I think that the number of iterations is not a good metric to use to kill the checker: checking a guard counts as a single iteration, yet it calls the (rather expensive) term oracle `solveOneEq`. Similarly, matching against a GADT constructor calls the type oracle `tyOracle`. All in all, not all iterations cost the same. I will build the HEAD one of these days and start looking into it myself but can you check for me how much time is needed to compile your example for 4000 (+1) constructors (increase the -fmax-pmcheck-iterations sufficently so that the checker can run)? I have the impression that it will not take forever, it's just that the number of iterations is a bad metric and makes the checker give up even in cases where there is no need to. Could you check that for me? Replying to [comment:16 simonpj]: > It would be great if someone had time to really look at this. I think gkaracha has probably now moved on; is that true George? > > It's not just a question of making a one-line fix; you'd have to dig into the algorithm. Hi Simon, I will happily look into this. I have been busy researching other stuff but the performance of the checker is still a challenge I wish to address (and the recent comments in bug reports like this one show that it is of great importance for GHC users). Starting next week I will start spending time on it to see what can be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:57:02 -0000 Subject: [GHC] #12749: Typechecker regression involving RankNTypes In-Reply-To: <050.ba26f8465d511f962d827ef210be9368@haskell.org> References: <050.ba26f8465d511f962d827ef210be9368@haskell.org> Message-ID: <065.34a76878e67ccb2caa825c8d87f2ab49@haskell.org> #12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It worked before due to a bug that makes type inference unpredictable. The issues it that the two branches of the `if` both have a higher rank type, and that is difficult. The solution here is to tell GHC the type of the conditional: {{{ applyNTCheck :: NatTrans (Either a) Maybe applyNTCheck = ((if b then trans else applyNT) :: NatTrans (Either a) Maybe -> NatTrans (Either a) Maybe) eitherToMaybe }}} Sorry! If I knew how to do better I would. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 14:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 14:57:35 -0000 Subject: [GHC] #12749: Typechecker regression involving RankNTypes In-Reply-To: <050.ba26f8465d511f962d827ef210be9368@haskell.org> References: <050.ba26f8465d511f962d827ef210be9368@haskell.org> Message-ID: <065.d2a91b9255d28d0b897359fde0cc4fe5@haskell.org> #12749: Typechecker regression involving RankNTypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Meanwhile I'll mark as invalid, because this is by-design. Alas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 15:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 15:32:32 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.76ab0031e5f67644db1db1d721216f12@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I don't have an optimized `HEAD` at hand, so I tried it with `ghc-8.0` branch: {{{ $ for i in 1 10 100 1000 2000 4000 10000 20000; do echo $i; ./A.gen.sh $i > A.hs && time ghc8.0 -dno-debug-output -fmax-pmcheck-iterations=200000000 A.hs; done 1 [1 of 1] Compiling A ( A.hs, A.o ) real 0m0.289s user 0m0.178s sys 0m0.032s 10 [1 of 1] Compiling A ( A.hs, A.o ) real 0m0.228s user 0m0.135s sys 0m0.031s 100 [1 of 1] Compiling A ( A.hs, A.o ) real 0m0.299s user 0m0.225s sys 0m0.038s 1000 [1 of 1] Compiling A ( A.hs, A.o ) real 0m2.087s user 0m1.941s sys 0m0.112s 2000 [1 of 1] Compiling A ( A.hs, A.o ) real 0m5.885s user 0m5.126s sys 0m0.127s 4000 [1 of 1] Compiling A ( A.hs, A.o ) real 0m15.612s user 0m15.094s sys 0m0.472s 10000 [1 of 1] Compiling A ( A.hs, A.o ) real 1m31.634s user 1m29.615s sys 0m1.873s 20000 [1 of 1] Compiling A ( A.hs, A.o ) A.hs:40006:3: warning: Pattern match checker exceeded (200000000) iterations in an equation for ‘fromEnum’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I will measure again after I build `HEAD`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 15:54:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 15:54:21 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.a03ca24bca736a1ed0119a4aaf854701@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2621 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tjakway): The issue stems from RegAlloc.Graph.Main lines 100-106: {{{ -- If any of these dump flags are turned on we want to hang on to -- intermediate structures in the allocator - otherwise tell the -- allocator to ditch them early so we don't end up creating space leaks. let dump = or [ dopt Opt_D_dump_asm_regalloc_stages dflags , dopt Opt_D_dump_asm_stats dflags , dopt Opt_D_dump_asm_conflicts dflags ] }}} Without the dump flags the intermediate structures we need are scrapped. I propose adding a flag to keep the intermediates without printing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:04:13 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.97cdc2f1ad7d12f72bc4ead79670706e@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Ok, it doesn't look like the asymptotics changed between `7.10.3` and `8.0`. Numbers from `7.10.3`: {{{ $ for i in 1 10 100 1000 2000 4000 10000 20000; do echo $i; ./A.gen.sh $i > A.hs && (time ~/local/third- party2/ghc/7.10.3/gcc-4.9-glibc-2.20-fb/e0e26d4/bin/ghc -dno-debug-output A.hs) 2>&1 | grep real; done 1 real 0m0.126s 10 real 0m0.161s 100 real 0m0.207s 1000 real 0m1.428s 2000 real 0m3.875s 4000 real 0m11.783s 10000 real 1m13.631s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #12427: Type inference regression with RankNTypes (GHC 8.1) In-Reply-To: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> References: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> Message-ID: <060.51f04e6f11da8fb9764d9bfd173a6718@haskell.org> #12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717/ghc" 45bfd1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717" Refactor typechecking of pattern bindings This patch fixes a regression introduced, post 8.0.1, by this major commit: commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 Author: Simon Peyton Jones Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. I didn't get the typechecking of pattern bindings right, leading to Trac #12427. In fixing this I found that this program doesn't work: data T where T :: a -> ((forall b. [b]->[b]) -> Int) -> T h1 y = case y of T _ v -> v Works in 7.10, but not in 8.0.1. There's a happy ending. I found a way to fix this, and improve pattern bindings too. Not only does this fix #12427, but it also allows In particular,we now can accept data T where MkT :: a -> Int -> T ... let { MkT _ q = t } in ... Previously this elicited "my head exploded" but it's really fine since q::Int. The approach is described in detail in TcBinds Note [Typechecking pattern bindings] Super cool. And not even a big patch! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #12507: Can't deduce implicit parameter In-Reply-To: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> References: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> Message-ID: <066.1404987ea7f3e24ef26d1991cbbf6573@haskell.org> #12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"cdbc73aea2d8220dc2c3467afbac5c17db96453a/ghc" cdbc73ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cdbc73aea2d8220dc2c3467afbac5c17db96453a" Test Trac #12507 This is now working apparently. It relates to when a polymorphic function gets instantiated, under some implicit paramter bindings. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #3064: Very long compile times with type functions In-Reply-To: <046.2a7b2611764311f7357001c522d303b9@haskell.org> References: <046.2a7b2611764311f7357001c522d303b9@haskell.org> Message-ID: <061.402988a7d3a8b68968cbc57a21328856@haskell.org> #3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #12724: Be lazier about reducing type-function applications In-Reply-To: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> References: <046.ff93da68610ecfe4362e40c6ac6e370a@haskell.org> Message-ID: <061.f20c2b272c58d4b15ec9e4a4e93dbc7a@haskell.org> #12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #5030: Slow type checking of type-level computation heavy code. In-Reply-To: <044.1e1b32a223d10caca6de7222071eb23b@haskell.org> References: <044.1e1b32a223d10caca6de7222071eb23b@haskell.org> Message-ID: <059.ba04b09b0784a0200eaec4bac7759b39@haskell.org> #5030: Slow type checking of type-level computation heavy code. -------------------------------------------------+----------------------- Reporter: thesz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler (Type checker) | Version: 7.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time performance bug | Test Case: T5030 Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+----------------------- Comment (by Simon Peyton Jones ): In [changeset:"1f09b246d377a0007a953e5a77545d81671d2e36/ghc" 1f09b246/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f09b246d377a0007a953e5a77545d81671d2e36" Accept 20% dedgradation in Trac #5030 compile time In commit 31621b12 * A collection of type-inference refactorings. I fixed a bug in the on-the-fly unifier. Usually the on-the-fly unifier (TcUnify) defers type function applications to the constraint solver. But in one situation it inconsistently did not defer, so a unification happened without reducing a type function. By a fluke this makes T5030 (specifcially the definition of cnst) much better. It turns out that consistently non-deferring type functions makes the test for #3064 go bad. So somehow the current, inconsistent situation was an accidental sweet spot. But it's a horrible sweet spot, relying on what was essentially a bug. So I've accepted the worsening (it's an exotic case), and opened #12724 to deal with the underlying cause. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 16:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 16:16:17 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.4a30179b5bc2749b40f9e5b568bf7862@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11339, | T11339b, T11339c, T11339d; partial- | sigs/should_compile/T11339a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717/ghc" 45bfd1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45bfd1a65978ee282d8d2cc1ddb7e3e5f4cd4717" Refactor typechecking of pattern bindings This patch fixes a regression introduced, post 8.0.1, by this major commit: commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 Author: Simon Peyton Jones Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. I didn't get the typechecking of pattern bindings right, leading to Trac #12427. In fixing this I found that this program doesn't work: data T where T :: a -> ((forall b. [b]->[b]) -> Int) -> T h1 y = case y of T _ v -> v Works in 7.10, but not in 8.0.1. There's a happy ending. I found a way to fix this, and improve pattern bindings too. Not only does this fix #12427, but it also allows In particular,we now can accept data T where MkT :: a -> Int -> T ... let { MkT _ q = t } in ... Previously this elicited "my head exploded" but it's really fine since q::Int. The approach is described in detail in TcBinds Note [Typechecking pattern bindings] Super cool. And not even a big patch! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 17:09:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 17:09:03 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.5fc892512445d0cfa70182616368e24d@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This seems fairly bad and shouldn't block forever on a redesign if there's a way to fix it in the short term. However, I don't understand the issue precisely. The ticket title has a kind of type error, since `extra-lib-dirs` is a flag that is only meaningful to Cabal, not to ghc. Could someone provide a reproducer that does not involve stack or Cabal, or characterize the interaction between Cabal and ghc? This may not even be a ghc bug at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 17:10:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 17:10:44 -0000 Subject: [GHC] #11186: Give strong preference to type variable names in scope when reporting hole contexts In-Reply-To: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> References: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> Message-ID: <060.b05b5dff2258dd77e465c99e94c43b74@haskell.org> #11186: Give strong preference to type variable names in scope when reporting hole contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: typed-holes 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 dfeuer): Replying to [comment:5 simonpj]: > And indeed, the same skolem bound in the pattern might have different lexical names in different places: > {{{ > bla2 (Foop q) = ( (\(r::pah) -> length ([r] :: _x)) q > , (\(r::hap) -> length ([r] :: _y)) q ) > }}} > Now what would you expect? I would expect the report about `_x` to tell me about `pah` and the one about `_y` to tell me about `hap`. May I ask what you think will be hard about this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 19:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 19:09:12 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.6a7a4d696632972e85d682488a44d844@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Results for `HEAD` (ff225b4957ded752dc017446fccb9708a1f4ec56): {{{ 1 real 0m0.201s 10 real 0m0.202s 100 real 0m0.303s 1000 real 0m1.907s 2000 real 0m4.617s 4000 real 0m13.118s 10000 real 1m1.684s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 20:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 20:37:00 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.38c86ce8f34b70086839f2201cbc0b89@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 21:11:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 21:11:18 -0000 Subject: [GHC] #12751: T5611 fails non-deterministically on OSX Message-ID: <049.17fafd770359ce4830897dc1166d36bc@haskell.org> #12751: T5611 fails non-deterministically on OSX -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is the test. {{{#!hs {-# LANGUAGE CPP,ForeignFunctionInterface #-} import Control.Concurrent import Foreign.C import System.IO #ifdef mingw32_HOST_OS sleep n = sleepBlock (n*1000) foreign import stdcall unsafe "Sleep" sleepBlock :: Int -> IO () #else sleep n = sleepBlock n foreign import ccall unsafe "sleep" sleepBlock :: Int -> IO () #endif main :: IO () main = do hSetBuffering stdout LineBuffering tid <- forkIO $ do putStrLn "child: Sleeping" _ <- sleep 1 -- The following lines should not happen after the killThread from the -- parent thread completes. However, they do... -- putStrLn "child: Done sleeping" threadDelay 100000 putStrLn "child: Done waiting" threadDelay 100000 -- putStrLn $ "parent: Throwing exception to thread " ++ show tid throwTo tid $ userError "Exception delivered successfully" putStrLn "parent: Done throwing exception" threadDelay 200000 }}} It occasionally fails with {{{ =====> T5611(normal) 1 of 1 [0, 0, 0] cd "./concurrent/should_run/T5611.run" && "/Users/matt/Documents/haskell/ghc/inplace/test spaces/ghc-stage2" -o T5611 T5611.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -dno-debug-output cd "./concurrent/should_run/T5611.run" && ./T5611 Actual stderr output differs from expected: --- ./concurrent/should_run/T5611.run/T5611.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 +++ ./concurrent/should_run/T5611.run/T5611.run.stderr.normalised 2016-10-21 22:08:55.000000000 +0100 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) *** unexpected failure for T5611(normal) Unexpected results from: TEST="T5611" }}} I am marking it broken for now. Does anyone know why it is failing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 21 23:46:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 21 Oct 2016 23:46:16 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.5263f50a665d4b177abf9799beb4b50c@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering Comment: I can see where the problem is here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 00:11:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 00:11:21 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.cf376b6ea80187f0481d67a15461e0f6@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: mpickering Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D2624 Comment: The ASSERT was slightly wrong as there is a special case where a `Void#` argument is added to the matching continuation to ensure laziness for a nullary pattern synonym. The fix is to check whether the number of arguments is 0 and if so check wether the only argument to the matcher is `Void#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 00:21:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 00:21:34 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.0ef418f64f71e68ccf472aebe62e6dea@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"f41a8a369796985a75dd618b969292e1e7033112/ghc" f41a8a36/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f41a8a369796985a75dd618b969292e1e7033112" Add and use a new dynamic-library-dirs field in the ghc-pkg info Summary: Build systems / package managers want to be able to control the file layout of installed libraries. In general they may want/need to be able to put the static libraries and dynamic libraries in different places. The ghc-pkg library regisrtation needs to be able to handle this. This is already possible in principle by listing both a static lib dir and a dynamic lib dir in the library-dirs field (indeed some previous versions of Cabal did this for shared libs on ELF platforms). The downside of listing both dirs is twofold. There is a lack of precision, if we're not careful with naming then we could end up picking up the wrong library. The more immediate problem however is that if we list both directories then both directories get included into the ELF and Mach-O shared object runtime search paths. On ELF this merely slows down loading of shared libs (affecting prog startup time). On the latest OSX versions this provokes a much more serious problem: that there is a rather low limit on the total size of the section containing the runtime search path (and lib names and related) and thus listing any unnecessary directories wastes the limited space. So the solution in this patch is fairly straightforward: split the static and dynamic library search paths in the ghc-pkg db and its use within ghc. This is a traditional solution: pkg-config has the same static / dynamic split (though it describes in in terms of private and public, but it translates into different behaviour for static and dynamic linking). Indeed it would make perfect sense to also have a static/dynamic split for the list of the libraries to use i.e. to have dynamic variants of the hs-libraries and extra-libraries fields. These are not immediately required so this patch does not add it, but it is a reasonable direction to follow. To handle compatibility, if the new dynamic-library-dirs field is not specified then its value is taken from the library-dirs field. Contains Cabal submodule update. Test Plan: Run ./validate Get christiaanb and carter to test it on OSX Sierra, in combination with Cabal/cabal-install changes to the default file layout for libraries. Reviewers: carter, austin, hvr, christiaanb, bgamari Reviewed By: christiaanb, bgamari Subscribers: ezyang, Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2611 GHC Trac Issues: #12479 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 07:08:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 07:08:04 -0000 Subject: [GHC] #12752: GHC should be able to warn on usafe CPP usage Message-ID: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> #12752: GHC should be able to warn on usafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GCC has a warning `-Wundef` that catches unsafe CPP usage like: {{{#!c #if variable_does_not_exist // something #endif }}} The GCC man page says about `-Wundef`: {{{ -Wundef Warn if an undefined identifier is evaluated in an "#if" directive. }}} Following GCC's lead, GHC should have a similar warning flag to detect and warn about this problem in Haskell code that uses CPP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 07:11:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 07:11:34 -0000 Subject: [GHC] #12752: GHC should be able to warn on usafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.f6db46c3a7bf82188c562a0e0502b94d@haskell.org> #12752: GHC should be able to warn on usafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 07:12:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 07:12:59 -0000 Subject: [GHC] #12752: GHC should be able to warn on usafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.26d392470c23acf42d7c889e73642a84@haskell.org> #12752: GHC should be able to warn on usafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I suspect this is just a matter of adding a GHC warning flag named something like `-Dcpp-undef` and then if that is set, passing `-Wundef` to the C pre-processor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 07:54:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 07:54:47 -0000 Subject: [GHC] #12752: GHC should be able to warn on unsafe CPP usage (was: GHC should be able to warn on usafe CPP usage) In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.554583575581dcea72b7d38020986dd7@haskell.org> #12752: GHC should be able to warn on unsafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 08:41:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 08:41:38 -0000 Subject: [GHC] #12752: GHC should be able to warn on unsafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.219018552f29b8934366c9fd144187f3@haskell.org> #12752: GHC should be able to warn on unsafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => phab:D2626 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 12:33:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 12:33:11 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.e908a2692c8b63631a779d8f0eae9218@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:10 rwbarton]: [...] > This may not even be a ghc bug at all. I think the ghc bug here is that GHCi panics when it cannot find a shared library and for errors returned by the link editor and also for some errors returned by `dlopen`. The correct behavior would be to print an error message and terminate normally in such situation as it is not ghc's fault that a file is not found etc. I shall create a separate ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 13:35:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 13:35:33 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.a2442bf30e58507442ea0a7cc50288c8@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:10 rwbarton]: > This seems fairly bad and shouldn't block forever on a redesign if there's a way to fix it in the short term. > > However, I don't understand the issue precisely. The ticket title has a kind of type error, since `extra-lib-dirs` is a flag that is only meaningful to Cabal, not to ghc. Could someone provide a reproducer that does not involve stack or Cabal, or characterize the interaction between Cabal and ghc? Let me describe the issue and perhaps you could help me turn this into a regression test: 1. We have a Haskell package that calls out to a C library. In this ticket the zlib package calls the C library `libz.so`. 1. We want to compile a module that depends on the Haskell package (from 1) and also uses Template Haskell. 1. To compile the module Template Haskell loads all packages that are specified as dependencies (in the Cabal file or on the ghc command line). Currently this means loading all transitive dependencies of each package to be loaded. Package loading fails because `libz.so` cannot be found in any standard directory because on the system @mboes describes it is installed elsewhere. The title of the ticket suggests to specify the directory where `libz.so` is located in the cabal file (of the package using zlib). I think this would violate abstraction: As a client of package zlib I expect zlib to be self-contained and provide all information that is needed to use it. In fact for a dynamically linked zlib package that is indeed the case. When building a dynamically linked package we record an R(UN)PATH for C libraries that are not installed in standard locations. If we just loaded the shared library of package zlib (`libHSzlib<...>.so` we would not need to know where to find `libz.so` because the system runtime loader takes care of that. But currently GHC's dynamic linker mimics the behavior of the (static) RTS linker and would load `libz.so` before it loads `libHSzlib<...>.so`. I could extract a patch from my work on #11238 that implements what I said in the third paragraph of comment:6. It would not only be a short term fix but also be a step in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 13:57:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 13:57:37 -0000 Subject: [GHC] #12753: GHCi/Template Haskell: Don't panic on linker errors. Message-ID: <047.d3ab0d524e9cdf7f9d5712b3903db94c@haskell.org> #12753: GHCi/Template Haskell: Don't panic on linker errors. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11042 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the link editor is called by `Linker.hs` as part of loading a library and an error occurs GHCi panics. As a consequence users submit bug reports because the panic message tells them do do so. The link editor process can fail because of missing libraries, failure to create a link file, missing linker program, etc., all of which are beyond the control of GHC and should not be considered a bug in GHC. When the link editor fails 1. an error message should be printed and GHC should terminate if the error is fatal. 1. a warning (that could be silenced) should be issued in non-fatal cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 14:00:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 14:00:08 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.8201df6aaffb51b978bcc3dd436c89c5@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * related: #10458 #5289 => #10458 #5289 #12753 Comment: Replying to [comment:11 trommler]: > Replying to [comment:10 rwbarton]: > [...] > > This may not even be a ghc bug at all. > I think the ghc bug here is that GHCi panics when it cannot find a shared library and for errors returned by the link editor and also for some errors returned by `dlopen`. The correct behavior would be to print an error message and terminate normally in such situation as it is not ghc's fault that a file is not found etc. I shall create a separate ticket for that. Created #12753. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 14:04:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 14:04:15 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.f4ac5e2f22725c8e07e325cd0075524c@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 14:11:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 14:11:45 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.5a0d1a06046deb0d22d5ebb72d613bef@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:13 trommler]: > Replying to [comment:11 trommler]: > > Replying to [comment:10 rwbarton]: > > [...] > > > This may not even be a ghc bug at all. > > I think the ghc bug here is that GHCi panics when it cannot find a shared library and for errors returned by the link editor and also for some errors returned by `dlopen`. The correct behavior would be to print an error message and terminate normally in such situation as it is not ghc's fault that a file is not found etc. I shall create a separate ticket for that. > Created #12753. Wait a minute! In this ticket GHC did not panic but perhaps the error message could be more informative and tell the user why it wanted to load `libz.so` at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 16:01:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 16:01:44 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.48e59aeb4229abe8ce9fe26a2e2efcb1@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2621 Wiki Page: | -------------------------------------+------------------------------------- Description changed by tjakway: @@ -2,4 +2,3 @@ - and to start I'm trying to write a function (mostly modeled on - hscCompileCmmFile and cmmNativeGen) that will compile a cmm file and - return register allocation stats (that can then be asserted against). It - should be less cumbersome to use than cmmNativeGen. + and to start I'm trying to write a function that will compile a cmm file + and return register allocation stats (that can then be asserted against). + It should be less cumbersome to use than cmmNativeGen. New description: I'm trying to write a unit test for the graph coloring register allocator and to start I'm trying to write a function that will compile a cmm file and return register allocation stats (that can then be asserted against). It should be less cumbersome to use than cmmNativeGen. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 17:55:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 17:55:36 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. Message-ID: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A file only containing a 10000 constructor enumeration type compiles twice as fast with an explicit export list compare to having no export list. {{{ # print "module A where" print "module A (T ( .. ) ) where" print "\n" print "data T = C" for i in range(0,10000): print (" | C" + str(i)) }}} Without an export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m22.872s user 0m19.653s sys 0m0.868s }}} With the export list: {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m11.249s user 0m10.428s sys 0m0.435s }}} The culprit here is `exports_from_avail`, in the case that no export list is provided, the things to export are gathered from the `GlobalRdrEnv`. Each constructor is placed in its own `Avail` which are then combined by `plusAvail` which is implemented using the expensive `unionLists`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 18:44:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 18:44:07 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.b9c1ed213d8a4c16ea679e76dab55622@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 mpickering): * status: new => closed * resolution: => invalid Comment: I don't know what I was doing but I can no longer reproduce this. Sorry for the noise, the code in `exports_from_avail` still looks like it could be more efficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 19:30:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 19:30:12 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.ed4827b764647b84eff7d71682fd7bff@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2617 Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"acc98510c5e32474b0bba9fba54e78df2b11078c/ghc" acc9851/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acc98510c5e32474b0bba9fba54e78df2b11078c" Fix failure in setnumcapabilities001 (#12728) The value of enabled_capabilities can change across a call to requestSync(), and we were erroneously using an old value, causing things to go wrong later. It manifested as an assertion failure, I'm not sure whether there are worse consequences or not, but we should get this fix into 8.0.2 anyway. The failure didn't happen for me because it only shows up on machines with fewer than 4 processors, due to the new logic to enable -qn automatically. I've bumped the test parameter 8 to make it more likely to exercise that code. Test Plan: Ran setnumcapabilities001 many times Reviewers: niteria, austin, erikd, rwbarton, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2617 GHC Trac Issues: #12728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 19:30:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 19:30:12 -0000 Subject: [GHC] #12741: --numa doesn't work even if libnuma is available In-Reply-To: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> References: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> Message-ID: <061.54b006e49ef4a5bcd0c60c91761750c8@haskell.org> #12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2620 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1050e46b5b1640a475fa2fa67616cda8d31308e2/ghc" 1050e46b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1050e46b5b1640a475fa2fa67616cda8d31308e2" rts: configure.ac should populate HAVE_LIBNUMA instead of USE_LIBNUMA Code in rts/ which deals with numa checks for `#if HAVE_LIBNUMA`, however this macro is not populated during `./configure`. https://phabricator.haskell.org/D2329 changed this code last and we instead set `USE_LIBNUMA` which fails to setup numa correctly. Test Plan: From main directory in ghc, ./configure && make clean && make boot && make cd nofib/parallel/queens ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded ./Main 15 +RTS -N24 -s -A64m --numa This fails before this patch with Main: --numa: OS reports NUMA is not available After the fix, it works as expected. Run the validation script, ./validate (It fails with an error in `compiler/utils/Util.hs` saying `GHC.Stack.CallStack` not found, once I remove this 1 line from this file , the script works) Reviewers: hvr, austin, bgamari, erikd, simonmar Reviewed By: erikd, simonmar Subscribers: mpickering, thomie, erikd, niteria Differential Revision: https://phabricator.haskell.org/D2620 GHC Trac Issues: #12741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:24:18 -0000 Subject: [GHC] #12751: T5611 fails non-deterministically on OSX In-Reply-To: <049.17fafd770359ce4830897dc1166d36bc@haskell.org> References: <049.17fafd770359ce4830897dc1166d36bc@haskell.org> Message-ID: <064.7098b353186a1e1db33d83a29c416415@haskell.org> #12751: T5611 fails non-deterministically on OSX -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Ben Gamari ): In [changeset:"a662f46c32ce35bd0769aa1ab224c3dfd39e207c/ghc" a662f46c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a662f46c32ce35bd0769aa1ab224c3dfd39e207c" Skip T5611 on OSX as it fails non-deterministically. Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2622 GHC Trac Issues: #12751 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:24:18 -0000 Subject: [GHC] #12752: GHC should be able to warn on unsafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.4643041045e1fbc674a86cb631b27274@haskell.org> #12752: GHC should be able to warn on unsafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2626 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3cb32d8b0b51c548ab424139c66cce6b37a2ab1b/ghc" 3cb32d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cb32d8b0b51c548ab424139c66cce6b37a2ab1b" Add -Wcpp-undef warning flag When enabled, this new warning flag passes `-Wundef` to the C pre-processor which causes the pre-processor to warn on uses of the `#if` directive on undefined identifiers. It is not currently enabled in any of the standard warning groups. Test Plan: Make sure the two tests pass on all major platforms. Reviewers: hvr, carter, Phyx, bgamari, austin Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2626 GHC Trac Issues: #12752 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:24:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:24:44 -0000 Subject: [GHC] #12752: GHC should be able to warn on unsafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.f4efb9d838e4d3672695adcd326bdbdc@haskell.org> #12752: GHC should be able to warn on unsafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:25:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:25:33 -0000 Subject: [GHC] #12741: --numa doesn't work even if libnuma is available In-Reply-To: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> References: <046.85800ab7ad49f1fcb538b9279cd2b49b@haskell.org> Message-ID: <061.d5b1b429f0db3e08637550ad38e181ae@haskell.org> #12741: --numa doesn't work even if libnuma is available -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2620 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * version: 8.0.1 => 8.1 * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:25:59 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.3bdcb8ce1c1853cfda7d1e1b0a786769@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2617 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:26:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:26:46 -0000 Subject: [GHC] #12752: GHC should be able to warn on unsafe CPP usage In-Reply-To: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> References: <044.8bdd8bbdf6a2adb4a19c822b2b7f5a92@haskell.org> Message-ID: <059.b534082a9d1e5ce794054ba7a9af8ffb@haskell.org> #12752: GHC should be able to warn on unsafe CPP usage -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2626 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well okay, but you could also just use `-optP -Wundef` since forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:27:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:27:03 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.7bf9476bbf566ad4b203b1c8cbf68f82@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2617 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 20:30:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 20:30:28 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.224df8074bcccac66935130b39ce043f@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The issue here seems to be the `Tree` module. With `-O1` compilation takes four minutes with much of the time being spent in the simplifier. However, deech said that his real concern was the compilation time with `-O0`. The culprit here appears to be desugaring, which takes over 10 seconds of the 30 second total compilation time (with a profiled compiler). Looking into the profile, it seems that the culprit is `simpleOptPgm`. In particular, it appears that the majority of desugaring time is spent in `optCoercion` called from the `Cast` branch of `simple_opt_expr.go`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 21:33:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 21:33:47 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.61d4cdd4e0dd8925ac4fe267127b778b@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Looking at the desugared Core of `Tree` (which is 2.4 gigabytes!) it seems we end up with lots of equivalent yet repeated equality coercions at the top level. For instance, there are 64 coercions of the form, {{{#!hs -- RHS size: {terms: 2, types: 22, coercions: 691} $d~_aDMR :: (Match (Graphics.UI.FLTK.LowLevel.Hierarchy.CMenuItem Base) :: *) ~ (FindOp MenuItem MenuItem (SetLabelsize ()) :: *) }}} However, it turns out that this is a drop in the bucket compared to, {{{ -- RHS size: {terms: 8,634, types: 10,620, coercions: 1,621,550} make_window :: IO (Ref Window) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 21:41:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 21:41:42 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax In-Reply-To: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> References: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> Message-ID: <062.bb21cd375e104cb2f9eb09a1d6f4b049@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T12729 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 4c8aab8f5663b9f0f1acdcc1afc85d921f2609d6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 21:41:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 21:41:51 -0000 Subject: [GHC] #12729: Unlifted newtypes via GADTSyntax In-Reply-To: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> References: <047.ac9e4a3c0459585d834682b36dae88d0@haskell.org> Message-ID: <062.3aa8025c8cbd9bc96ba7000925e91d9c@haskell.org> #12729: Unlifted newtypes via GADTSyntax -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T12729 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 22 22:41:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 22 Oct 2016 22:41:47 -0000 Subject: [GHC] #12507: Can't deduce implicit parameter In-Reply-To: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> References: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> Message-ID: <066.d5484936b39d6216a80350f2bc09b3dc@haskell.org> #12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 05:13:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 05:13:22 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together Message-ID: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries /ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist- install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries /ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -split-objs -dynamic-too -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o -dyno libraries/ghc-prim/dist- install/build/GHC/Types.dyn_o /usr/bin/ld: -r and -pie may not be used together collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/Types.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 }}} Googling showed other builds with similar errors, for a bug report [which is now resolved]: - https://wiki.ubuntu.com/SteveBeattie/PIENotes - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 Running with `ld` GNU ld (GNU Binutils for Ubuntu) 2.27. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 08:49:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 08:49:40 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together In-Reply-To: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> References: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> Message-ID: <065.e7c9f2239e29ac86f6391887fb501e71@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): This is a known issue and there should be already related tickets filed about this in the GHC wiki. Also, in https://launchpad.net/~hvr/+archive/ubuntu/ghc I addressed this problem by simply calling `configure` a bit differently to make it work which basically comes down to {{{ CONF_CC_OPTS_STAGE2=-fno-PIE \ CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ CONF_LD_LINKER_OPTS_STAGE2=-no-pie \ ./configure }}} Did somebody come up with a reliable autoconf test already to detect whether `gcc` has `-no-pie` on by default? IIRC you can't rely on CPP for this and you really have to perform a compile and analyse the result, which is the main reason we haven't implemented it yet... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 09:06:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 09:06:45 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error Message-ID: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> #12756: ghci gives stg_ap_v_ret error --------------------------------------+---------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The following interaction with ghci occurs: {{{ Prelude> :l Test.hs [1 of 2] Compiling BigWord ( lib/BigWord.hs, interpreted ) [2 of 2] Compiling Main ( Test.hs, interpreted ) Ok, modules loaded: BigWord, Main. *Main> main : internal error: stg_ap_v_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} whereas the compiled file Test.hs executes without error. See the attached files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 09:07:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 09:07:31 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error In-Reply-To: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> References: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> Message-ID: <063.5920c899d8b93ff724b7b4954f7b7c52@haskell.org> #12756: ghci gives stg_ap_v_ret error ----------------------------------+-------------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by ryanreich): * Attachment "Test.hs" added. Minimal main function -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 09:07:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 09:07:57 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error In-Reply-To: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> References: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> Message-ID: <063.700d71af5e0e7dfdd53fd8e58aa7d059@haskell.org> #12756: ghci gives stg_ap_v_ret error ----------------------------------+-------------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by ryanreich): * Attachment "BigWord.hs" added. Source library -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 11:15:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 11:15:25 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 Message-ID: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This affects GHC 8.0.2dev (d84a824cebe94711528727bcb587bfc369ec36a2) as well as GHC HEAD (c23dc6164d54eacc654516b885104dc8b7678f16) The following program results in a segfault when compiled at -O1 or more: {{{#!hs {-# LANGUAGE OverloadedStrings #-} module Main (main) where import Data.ByteString (ByteString) import qualified Data.ByteString as B answers :: [ByteString] answers = map (B.filter (/= 0x20)) [ "e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855" , "d7a8fbb3 07d78094 69ca9abc b0082e4f 8d5651e4 6d3cdb76 2d02d0bf 37c9e592" , "e4c4d8f3 bf76b692 de791a17 3e053211 50f7a345 b46484fe 427f6acc 7ecc81be" , "ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad" , "248d6a61 d20638b8 e5c02693 0c3e6039 a33ce459 64ff2167 f6ecedd4 19db06c1" , "cf5b16a7 78af8380 036ce59e 7b049237 0b249b11 e8f07a51 afac4503 7afee9d1" , "cdc76e5c 9914fb92 81a1c7e2 84d73e67 f1809a48 a497200e 046d39cc c7112cd0" ] x, y :: ByteString x = "e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855" y = B.filter (/= 0x20) x main :: IO () main = do print (seq x ()) print (seq y ()) print (length answers) print (seq (head answers) ()) -- segfault! }}} {{{ $ ghc-8.0.2 -fforce-recomp --make -O1 bug.hs && ./bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... () () 7 Segmentation fault }}} {{{ $ ghc-8.0.2 -fforce-recomp --make -O0 bug.hs && ./bug [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug ... () () 7 () }}} I haven't yet investigated why this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 11:26:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 11:26:27 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.0368befaeb4a218ad7d00d69a966baf2@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I was informed by slyfox that this is much related (almost to the point of being a duplicate) of #12585, which in turn is a duplicate of #11312 I do consider this a blocker for GHC 8.0.2 as the repro-case above is code that's surely not exotic... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 11:27:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 11:27:38 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.8f9a47c3dd150d3183dba577ae55802e@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): See #12757 for yet another instance/report, this time affecting pre- release GHC 8.0.2 snapshots -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 11:42:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 11:42:26 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.34d5bbf08cabb361c6f4398a56048af8@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 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 Iceland_jack): This is a pipe dream, `Logic` offers cool possibilities. [https://hackage.haskell.org/package/sbv-5.12/docs/src/Data-SBV- BitVectors-Model.html sbv] has `EqSymbolic` which is an `Eq a` where `Logic a ~ SBool` : {{{#!hs infix 4 .==, ./= class EqSymbolic a where (.==), (./=) :: a -> a -> SBool }}} This could be the regular `Eq` if we had something like (with `Boolean` taken from ticket:10592#comment:12) {{{#!hs class Boolean (Logic a) => Eq (a :: TYPE rep) where type Logic a :: TYPE (Rep rep) (==) :: a -> a -> Logic a a == b = not (a /= b) (/=) :: a -> a -> Logic a a /= b = not (a == b) instance Eq (SBV a) where type Logic (SBV a) = SBool (==) :: SBV a -> SBV a -> SBool SBV a == SBV b = SBV (svEqual a b) instance EqSymbolic (SArray a b) where type Logic (SArray a b) = SBool (==) :: SArray a b -> SArray a b -> SBool SArray a == SArray b = SBV (eqSArr a b) }}} We lose `EqSymbolic Bool` but `... => EqSymbolic [a]` would survive in a different form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 12:40:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 12:40:46 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error In-Reply-To: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> References: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> Message-ID: <063.a914301a3b386e6718b593051a6a0013@haskell.org> #12756: ghci gives stg_ap_v_ret error ----------------------------------+-------------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by AlexET): After a bit of reducing I think there is a bug in the code meaning the `unsafeRead`/`unsafeWrite` in `addBigWords` are out of bounds. This is because although we have arrays we use have bounds `(1,1)` and we write at index `1`, `unsafeRead` and `unsafeWrite` always use 0-indexed array indexes rather than using the array bounds (because they are meant to be fast and unsafe). The OOB write means that any thing can happen. In the case of compiled we happen to ignore it, when interpreted we happen to crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 13:56:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 13:56:27 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together In-Reply-To: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> References: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> Message-ID: <065.73a230f30f1b823aa23ab97ec8cd8b42@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SamuelMarks): Thanks for those arguments, the build is currently running (no errors yet =]). Automated solutions to this problem include `grep` of: {{{ gcc -dumpspecs }}} Or a `readelf` like from [http://www.trapkit.de/tools/checksec.html checksec.sh]: {{{ #!bash if readelf -h $1 2>/dev/null | grep -q 'Type:[[:space:]]*EXEC'; then echo -n -e '\033[31mNo PIE \033[m ' elif readelf -h $1 2>/dev/null | grep -q 'Type:[[:space:]]*DYN'; then if readelf -d $1 2>/dev/null | grep -q '(DEBUG)'; then echo -n -e '\033[32mPIE enabled \033[m ' else echo -n -e '\033[33mDSO \033[m ' fi else echo -n -e '\033[33mNot an ELF file\033[m ' fi }}} Alternatively in C++ take a look at this [http://lists.llvm.org/pipermail /cfe-commits/Week-of-Mon-20130408/077610.html LLVM patch implementation] of `isPIEDefault`. [https://wiki.dlang.org/LDC ldc] uses `llvm::Reloc::PIC_` to check, see: [https://github.com/ximion/ldc/blob/d9496882163e173ea718756a7fb0cbc627c5326f/driver/targetmachine.cpp#L521 ldc/driver/targetmachine.cpp#L521]. In particular see `Reloc::Model TargetMachine::getRelocationModel() const` in LLVM's [http://llvm.org/docs/doxygen/html/classllvm_1_1TargetMachine.html#a87f1815c4b56735aaadbbcdfdf32cf4f TargetMachine.cpp]. Additionally there's this `gcc` patch [http://gcc.gnu.org/ml/gcc- patches/2016-07/msg01257.html check -nopie in configure]. The compile-and-see approach you mentioned is used in various places also, e.g.: `gccSupportsFlag` function under [https://github.com/gcc- mirror/gcc/blob/be239ed2ba619747b64629895116f209b58baee8/libgo/go/cmd/go/build.go#L3082 gcc/libgo/go/cmd/go/build.go#L3082]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 16:12:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 16:12:05 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.58e5752b854a3da62e3ea964359453e6@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => closed * resolution: => wontfix Comment: Replying to [comment:12 trommler]: > Replying to [comment:10 rwbarton]: > 3. To compile the module Template Haskell loads all packages that are specified as dependencies (in the Cabal file or on the ghc command line). Currently this means loading all transitive dependencies of each package to be loaded. Package loading fails because `libz.so` cannot be found in any standard directory because on the system @mboes describes it is installed elsewhere. Actually, package zlib should record the location of libz.so if it is not found in a standard location. GHCi reads the `library-dirs` field that should contain the path to `libz.so`. In changeset:f41a8a369796985a75dd618b969292e1e7033112 a new field `dynamic-library-dirs` has been introduced for cases where dynamic library development files are in a directory separate from the archive (`.a`) files. I checked the code in `Linker.hs` and it reads the `library-dirs` field from the package database. So I would say this is a packaging error on nix. As I said comment:12 passing `extra-lib-dirs` breaks abstraction and is brittle. Closing this as wontfix, please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 17:40:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 17:40:13 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite Message-ID: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC testsuite's performance tests tends to be a constant source of busy-work as it requires that contributors manually bump performance numbers and propagate these changes across platforms. Moreover, the testsuite is poor at noticing performance regressions due to false positive failures (due to spurious environmental differences) and false negatives (due to the rather generous acceptance windows that many tests have). Joachim and I briefly discussed this at Hac Phi and came up with the following proposal: * We rip expected performance numbers out of the `.T` files * -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 17:51:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 17:51:38 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.6080a9da03e94d57390e3e88afb16714@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -13,1 +13,5 @@ - * + * We replace the existing `compiler_stats_num_field` test modifier with + an implementation that dumps performance metrics to a CSV file + * Introduce a tool to compare this CSV file to metrics associated with a + ancestor commit via `git notes` + * The tool would also be able to add notes New description: The GHC testsuite's performance tests tends to be a constant source of busy-work as it requires that contributors manually bump performance numbers and propagate these changes across platforms. Moreover, the testsuite is poor at noticing performance regressions due to false positive failures (due to spurious environmental differences) and false negatives (due to the rather generous acceptance windows that many tests have). Joachim and I briefly discussed this at Hac Phi and came up with the following proposal: * We rip expected performance numbers out of the `.T` files * We replace the existing `compiler_stats_num_field` test modifier with an implementation that dumps performance metrics to a CSV file * Introduce a tool to compare this CSV file to metrics associated with a ancestor commit via `git notes` * The tool would also be able to add notes -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 17:51:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 17:51:45 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.94da30192c70b09dec5125289221f1bc@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 bgamari): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 20:48:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 20:48:19 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error In-Reply-To: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> References: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> Message-ID: <063.971307b737445f0c3d341e99506e384a@haskell.org> #12756: ghci gives stg_ap_v_ret error ----------------------------------+-------------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by ryanreich): You are totally right. That was very careless on my part. So is this an "incorrect" bug report, despite the exhortation from ghci, or should the error be caught better? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 21:11:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 21:11:02 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.c659962d9c72eeac42eae0b6d736e8ac@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by phadej): * owner: => phadej * differential: => D2632 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 21:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 21:13:14 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.ebda18c93fefc6feed50ff15c7ff79b7@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by phadej): * differential: D2632 => Phab:D2632 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 23:12:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 23:12:04 -0000 Subject: [GHC] #12759: Latest Debian GCC breajs GHC Message-ID: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> #12759: Latest Debian GCC breajs GHC ----------------------------------------+-------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- Just got `gcc (Debian 6.2.0-9) 6.2.0 20161019` in a recent upgrade (Debian Testing) and now: {{{ > cat hello.hs main :: IO () main = putStrLn "Hello" > ghc hello.hs -o hello [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello ... /usr/bin/ld: hello.o: relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' \ can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/ghc-8.0/lib/base-4.9.0.0/libHSbase-4.9.0.0.a(Base__166.o): \ relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when \ making a shared object; recompile with -fPIC .... }}} The previous version of gcc in Debian Testing (gcc (Debian 6.2.0-6) 6.2.0 20161010) is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 23 23:43:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 23 Oct 2016 23:43:30 -0000 Subject: [GHC] #12759: Latest Debian GCC breajs GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.3efed2a6be1c4fd94389fc0c861143d9@haskell.org> #12759: Latest Debian GCC breajs GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): Almost certain this is due to: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=835148 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 03:08:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 03:08:21 -0000 Subject: [GHC] #12759: Latest Debian GCC breajs GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.fcb7e5556faefc3ee20bbcb6ad941afa@haskell.org> #12759: Latest Debian GCC breajs GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): Debain allows parallel installs of GCC, so for now I've worked around this issue by switching the default compiler to gcc-5 (gcc-5 (Debian 5.4.1-3) 5.4.1 20161019). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 05:28:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 05:28:40 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) Message-ID: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Still trying to debug compilation failures in our codebase, still can't build prerequisites yet. ghc needs to be compiled with BuildVlavour = devel2 and compilation with -O2 is required: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module A where import Data.List(minimumBy) import Data.Ord (comparing) data A a = A Int newtype B = B Double deriving (Eq,Ord,Num,Real,Fractional,RealFrac,Floating,RealFloat) class C a where _c :: [a] -> D a instance C B where _c = f2 u data D x = D [(x,Double)] [ x ] u = undefined f1 :: RealFloat a => A a -> a -> [a] -> D a f1 (A a1) m ps0 = D (zip tickvs []) labelvs where range _ | m == m = if m==0 then (-1,1) else (m, m) labelvs = map fromRational $ f3 (fromIntegral a1) (range ps0) tickvs = map fromRational $ f3 (fromIntegral a1) (head labelvs, head labelvs) f2 :: RealFloat a => A a -> [a] -> D a f2 lap ps = f1 u (minimum ps) ps f3 :: RealFloat a => a -> (a,a) -> [Rational] f3 k rs@(m,_ ) = map ((s*) . fromIntegral) [floor m .. ] where s = minimumBy (comparing ((+ k) . realToFrac)) [0] }}} {{{ % ghc -O2 A.hs [1 of 1] Compiling A ( A.hs, A.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1978:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2014:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1454:33 in ghc:Coercion in_scope InScope [00 :-> wild_00, X1o :-> wild_X1o, X1p :-> wild_X1p, a4z5 :-> $c==_a4z5, a4zs :-> $c/=_a4zs, a4zV :-> $ccompare_a4zV, a4Ai :-> $c<_a4Ai, a4AF :-> $c<=_a4AF, a4B2 :-> $c>_a4B2, a4Bp :-> $c>=_a4Bp, a4BM :-> $cmax_a4BM, a4C9 :-> $cmin_a4C9, a4Cy :-> $c+_a4Cy, a4CV :-> $c-_a4CV, a4Di :-> $c*_a4Di, a4DF :-> $cnegate_a4DF, a4DY :-> $cabs_a4DY, a4Eh :-> $csignum_a4Eh, a4EA :-> $cfromInteger_a4EA, a4F3 :-> $ctoRational_a4F3, a4Fs :-> $c/_a4Fs, a4FP :-> $crecip_a4FP, a4G8 :-> $cfromRational_a4G8, a4GB :-> $cproperFraction_a4GB, a4Hg :-> $ctruncate_a4Hg, a4HV :-> $cround_a4HV, a4IA :-> $cceiling_a4IA, a4Jf :-> $cfloor_a4Jf, a4K0 :-> $cpi_a4K0, a4Kf :-> $cexp_a4Kf, a4Ky :-> $clog_a4Ky, a4KR :-> $csqrt_a4KR, a4La :-> $c**_a4La, a4Lx :-> $clogBase_a4Lx, a4LU :-> $csin_a4LU, a4Md :-> $ccos_a4Md, a4Mw :-> $ctan_a4Mw, a4MP :-> $casin_a4MP, a4N8 :-> $cacos_a4N8, a4Nr :-> $catan_a4Nr, a4NK :-> $csinh_a4NK, a4O3 :-> $ccosh_a4O3, a4Om :-> $ctanh_a4Om, a4OF :-> $casinh_a4OF, a4OY :-> $cacosh_a4OY, a4Ph :-> $catanh_a4Ph, a4PA :-> $clog1p_a4PA, a4PT :-> $cexpm1_a4PT, a4Qc :-> $clog1pexp_a4Qc, a4Qv :-> $clog1mexp_a4Qv, a4QY :-> $cfloatRadix_a4QY, a4Rh :-> $cfloatDigits_a4Rh, a4RA :-> $cfloatRange_a4RA, a4RT :-> $cdecodeFloat_a4RT, a4Sc :-> $cencodeFloat_a4Sc, a4Sz :-> $cexponent_a4Sz, a4SS :-> $csignificand_a4SS, a4Tb :-> $cscaleFloat_a4Tb, a4Ty :-> $cisNaN_a4Ty, a4TR :-> $cisInfinite_a4TR, a4Ua :-> $cisDenormalized_a4Ua, a4Ut :-> $cisNegativeZero_a4Ut, a4UM :-> $cisIEEE_a4UM, a4V5 :-> $catan2_a4V5, a4Vu :-> $c_c_a4Vu, a5eH :-> wild_a5eH, a5eJ :-> x_a5eJ, ruN :-> u, ruO :-> f1, ruP :-> f2, ruQ :-> f3, r24E :-> $tc'A, r25L :-> $tcA, r25N :-> $tc'B, r25Z :-> $tcB, r2dl :-> $tc'D, r2ds :-> $tcD, r2dF :-> $tcC, r2dG :-> $tc'C:C, r2dL :-> $fCB, r2dZ :-> $fEqB, r2ec :-> $fOrdB, r2nC :-> $fNumB, r2nK :-> $fRealB, r2nT :-> $fFractionalB, r2oa :-> $fRealFracB, r2oC :-> $fFloatingB, r2oX :-> $fRealFloatB, r4yJ :-> $trModule, s5iM :-> $trModule_s5iM, s5iN :-> $trModule_s5iN, s5iO :-> $tc'A_s5iO, s5iQ :-> $tc'B_s5iQ, s5iR :-> $tcB_s5iR, s5iS :-> $tc'D_s5iS, s5iT :-> $tcD_s5iT, s5iU :-> $tc'C:C_s5iU, s5iV :-> $tcC_s5iV, s5jw :-> $sf2_s5jw, s5jM :-> $sf1_s5jM, s5jU :-> labelvs_s5jU, s5k8 :-> $sf3_s5k8, s5ki :-> $sfromIntegral_s5ki, s5kD :-> $sminimum_s5kD, s5kE :-> $scomparing_s5kE, s5kF :-> $srealToFrac_s5kF, s5kG :-> $sfromIntegral_s5kG, s5kN :-> lvl_s5kN, s5kX :-> lvl_s5kX, s5lc :-> lvl_s5lc, s5ln :-> lvl_s5ln, s5pu :-> lvl_s5pu, s5pv :-> lvl_s5pv, s5ra :-> lvl_s5ra, s5rb :-> lvl_s5rb, s5Bi :-> $w$sf3_s5Bi, s5Bt :-> $wf3_s5Bt, s5Bx :-> w_s5Bx, s5BB :-> ww_s5BB, s5BF :-> $w$sf1_s5BF, s5BS :-> $wf1_s5BS, s5BW :-> $wf2_s5BW, s5D0 :-> $j_s5D0, s5FJ :-> lvl_s5FJ, s5FL :-> $wgo_s5FL, s5FM :-> lvl_s5FM, s5FN :-> lvl_s5FN, s5FP :-> karg_s5FP, s5FW :-> go_s5FW, s5FX :-> lvl_s5FX, s5FY :-> lvl_s5FY, s5FZ :-> lvl_s5FZ, s5G0 :-> lvl_s5G0, s5G1 :-> lvl_s5G1, s5G2 :-> lvl_s5G2, s5G4 :-> lvl_s5G4, s5G5 :-> lvl_s5G5, s5G6 :-> lvl_s5G6, s5G7 :-> lvl_s5G7, s5Io :-> $s$j_s5Io, s5Ip :-> $s$j_s5Ip, s5Ir :-> $sgo_s5Ir] tenv [] tenvFVs [] cenv [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] cenvFVs [s5Ij :-> sg_s5Ij, s5Ik :-> sg_s5Ik] tys [Ratio Integer] cos [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 07:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 07:25:59 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.c1db918c7e1408325a886e93bbc2d98b@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Regarding `wave4main`, the main problem seems to be destruction of a join point. The program contains an expression that looks like this: {{{ #!haskell runRW# (\ s -> letrec go s1 = let ... in (# s2, Array a b c #) in go s) }}} After a nested CPR transformation, it becomes: {{{#!haskell runRW# (\ s -> letrec $wgo s1 = let ... in (# s2, a, b, c #) in case $wgo s of (# s3, a', b', c' #) -> (# s3, Array a' b' c' #)) }}} destroying the join-point property of `go`. This is basically the same as what @nomeata found 2 years ago. I see two ways to move forward: 1. Wait for SequentCore to be implemented. 2. Have special cases for `runRW#` in the CPR analyzer and in the simplifier, as discussed in https://ghc.haskell.org/trac/ghc/ticket/10678#comment:10 I'm mildly interested in doing (2), but I don't think I fully understand the idea. In particular, the above comment mentions an example expression `case (runRW e) of BN# farr -> farr` that the simplifier would be able to transform. However, since `runRW#` returns an unboxed pair rather than a single boxed value, it seems that it would have to spot a much more complicated pattern to accomplish this transformation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 07:47:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 07:47:38 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.588c0356c5d39b8ec751fa1aae74bf61@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wait... how could inlining or not make a seg-fault? The above discussion shows that it can affect a boolean value, but not seg-fault! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 07:49:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 07:49:12 -0000 Subject: [GHC] #12756: ghci gives stg_ap_v_ret error In-Reply-To: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> References: <048.4049d069817f575ecdd154d4ced1ea8d@haskell.org> Message-ID: <063.0d9496275f42cd5a1a29a2dc81d6a8da@haskell.org> #12756: ghci gives stg_ap_v_ret error ----------------------------------+-------------------------------------- Reporter: ryanreich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by simonpj): Writing out of bounds with `unsafeWrite` is surely a library error, no? Can't we just fix it? Amaxing work to figure out what it was -- thank you AlexET! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 07:55:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 07:55:24 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.78eeb5f6b8cf991e5372a477a6f298f8@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 simonpj): I'm all for eliminating busy-work, but my experience is that we have too few, not too many, performance tests. Mostly, when a perf-test fails, there really is something to investigate, annoying though I often find it. The exception is `max_bytes_used` which wobbles around unpredicatably. I'm not sure how your new approach would make things better. Would you like to elaborate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:16:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:16:31 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.92cb06836a0c7ad4f7bbac6670cbf5dd@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Generally the patch looks good to me, thank you. But can we first agree about goals and nomenclature. * Minor: you use the term "concat" in the implementation, but the list `concat` function has type `[[a]] -> [a]` not `[a] -> [a] -> [a]`. We generally use "append" for the latter; e.g. `appendFS`. * In order to do this you have figured out how to add a new type-level operator to GHC. Is that written up on the wiki anywhere? If not it'd be great if you could do so? There are a number of separate things you have to do. [wiki:TypeNats] would be a good place to start, despite its Nat- sounding title. * More significant. You are introducing a type-level operator `(<>) :: Symbol -> Symbol -> Symbol`. Wouldn't `(++)` be more appropriate? It's type is very like `(++)`. The other use of `(<>)` that I know of is in the pretty printing library, where it has type `Doc -> Doc -> Doc` so there is precedent there. I think it partly depends on whether we are regarding `Symbol` as an opaque type; in which case we might want to keep `(++)` for appending type-level lists (or does it exist already?). But #11342 is (I think) arguing for a less opaque representation. * Incidentally I realise that I don't know how to find the Haddock docs for the functions available over `Symbol`.... I'm copying in the core libraries committee, since this is really their territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:17:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:17:59 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.5610e7f46646e47f534ea0450e3b6fc5@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:35:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:35:04 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.11a34a423843d787178414c87bcf2941@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): * good point about `append` vs. `concat` , append will be definitely better * As said in the Phab, I mostly copied things from existing magic type families. E.g. there are comments like `(a + 5 ~ 8) => (a ~ 3)`, which I tried to reproduce for `(<>)`, but I didn't managed to find any tests exercising those code paths (I didn't spent too much time looking though). 1f77a5341cbd6649a6bc2af868002728cd79b9d7 patch added most of the `TcTypeNats.hs`, I guess it make sense to add refined parts of commit message to the wiki. Will do. * I personally think `(<>)` is more appropriate than `(++)`. I had an idea to make `(<>)` polykinded `:: forall k. k -> k -> k` with the `Symbol` instantiation as a magic one. But it seems to be easier to leave the abstracting part to the userland, and have magical monomorphic type. So it might make sense to not use any operator name at all, but a name like `AppendSymbol`, and define `<>` to work on symbols and lists in `base` or some other type-level trickery library. * FWIW, I think there aren't any other places with functions over `Symbol` than the ones in `GHC.TypeLits`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:35:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:35:31 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.59be1f1938305a7cdfaf3da5e9032a9e@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: maurerl@… (added) Comment: Let's do (1); it's nearly ready! Akio, Luke (now in cc), can you work together on this? Luke has a pretty stable join-point branch which never destroys join points. Best just to build on that I think. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:45:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:45:41 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.1e6947d0b4fe9e5733c51a27c6a5ea30@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): I have an example that may or may not capture the original case 2 (allocation bloat due to INLINE, here by a factor of 2000). Perhaps it's just INLINE pushing the subexpression `mapVT n` over the threshold where some kind of simplification and/or floating out is not done any more. If it's interesting, please let me know and I will file a new bug report. {{{ {-# LANGUAGE BangPatterns, RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM import Data.List import Data.Maybe -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P !Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE -- -- with INLINE: -- 384,409,080 bytes allocated in the heap -- with NOINLINE: -- 169,080 bytes allocated in the heap dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (y, _) = pI `quotRem` z in P y !_ = isJust $ IM.lookup (fromEnum p0) IM.empty !_ = isJust $ IM.lookup (fromEnum p1) IM.empty in () mapVT :: forall s. Int -> ST s () {-# NOINLINE l #-} l = [0..1600] {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l !runRes = foldl' (\() n -> runST (mapVT n)) () [1..10000] return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 08:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 08:49:29 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.60e1342a8256b9153f95a2cc5b465399@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > ghc needs to be compiled with BuildVlavour = devel2 Which exact version of GHC are you building? Can you try with the `ghc-8.0` branch? I don't get this assertion failure when compiling the module you give above; and it might well have been fixed. Is this a show-stopper for you? This particular assertion failure is almost certainly not a problem; we should fix it (that's why it's there) but it probably won't cause any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 09:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 09:34:31 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.837ce945cbcfd3408cd23b98b3f7e84a@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): I'm compiling this: 8.0.1 + some fixes on top {{{ * 3971db9 (HEAD) Get in-scope set right in top_instantiate simonpj at microsoft.com 4 months ago * eedd604 Build a correct substitution in dataConInstPat niteria at gmail.com 6 months ago * 4091505 Fix the in-scope set for extendTvSubstWithClone simonpj at microsoft.com 4 months ago * 4986837 (tag: ghc-8.0.1-release) rules/build-prog: Ensure programs depend upon their transitive deps ben at smart-cactus.org 5 months ago }}} It is not a show stopper, but it stops me from trying devel2 compiler on our codebase and there we have strange compilation failures. I will try to build it with most recent branch and will let you know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 09:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 09:41:25 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.4f7b4508e3316c7992579d64baef7ea0@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK thanks. While I could build 8.0.1 + some fixes, I'd much prefer to focus attention on the 8.0.2 candidate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:21:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:21:09 -0000 Subject: [GHC] #12427: Type inference regression with RankNTypes (GHC 8.1) In-Reply-To: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> References: <045.c0f95031d5d84dce2d172c79ab762b36@haskell.org> Message-ID: <060.fc93c91df46955c70f2304e4b9a48bf4@haskell.org> #12427: Type inference regression with RankNTypes (GHC 8.1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: RankNTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12427a, b Blocked By: | Blocking: Related Tickets: #12431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T12427a, b * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:32:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:32:18 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.4dca0174a3fb8b2a35619fecc197356b@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): It compiles with no errors with current HEAD. I guess I will make sure to check all subsequent problems with the most recent version or will try to compile as much as possible with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:44:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:44:17 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.c2fb356e44b580d17c28eba11a115088@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually we really don't want to disable ALL unfoldings, just unfoldings for imported things. Locally-bound things (esp in local lets) should be fine. I suppose that means that every use of `idUnfolding` has to be guarded with a test of `DynFlags`. The "is it imported?" test can be `isLocalVar`. I took a look at uses of `idUnfolding`. * Some, like `idUnfoldingFVs` can be dealt with by testing for `isLocalVar`. Global vars will have no fvs, so no point in looking at the unfolding. This might even improve perf! * Some, like the use of `idUnfolding` in `CoreLint` are guaranteed to be on a `LocalId`, so that can be an assertion. * The`isCompulsoryUnfolding` in `CoreSubst` is OK; we do want to inline conpulsory unfoldings regardless. Etc. It's tiresome to look at all these call sites, but I see no alternative. We have an Id that does ''have'' an unfolding, but we don't want to look at it.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:46:55 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.93075b99f9a0c5d551ca8e2548407505@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): HEAD is good, thanks. But what about `ghc-8.0` branch? That's the release candidate for 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:49:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:49:57 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.40aa212b65fb7627ff2e6f93b6a837ab@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Still compiling, will let you know as soon as it's done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 10:52:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 10:52:11 -0000 Subject: [GHC] #11186: Give strong preference to type variable names in scope when reporting hole contexts In-Reply-To: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> References: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> Message-ID: <060.8497c8cb480b304d5614785b17eb1c08@haskell.org> #11186: Give strong preference to type variable names in scope when reporting hole contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: typed-holes 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 simonpj): > May I ask what you think will be hard about this? Well, the message prints the type of `[r]`, and the type is the ''same in both cases''. Your point, which is a reasonable one, is that you'd like the type to be rewritten to make sense in the current lexical context, whatever that is. I don't think that would be too hard. The current lexical environment maps, say `pah :-> t8`, where `t8` is the variable GHC chose for the argument type of `q`. So we could reverse-map back from `t8` to `pah`. Not hard, but more than the work of a moment. I can advise if someone wants to have a go. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 12:22:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 12:22:03 -0000 Subject: [GHC] #12760: Assertion failed with BuildFlavour = devel2 (yet another) In-Reply-To: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> References: <044.fa5cb64a5da3d22857a51b2d16995d4a@haskell.org> Message-ID: <059.c2ea0fb3f398f5cfe4f53bf3765de2ef@haskell.org> #12760: Assertion failed with BuildFlavour = devel2 (yet another) -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Compiles as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:01:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:01:52 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.5478f8bca232c144e99bb9b9701d0d7c@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm indifferent about what to name `(<>)`, but the fact that someone has objected to it means it might be worth starting a thread on the [https://mail.haskell.org/pipermail/libraries/ libraries mailing list] to figure out the community's opinion. I've heard convincing arguments for both `(<>)` and `(++)`. Or `(+++)`, which is what the [https://github.com/konn/ghc-typelits- symbols/blob/cd812f4cfc2e6816a18283a6a0e9bb2d9ea2905e/src/GHC/TypeLits/Symbols/Internal.hs#L6-L8 ghc-typelits-symbols] GHC plugin library has taken to calling this operation. Or `AppendSymbol`, if we really want to explore all options. If you wish to add tests for this feature, there is a portion of the GHC test suite located in `base` [http://git.haskell.org/ghc.git/tree/HEAD:/libraries/base/tests here]. And you're absolutely correct in observing that the `Symbol` API is quite feature-poor at the moment. OtToMH, there are only three useful operations over `Symbol`s in `base`: * You can check whether two symbols are equal (either through type-level equality or through [http://hackage.haskell.org/package/base-4.9.0.0/docs /GHC-TypeLits.html#v:sameSymbol sameSymbol]). * You can compare two symbols lexicographically with [http://hackage.haskell.org/package/base-4.9.0.0/docs/GHC- TypeLits.html#t:CmpSymbol CmpSymbol]. * You can convert a `KnownSymbol` to a `String` value with [http://hackage.haskell.org/package/base-4.9.0.0/docs/GHC- TypeLits.html#v:symbolVal symbolVal]. And that's about it. While it'd be nice to have promoted lists of `Char`s and just promote all operations over lists, that's much more work, and `Symbol`'s all we've got for now, so we might as well work with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:13:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:13:17 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.8a2770b41d1162398a329fa3541e936f@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've done a bisection of this on `ghc-8.0`; according to the bisection the culprit is 2a9767ed596679ddf21b7edfa9fc6410443c2a01. I have yet to verify that reverting on `ghc-8.0` `HEAD` fixes the issue. I'm currently waiting for a build to confirm this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:27:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:27:56 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.eef5dd3be0bb3170d8bfc8f27abcaceb@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:34:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:34:50 -0000 Subject: [GHC] #7808: data families and TH names do not mix well (e.g. cannot use TH deriving) In-Reply-To: <045.dda1757ce74af37f80842c4fd3fa6323@haskell.org> References: <045.dda1757ce74af37f80842c4fd3fa6323@haskell.org> Message-ID: <060.f35c3b7f4dc1298f87f2930239edfd38@haskell.org> #7808: data families and TH names do not mix well (e.g. cannot use TH deriving) -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.2 Resolution: | Keywords: TypeFamilies 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 RyanGlScott): Apologies for commenting on an extremely old Trac ticket. The way I tackle this problem in libraries like `bifunctors` (see [http://hackage.haskell.org/package/bifunctors-5.4.1/docs/Data-Bifunctor- TH.html#v:deriveBifunctor Data.Bifunctor.TH]) is by allowing functions of the form `:: Name -> Q a` to take either a type constructor `Name` (for a plain datatype) or a data constructor `Name` (for a data family instance). The TH code is able to look up the original data family instance from any of its data constructor names, so it works, although it's a bit awkward. There's also the drawback that you can't do this trick for data family instances with no constructors... but how useful are those, really? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:40:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:40:46 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.eb52b048569e4d31b6e985d31bcb168e@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:45:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:45:02 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.3a33bc171be58d725203c6a5239fc046@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:49:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:49:56 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.ee38b039ad9d51018731fb1dbf311f1d@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf 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 RyanGlScott): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:55:43 -0000 Subject: [GHC] #12761: Type aliases for TypeError constrains fire during compilation time Message-ID: <046.6515363a438696f6792947ccce1be968@haskell.org> #12761: Type aliases for TypeError constrains fire during compilation time -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! The following code should compile fine: {{{ module Main where import GHC.TypeLits (ErrorMessage(Text, ShowType, (:<>:)), TypeError) type MyError a b = TypeError (ShowType a :<>: ShowType b) main :: IO () main = return () }}} but it raises an error during compilation: {{{ Main.hs:5:1: error: • ab • In the type synonym declaration for ‘MyError’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:57:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:57:53 -0000 Subject: [GHC] #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving In-Reply-To: <045.f9bffd180044243f5d493b11cf11851d@haskell.org> References: <045.f9bffd180044243f5d493b11cf11851d@haskell.org> Message-ID: <060.a8c85c297647e4bc00df918090fe4516@haskell.org> #12639: Inconsistent treatment of FlexibleInstances and MPTCs with standard vs. flexible deriving -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 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 RyanGlScott): I have some opinions on both of these suggestions, but I'll refrain from posting them here. Before that, if you really want to see these changes make it into GHC, you should propose them as a post to the [https://mail.haskell.org/mailman/listinfo/ghc-devs GHC devs mailing list]. In particular, your second proposed item would cause a //lot// of code in the wild to break, so we need to discuss it more thoroughly to ensure it's a breakage we want to endorse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 13:58:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 13:58:52 -0000 Subject: [GHC] #12761: Type aliases for TypeError constrains fire during compilation time In-Reply-To: <046.6515363a438696f6792947ccce1be968@haskell.org> References: <046.6515363a438696f6792947ccce1be968@haskell.org> Message-ID: <061.cc50e143284e4a71cd55350fdb4e1ca2@haskell.org> #12761: Type aliases for TypeError constrains fire during compilation time -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:03:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:03:02 -0000 Subject: [GHC] #12762: ASSERT failures on HEAD following typechecker refactoring Message-ID: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> #12762: ASSERT failures on HEAD following typechecker refactoring -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Erik says {{{ I suspect these commits 3f5673f34a2f761423027bf46f64f7499708725f may be responsible for 11 test failures: Unexpected results from: TEST="T9857 T12007 T9732 T9783 T9867 unboxed-wrapper-naked match-unboxed num T12698 T4439 unboxed-wrapper" SUMMARY for test run started at Sun Oct 23 16:56:26 2016 AEDT 0:00:02 spent to go through 11 total tests, which gave rise to 47 test cases, of which 36 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 11 unexpected failures 0 unexpected stat failures Unexpected failures: deSugar/should_compile/T4439.run T4439 [exit code non-0] (normal) ghci/scripts/T12007.run T12007 [bad stderr] (ghci) patsyn/should_compile/num.run num [exit code non-0] (normal) patsyn/should_compile/T9732.run T9732 [exit code non-0] (normal) patsyn/should_compile/T9857.run T9857 [exit code non-0] (normal) patsyn/should_compile/T9867.run T9867 [exit code non-0] (normal) patsyn/should_compile/T12698.run T12698 [exit code non-0] (normal) patsyn/should_fail/unboxed-wrapper-naked.run unboxed-wrapper-naked [stderr mismatch] (normal) patsyn/should_run/T9783.run T9783 [exit code non-0] (normal) patsyn/should_run/match-unboxed.run match-unboxed [exit code non-0] (normal) patsyn/should_run/unboxed-wrapper.run unboxed-wrapper [exit code non-0] (normal) }}} SPJ says: indeed! Fixing now. I hadn't compiled the testsuite with DEBUG on, and doing so indeed shows up two lurking bugs! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:07:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:07:20 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.c83d9c2195a0135513c7cb16dca88d36@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #2721 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:07:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:07:53 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.7ecd035e0ca44f928f2d04e8b287b8f2@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #8165 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:09:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:09:42 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.ba25253f56d66ba8d7c404d30eb329e8@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2633 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) * status: new => patch * differential: => D2633 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:16:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:16:33 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow (was: Unexpected context reduction stack overflow) In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.ad0cfb1a0e3bc6d48e928330aa83a6ea@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a cut-down version: {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeApplications #-} module T12734 where import Prelude import Control.Applicative import Control.Monad.Fix import Control.Monad.Trans.Identity import Control.Monad.Trans.Class import Control.Monad.IO.Class data A data B data Net data Type data Layer4 t l data TermStore -- Helpers: Stack data Stack lrs (t :: * -> *) where SLayer :: t l -> Stack ls t -> Stack (l ': ls) t SNull :: Stack '[] t instance ( Con m (t l) , Con m (Stack ls t)) => Con m (Stack (l ': ls) t) instance Monad m => Con m (Stack '[] t) instance ( expr ~ Expr t lrs , Con m (TStk t lrs)) => Con m (Layer4 expr Type) newtype Expr t lrs = Expr (TStk t lrs) type TStk t lrs = Stack lrs (Layer4 (Expr t lrs)) class Con m t -- HERE IS A FUNNY BEHAVIOR: the commented line raises context reduction stack overflow test_gr :: forall m t lrs bind. ( Con m (TStk t lrs) , bind ~ Expr t lrs -- ) => m (Expr t lrs) -- Works with this line ) => m bind -- Does not work with this line test_gr = undefined newtype KT (cls :: *) (t :: k) (m :: * -> *) (a :: *) = KT (IdentityT m a) test_ghc_err :: KT A '[Type] IO (Expr Net '[Type]) test_ghc_err = test_gr @(KT A '[Type] IO) @_ @'[Type] @(Expr Net '[Type]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:33:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:33:48 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.dbf017571df57f72fc7c25c364c239eb@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I know what is going on. With the cut-down example above, when checking the cod for `test_ghc_err` we are faced with {{{ [W] Con m (TStk t lrs) where m := KT A '[Type] IO bind := Expr Net '[Type] t := Net lrs := '[Type] }}} The `:=` are unifications that can take place pretty eagerly. Now let's try solving that wanted constraint {{{ [W] Con m (TStk t lrs) = (Type synonym) [W] Con m (Stack lrs (Layer4 bind)) = (inline lrs) [W] Con m (Stack '[Type] (Layer4 bind)) --> instance decl for (Con m (Stack (l :' ls) t)) [W] Con m (Stack '[] bind) [W] Con m (Layer4 bind Type) The first of these rapidly reduces to (Monad m). The second is harder: [W] Con m (Layer4 bind Type) --> instance decl for (Con m (Layer4 expr Type) [W] bind ~ Expr t0 lrs0 -- C1 [W] Con m (TStk t0 lrs0) -- C2 where t0, lrs0 are fresh unification variables. If we simplify (C1), using the fact that bind := Expr Net '[Type] we get t0 := Net lrs0 := lrs And now we have (C2): [W] Con m (TStk Net lrs) which is the very same thing we start with. So we can "tie the knot" via the `inert_solved_dicts` and we are done. }}} This makes essential use of GHC's ability to solve a set of constraints with a ''recursive'' dictionary binding. So what goes wrong? * If we fail to prioritise C1 over C2, we'll embark on simplifying C2, not spotting the loop. Result: an infinite regress. * We do prioritise equality constraints * But C1, namely `bind ~ Expr t0 lrs0` is actually a ''class'' constraint, not an equality. It has a built-in reduction to the homogeneous-equality class constraint `bind ~~ Expr t0 lrs0`; and that in turn has a built-in reduction to the true equality constraint `bind ~# Expr t0 lrs0`. So a solution that works is to prioritise the two equality-class constraints `t1 ~ t2` and `t1 ~~ t2` just as we do equality constraints. That's a good thing to do anyway. But I'm concerned that it does not truly solve the problem. Two worries: * To "tie the knot" we rely on saying "I've see this goal before". But to be sure of that we should rewrite `inert_solved_dicts` with the current substitution, and currently we don't do that. Maybe we should. It's more work but we might in exchange sometimes get more sharing. * What if we have a class constraint `(C t1 t2)` where C has a perhaps- distant superclass `(s1 ~ s2)`. Then should we prioritise the `(C t1 t2)` constraint? But the superclass might not even be revealed until we do some reduction on `(C t1 t2)`. This way lies madness. I think wes should not even attempt to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:53:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:53:18 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.ea677501b123c53561897db347ef00bf@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 RyanGlScott): * cc: RyanGlScott (added) Comment: I feel like batterseapower is arguing for a change in the way associated family instances work at a fundamental level. To illustrate what I mean, consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where data D a c :: a -> a -> Bool instance Eq a => C [a] where newtype D [a] = DList [a] c = (==) dlist :: D [a] dlist = DList [] }}} Notice that I was able to construct a value of type `D [a]` without needing an `Eq a` constraint! That flies in the face of the fact that the `C [a]` instance does seem to require an `Eq a` constraint—rather, it requires an `Eq a` constraint, but only when typechecking its associated methods. For better or worse, the `D [a]` family instance appears to be pretty much independent of the `C [a]` instance (and its methods). So if we accept batterseapower's proposal above and propagate class constraints down to the associated family instances as well, would it be correct to say that my example code would now fail to typecheck? Is this desirable behavior? I don't really understand the intricacies of associated family instances that well, so perhaps there is a reason that the current design is the way it is. I'd need Simon's judgment to know for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 14:56:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 14:56:05 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.225b91ac7c56e0200f52b3637061f29c@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 nomeata): Allright, it is done, and I can report back. Introducing `ConApp` (without any compression) was quite tedious, and for me, rather two than one week. By now, it validates (almost; the GHCi debugger shows some difference in behaviour that I did not investigate) and shows the same runtime performance. The most tricky points are related to rules, which really do not like it if eta-expansion changes the Core too much. It took me a while to get equivalent program output after this refactoring (and I took a shortcut for now, duplicating some list fusion rules that match `build (:)` to have a second variant matching `build (\x y -> x : y)`). With a bit more careful work, this could be fixed, should we want this code to be merged. This change on its own affected some compiler perf benchmarks in the test suite: T9961 improves by 13%, T9233 by 2.5%., T9020 by 2.5%. T4801 regresses by 3.87% (bytes allocated) I then, in a separate patch, implemented omitting redundant type arguments from constructors such as `Just`, `(:)` and tuples, which was the main motivation here. At every use of `ConApp`, I tried to understand the code as to whether it actually cares about the type arguments (which means that the they need to be recovered) or not (in which case the compressed argument list can be traversed, which is of course more efficient). In these places I had to uncompress the type arguments: * `freeVars` (which also calculates the types) * The linter * `cpeRhsE` * `exprIsConApp_maybe` * `exprType` * `collectStaticPtrSatArgs`, `sptModuleInitCode` (all about static pointer tables) * `decomposeRuleLhs` in the desugarer * `toIfaceExpr` when serializing tuples (low-hanging fruit here) * `match_magicDict` * `occAnal` * `simplExprF1` * `isValue` is `specConstr` I found that it is crucial to analyze the type of the data constructor only once, and store the “compression scheme” (i.e. which type arguments to recover form which term arguments) once in the data constructor, as this analysis is not completely cheap. But even with this optimization in place, the effect of this is – neglectible. My gut feeling: * `ConApp` is not a good idea in this form. Constructor applications are still just applications, and treating them that separately is not going to be healthy. It might be a better idea to make ''all'' applications saturated (as in strict core, or less invasive, “spotty types”). * The compression scheme is nice in principle, but there are still too many code paths that want the types. Some might be taken off the list after careful analysis of the code and mild refactoring. In others, making sure that the type in a `Type` data constructor is used as lazily as possible might help avoiding actually running `exprType` (this is a blind guess). * Furthermore, the large types that occur with nested tuples are already in the type checker! So avoiding them in Core is only half the story. * If compression would make a difference, then I think we want it at all applications (or at least applications headed by an `Id`, where we could store the compression scheme). Another point in favor of making all applications saturated. As for the problem of nested tuples: Maybe it would have been better to first carefully analyze the compiler (using `-v`/profiling/ticky-ticky) to be sure where we pay the unwanted cost (type checking, Core, interfaces, somewhere else) to know what we have to fix, before having a shot at one assumed cause. The code is at Phab:D2564. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 15:00:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 15:00:52 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.745529f93f5cad87715894be43fad9c2@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 MikolajKonarski): Here is an even simpler version of INLINE allocation bloat, but with less difference vs NOINLINE. I guess virtually every feature of this example is needed to trigger the bloat. {{{ {-# LANGUAGE RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE and observe lower alloc dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (_, x) = pI `quotRem` z in P x m = IM.lookup (fromEnum p0) IM.empty b = IM.member (fromEnum p1) IM.empty in m == Just 'c' `seq` b `seq` () {-# NOINLINE l #-} l = [0..10000000] mapVT :: forall s. () -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l return $! runST (mapVT ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 15:30:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 15:30:46 -0000 Subject: [GHC] #12731: Generic type class has type family; leads to big dep_finsts In-Reply-To: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> References: <045.75a7a15ad86cb6ca54991618e231cc61@haskell.org> Message-ID: <060.3fd323554fe6966e8c28b3faa1c7d4b8@haskell.org> #12731: Generic type class has type family; leads to big dep_finsts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Generics 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 RyanGlScott): * keywords: => Generics * cc: RyanGlScott (added) Comment: As you've discovered, it's possible to manually define `Generic` instances (as long as Safe Haskell isn't enabled, I might point out). But even if we restrict `Generic` instances to only be derived, I don't think that would guarantee they don't overlap. After all, you can do this (requires GHC 8.0 or later): {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE StandaloneDeriving #-} import GHC.Generics data Foo a = Foo a deriving instance {-# OVERLAPPABLE #-} Generic (Foo a) deriving instance {-# OVERLAPPING #-} Generic (Foo Int) }}} We used to forbid `Generic` instances like `Generic (Foo Int)` (see #5939), but reverted that decision when we found out that it wreaked havoc with sufficiently poly-kinded `Generic1` instances that require kinds to be instantiated with `*` (see #11732). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:10:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:10:29 -0000 Subject: [GHC] #12618: Add saturated constructor applications to Core In-Reply-To: <046.22cf3f9084aee871c2af64177631d815@haskell.org> References: <046.22cf3f9084aee871c2af64177631d815@haskell.org> Message-ID: <061.dce133762e855e62da369529834a13ce@haskell.org> #12618: Add saturated constructor applications to Core -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): I did a full implementation of System IF some years ago, and concluded (like you) that the pain is not worth the gain. Your point that the type checker is building these very big types in the nested-tuple case is an excellent one. I don't have any brilliant ideas, I'm afraid. But this is an excellent data point. Is Phab a good place to keep the patch long-term, or would it be best pushed into the GHC repo? Good work, even if disappointing! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:16:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:16:37 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.eb8f6a1fbbf76d0ba96390c99bea375e@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 simonpj): I think Max was asking for something less fundamental. He just wanted the `deriving` clause on the original instance decl to infer an instance context of `Eq (Associated a)`. That's usually not allowed for `deriving` clauses but he argues that in the context of a class instance decl, it should. So it's just to do with the relatively narrow question of "what context does one infer for a deriving clause?". Since the standalone deriving clause is available, I'm inclined to say "use the standalone route". It's just clearer. But I'm not terribly bothered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:23:19 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.44da7966a5a781111289b84b1bd27746@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.3 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash | types/should_fail/T12386 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_fail/T12386 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ commit 3f5673f34a2f761423027bf46f64f7499708725f Author: Simon Peyton Jones Date: Tue Sep 20 23:31:07 2016 +0100 A collection of type-inference refactorings. This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:32:06 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.036846574fc1cc490821226f0e34f653@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1c4a39d3a8d36803382792ff78b4709794358883/ghc" 1c4a39d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c4a39d3a8d36803382792ff78b4709794358883" Prioritise class-level equality costraints This patch fixes Trac #12734 by prioritising the class-level variants of equality constraints, namely (a~b) and (a~~b). See comment:10 of Trac #12734 for a description of what went wrong, and Note [Prioritise class equalities] in TcSMonad. The fix is still not great, but it's a definite step forward, and cures the particular problem. Worth merging to 8.0. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:32:07 -0000 Subject: [GHC] #12762: ASSERT failures on HEAD following typechecker refactoring In-Reply-To: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> References: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> Message-ID: <061.7aa705320a7378cec0f1ce55a12a27ec@haskell.org> #12762: ASSERT failures on HEAD following typechecker refactoring -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"1221f8104bb5123c18bd5b840cde9ab2e71247d5/ghc" 1221f81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1221f8104bb5123c18bd5b840cde9ab2e71247d5" Don't instantaite when typechecking a pattern synonym Fixes most of the cases in Trac #12762 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:32:07 -0000 Subject: [GHC] #12762: ASSERT failures on HEAD following typechecker refactoring In-Reply-To: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> References: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> Message-ID: <061.4272f6646a3fe49fa872922d0a8dc564@haskell.org> #12762: ASSERT failures on HEAD following typechecker refactoring -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"08ba691ad55f30e67466628125244392c48ce1ab/ghc" 08ba691/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08ba691ad55f30e67466628125244392c48ce1ab" Take account of kinds in promoteTcType One of the ASSERT failures in Trac #12762, namely the one for T4439, showed that I had not dealt correctly with promoting the kind of a type in promoteTcType. Happily I could fix this by simplifying InferRes (eliminating the ir_kind field), so things get better. And the ASSERT is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:32:07 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.a4e777b00d918ddee2fb85d437c468f9@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 Simon Peyton Jones ): In [changeset:"03b0b8e43ff43365fc52a92d8ff18558f4ee8202/ghc" 03b0b8e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03b0b8e43ff43365fc52a92d8ff18558f4ee8202" Test Trac #12174 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:34:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:34:25 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.8fffca1b9cbed6a880c877680587dbb7@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T12714 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => dependent/should_fail/T12714 * resolution: => fixed Comment: Works in HEAD. I doubt it's worth trying to track the fix down for the 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:37:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:37:32 -0000 Subject: [GHC] #12081: TypeInType Compile-time Panic In-Reply-To: <047.ceeb8e791a978943694d6a174084488b@haskell.org> References: <047.ceeb8e791a978943694d6a174084488b@haskell.org> Message-ID: <062.42ebadbe3b49ce34227eda95e5f173cb@haskell.org> #12081: TypeInType Compile-time Panic -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"853cdaea7f8724cd071f4fa7ad6c5377a2a8a6e4/ghc" 853cdaea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="853cdaea7f8724cd071f4fa7ad6c5377a2a8a6e4" Test Trac #12081 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:37:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:37:58 -0000 Subject: [GHC] #12081: TypeInType Compile-time Panic In-Reply-To: <047.ceeb8e791a978943694d6a174084488b@haskell.org> References: <047.ceeb8e791a978943694d6a174084488b@haskell.org> Message-ID: <062.b72279f53a37df3b1f6d1bb44999ba0a@haskell.org> #12081: TypeInType Compile-time Panic -------------------------------------+------------------------------------- Reporter: MichaelK | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | dependent/should_fail/T12081 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => dependent/should_fail/T12081 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:38:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:38:18 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.bca61df2959515d41014aa3b105a52cc@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T12174 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: dependent/should_fail/T12714 => dependent/should_fail/T12174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:40:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:40:36 -0000 Subject: [GHC] #12507: Can't deduce implicit parameter In-Reply-To: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> References: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> Message-ID: <066.931a0e8dfc3ffd8136bc06e67b671f3a@haskell.org> #12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12507 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T12507 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:41:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:41:28 -0000 Subject: [GHC] #12762: ASSERT failures on HEAD following typechecker refactoring In-Reply-To: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> References: <046.4c586b501d351ca91cb19f73c48d7b05@haskell.org> Message-ID: <061.af98d77b02fb984d23ef00abc7db4e4b@haskell.org> #12762: ASSERT failures on HEAD following typechecker refactoring -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 simonpj): Erik, can you try again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 16:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 16:41:54 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.81c8d2d8b87e94912c8e9666060f727d@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): danilo2: maybe try HEAD? Should be fixed, I hope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 17:35:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 17:35:30 -0000 Subject: [GHC] #12706: Collecting type info is slow In-Reply-To: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> References: <048.46558b94dab961bc2f1f1afabbe58413@haskell.org> Message-ID: <063.e39eb6a41c88dc3773f416f712d51b02@haskell.org> #12706: Collecting type info is slow -------------------------------------+------------------------------------- Reporter: vshabanov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 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 vshabanov): I tried profiled compiler. Unfortunately I don't know GHC internals well enough to fix it but, anyway, here are my findings. Most time is spent in source:ghc/ghc/GHCi/UI/Info.hs Half time is spent in `typecheckModule` call and another half in `everythingAllSpans`. First problem here is a bad `cacheInvalid` function. It checks file time of object file, but there are no object files in GHCi. So types are always collected for all modules instead of new/modified ones. I don't know how to correctly check what files were recompiled but it's the first thing to do to shorten "Collecting type info" phase. Clearing cache on `:l` in GHCi is also necessary to free memory. I'm also not sure about call to `typecheckModule`. Aren't modules already type checked? Maybe it's possible to get type check results that were already calculated. Harder thing to do is to optimize `everythingAllSpans`. It uses SYB approach to extract `LHsBind`, `LHsExpr` and `LPat` from `TypecheckedSource = Bag (Located HsBindLR)`. It could be rewritten using direct recursion over `HsBindLR` without `cast` and `gmapQ`. But it looks like quite a big task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 17:38:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 17:38:09 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.d7c95faafe894181e5212d1036425bdc@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 RyanGlScott): I would also be inclined to say "use the standalone route", for the reason that I don't see any reason why the `deriving` clause would infer `Eq (Associated a)` given the current state of things. I was merely imagining a hypothetical scenario in which data family instances //would// reasonable infer such a constraint when deriving instances. If data family instances were more tightly intermingled with their parent instances in terms of instance contexts, I could envision this being the case. P.S. Do you know why GHC decides `DList [] :: D [a]` instead of `DList [] :: Eq a => D [a]`? That is, why GHC chose to make associated data family instance contexts separate from their parent instances' contexts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 17:53:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 17:53:33 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies Message-ID: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a corner case, but it would appear that GHC doesn't do proper improvements for classes with "empty" functional dependencies. Consider the following example: {{{#!hs class C a | -> a where m :: a -> () instance C Int f x = m x }}} The inferred type for `f` is `C a => a -> ()`, however I was expecting it to infer `Int -> ()`. The reasoning is as follows: the use of `m` generates a `C a` constraint (`a` is a unification variable). This should have interacted with the `C Int` instance (in a rather odd vacuous sort of way) to generate a derived constraint `a ~ Int`, which should have then instantiated `a` to `Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 18:28:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 18:28:48 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.7888b161390880b1187d1df30dd650da@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pumpkin): Replying to [comment:6 simonmar]: > The linker should mmap RW during linking and them remap RX when linking is complete. I think the new m32 allocator will make things a more difficult though, because it maintains partial pages of linked code, and we can't remap one of those pages from RX to RW since it might already be in use. I think grsecurity tracks writability history as well, so it forbids a page from being executable that was ever writable (by a given process) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 20:51:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 20:51:34 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.a5a7669a68df1d2ed99db6f1481a7ae5@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm... what code would generated in this example? {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} import Data.Kind class C (a :: k) where type T k :: Type instance C Int where type T Type = Int -------------------- newtype MyInt = MyInt Int deriving C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 21:13:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 21:13:37 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.cf087ab025bbd55e36d2d6cdb107be26@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The definition of `C` should be illegal since it doesn't mention the variable `a`. Apparently that hasn't been fixed yet though, I thought it was? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 21:16:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 21:16:24 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.0474e38fc592aab1e5e0ea687cda2f6f@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 rwbarton): Can data family (or type family) instances even have contexts? What is that supposed to mean? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 23:13:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 23:13:28 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.10a184c742604d6efede807e63939372@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Why should `C` be illegal? The type parameters of `T` are a permutation of a proper subset of the class parameters (`a` and `k`), so it [https://wiki.haskell.org/GHC/Type_families#Associated_family_declarations_2 should be legal]. But moreover, I think the answer to my question in comment:14 is: you can't newtype-derive `C` for `MyInt`, as there's an associated type that //doesn't mention the last type parameter of `C`//. This is crucial, because if this doesn't hold, then we won't have a `T` instance to fall back on, making the whole derivation crumble. We'd just need to check for this condition beforehand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 23:16:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 23:16:30 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.758279005310a8e2d867b5704dc6765c@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh that is a strange condition, but okay. (Maybe what I was thinking about was a new sanity condition on associated type instances, not their declarations.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 23:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 23:18:48 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.b4692cd412607af69b0c3f2c4316266e@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 RyanGlScott): What I mean is: if you had this code (using the example in comment:10): {{{#!hs c' :: [a] -> [a] -> Bool c' = c }}} then it would fail to typecheck, as there's no `Eq a` constraint, as mandated by the context in `instance Eq a => C [a]`. What I am asking is simply: should this `Eq a` constraint also be required for the associated family instances as well? That is, should this typecheck, even though it has no `Eq a` constraint? {{{#!hs dlist :: D [a] dlist = DList [] }}} (Currently, it //does// typecheck.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 23:38:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 23:38:40 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.9199c034e7742e1b9a6ec012483d359d@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 rwbarton): I would expect it to type check, because an associated family instance is sugar for an ordinary data family instance and I can't understand what it would mean to put a constraint on such an instance (or why I would want to; it feels like the old datatype contexts). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 24 23:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 24 Oct 2016 23:48:56 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.f0b742a50dd522884ead34263e54e751@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 RyanGlScott): Ah, the comparison to `-XDatatypeContexts` is definitely a compelling argument for the current behavior. I'll quit my job as devil's advocate, then. In that case, that cements my opinion that associated data family instances should be totally unrelated to the instance context of the parent instance, and moreover, that the bug is really just a duplicate of #11008 in disguise, as the fix for this issue would be improving GHC's ability to infer exotic constraints. Should we close it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 00:08:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 00:08:19 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.d63444952571935d0008c8bfc6ee1e07@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): This code still triggers the issue in ghc-8.0 branch as of 24 Oct 2016, code above - no longer does that. {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PolyKinds #-} module A where import GHC.Generics class Enum' f where enum' :: [f a] toEnumDefault :: (Generic a, Enum' (Rep a)) => Int -> a toEnumDefault i = let l = enum' in if (length l > i) then to (l !! i) else error "toEnum: invalid index" class GEnum a }}} {{{ [1 of 1] Compiling A ( Generics/Deriving/Enum.hs, Generics/Deriving/Enum.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161022 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:2008:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2044:17 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:1986:3 in ghc:TyCoRep in_scope InScope [a2Um :-> a_a2Um[sk], a2Ur :-> k_a2Ur[tau:3], a2Us :-> f_a2Us[tau:3], a2Uu :-> a_a2Uu[sk]] tenv [a2Um :-> a_a2Uu[sk]] tenvFVs [a2Ui :-> k_a2Ui[tau:5], a2Uu :-> a_a2Uu[sk]] cenv [] cenvFVs [] tys [[f_a2Us[tau:3] a_a2Um[sk]]] cos [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 01:04:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 01:04:51 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.2b953433021042722c9f962caca63c8e@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): 15fc52819c helps but it's not included into release candidate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 07:34:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 07:34:25 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.b55168810dec818104c21515dc39c3e2@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The recipe gave in comment:4 doesn't work for the example in comment:14. I could elaborate the recipe a bit thus: {{{ class C x y z where type T y z x op :: x -> [y] -> z newtype N a = MkN deriving( C ) -- Here the deriving clause would generate instance C x y => C x y (N a) where type T y (N a) x = T y x op = coerce (op :: x -> [y] -> ) }}} The recipe for generating the `type instance` is to replace the occurrence of `z` (which must occur) with `` on the LHS and RHS. I don't think it need be the last parameter of `T`, as the example shows. I'm far from sure if this is really worth the effort of explaining and implementing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 08:10:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 08:10:55 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.fa547e663ebe5dea45be6d5ed6266b0a@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 simonpj): I think it's more than just #11008. The question of this ticket is just "what context should GHC infer for a 'deriving' clause." But the ticket concerns the specific case of a `data instance` inside a `class` instance decl, thus: {{{ instance => C (T a b) where data D (T a b) = D1 a | D2 b }}} Now arguably, whether or not the `deriving Eq` part ''needs'' `` it would do no harm to add it, so we get the derived instance {{{ instance => Eq (DT a b) where (==) = }}} (where `DT` is the representation data type for `D (T a b)`). The point is that `` might help satisfy the `Eq` constraints arising from ``. Max argues that `` must already be satisfied (because the class instance holds). But that's not really true {{{ f x y = D1 x == D2 y }}} Here we need equality on `DT` but we don't need `C (T a b)`. So `` might be over-constraining. So I'm unconvinced that this is worth the bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 08:13:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 08:13:10 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.5f70ed676cbb09310c4d705ec9eaab22@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you! The commit 15fc52819c is short and definitely good. Let's merge it into 8.0. In comment:5 you say that "helps"; does it fix the 8.0 branch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 08:13:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 08:13:15 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.033b68fc9e8eb1aac1605e55aa9bd8cc@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 08:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 08:16:49 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.063f867ff5bc6389e363b21c2b7426ed@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Right, picking 15fc52819c to 8.0 branch fixes the issue. Btw, right now I'm debugging one more issue that causes assertion failure with devel2 and it's still the case in 8.0 branch. At the moment smallest sample is down to 8 files with no external dependencies other than bytestring. I can try reducing it further but it's going hard. it's a sample for that new panic: {{{ (GHC version 8.0.1.20161022 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:2012:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2048:17 in ghc:TyCoRep substTy, called at compiler/simplCore/SimplEnv.hs:696:18 in ghc:SimplEnv in_scope InScope [00 :-> wild_00, Xw :-> wild_Xw, XD :-> wild_XD, XH :-> wild1_XH, XaWP :-> msg0_XaWP, a4vA :-> s'_a4vA, a4Db :-> ds2_a4Db, a4Dd :-> ipv_a4Dd, a4De :-> ipv1_a4De, a6eU :-> t'_a6eU, a6eV :-> pos'_a6eV, a6eW :-> more'_a6eW, a6eX :-> a1_a6eX, d4gB :-> dt_d4gB, d4gC :-> dt1_d4gC, d4gD :-> dt2_d4gD, d4gE :-> dt3_d4gE, d4gF :-> dt4_d4gF, d4gG :-> dt5_d4gG, rdYv :-> decodeOTCLine, reHX :-> $trModule, s6ZQ :-> nt1_s6ZQ, s6ZS :-> ipv1_s6ZS, seJM :-> $trModule_seJM, seJN :-> $trModule_seJN, seJU :-> lvl_seJU, seJY :-> lvl_seJY, seOl :-> $wsucc_seOl, seOu :-> $wdecodeOTCLine_seOu, sePd :-> lvl_sePd, sePe :-> lvl_sePe, sePf :-> lvl_sePf, sePg :-> lvl_sePg, sePh :-> lvl_sePh, sePi :-> lvl_sePi, sePk :-> lvl_sePk, sePl :-> lvl_sePl, sePm :-> lvl_sePm, sePn :-> lvl_sePn, sePp :-> fail_sePp, sePq :-> lvl_sePq, sePr :-> lvl_sePr, sePs :-> lvl_sePs, sePt :-> lvl_sePt, sePu :-> lvl_sePu, sePv :-> lvl_sePv, sePw :-> lvl_sePw, seQ0 :-> sc_seQ0, seQ1 :-> sc_seQ1, seQ2 :-> sc_seQ2, seQ3 :-> sc_seQ3, seQ7 :-> sc_seQ7, seQa :-> $s$wsucc_seQa] tenv [] tenvFVs [] cenv [seQ6 :-> sg_seQ6] cenvFVs [seQ6 :-> sg_seQ6] tys [ByteString] cos [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 12:55:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 12:55:18 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.5f9856206b462eea6c72aba3b0251370@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If it's OK in HEAD (is it?) I'd be inclined to leave it. The ASSERT is very conservative, so it's very unlikely to reveal a real bug Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 13:02:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 13:02:02 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.ca1c9ff454abb41e3b74fa99b935e4e6@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): > If it's OK in HEAD (is it?) I'd be inclined to leave it. The ASSERT is very conservative, so it's very unlikely to reveal a real bug I'll check if HEAD fixes it. It might reveal a bug - it's from our codebase and there is a random compilation failure that goes away when compilation is restarted. If it's not this one - there might be something else - I decided to isolate it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 13:10:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 13:10:11 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.67bd581d819f5d77317a9021a530d43f@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 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 RyanGlScott): Replying to [comment:17 simonpj]: > So I'm unconvinced that this is worth the bother. I completely agree, not only because it might be over-constraining, but in some cases it might even yield redundant constraints, as in this example: {{{#!hs {-# LANGUAGE TypeFamilies #-} class C a where data D a c :: a -> a -> Bool instance Eq a => C [a] where newtype D [a] = DList [a] deriving Show c = (==) }}} This would, under the proposal in this ticket, yield: {{{#!hs instance (Eq a, Show a) => Show (D [a]) }}} which isn't what we want at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 13:14:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 13:14:21 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.a531a530d2273b0323af501c3d4e7c05@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: goldfire => RyanGlScott Comment: Right, I didn't say the last type parameter of `T` had to be the newtype. Rather, the last type parameter of the class `C` (`z` in the example in comment:18) just has to occur somewhere in the type parameters of `T`. > I'm far from sure if this is really worth the effort of explaining and implementing it. I disagree! Really, this is a quite straightforward idea (with a couple of small gotchas, like the one you observed), and I've implemented most of it already—I just need to polish up the documentation, update the GHC wiki, and post a Phabricator Diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:12:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:12:24 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.5ded16c7d9bbc6d5ec786fd8cd973f81@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to be clear on the design here: we plan on rejecting the code in comment:14, right? That is, for GND to work with associated types, the last parameter of the class must be mentioned in the associated type LHS. Then I'm on board. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:13:14 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.688eb00cd13dc1088d4e94d21ff35d88@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:20 goldfire]: > Just to be clear on the design here: we plan on rejecting the code in comment:14, right? That is, for GND to work with associated types, the last parameter of the class must be mentioned in the associated type LHS. Then I'm on board. Yes, precisely. I'll make sure to mention this fact in the users' guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:20:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:20:37 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.72df2d508744e165e8e0cea0f6647fe3@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I clarify that I suspect the large term counts here are really the result of the library itself making heavy use of type classes, essentially making this yet another manfestation of #8095. The high desugaring times observed in compiling tree are due to the fact that we run `simpleOptPgm` during desugaring. I didn't have a chance to look at compilation time regressed from 7.8 to 7.10 to 8.0. When I get a chance the best next step will likely to focus on the 7.10 to 8.0 regression (since it is both newer (and therefore easier to debug) as well as larger). First verify that the desugared Core is equivalent, then look at compiler profiles to see if the compiler implementation has regressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:20:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:20:51 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.1caba1e093f16c89a8cd2fe24f2d8adf@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: 5321, #11598 => #5321, #11598, #12506 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:26:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:26:49 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.787572617434f888c4f762778f84354c@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11312, #12585 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 14:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 14:32:07 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.f50c2bf1ea4f514ea4faadc09013c2ec@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Siarheit had some insight on this. The problem here is essentially that `bytestring` traverses a `ByteString` by walking until `currPtr == ( "literal"# +# length "literal"# )` where `currPtr` is initialized with `"literal"#`. This means that if `"literal"#` is inlined twice, you will end up with `currPtr` and `"literal"# +# length "literal"#` pointing into two separate chunks of memory, with who-knows-what in between. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 15:47:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 15:47:11 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.c086f918a1498852cae7a3f2b04d0d77@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): And #12757 shows that having literal strings be of type `Addr#` can lead to seg-faults. Yikes. We really should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 15:53:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 15:53:04 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.fa81c20a18b30387a74c9ecf0e0ae136@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah! Good insight. comment:3 of #11312 would nail this problem, and we should do that anyway. Short term, not duplicating literal strings seems like the way forward. They are duplicated in `CorePrep`, apparently because of * Edwards's patch for #12076 made `CorePrep` a bit more gung ho about inlining * When inlining in `CorePrep` we use `cpe_ExprIsTrivial`, which treats all literals (including strings) as trivial and hence inlinable. No one quite knows why: see #11158 So the best path forward seems to be to fix #11158, which we want to do anyway. Then we won't duplicate string literals, and `bytestring` will probably be happy again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:23:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:23:38 -0000 Subject: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC In-Reply-To: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> References: <044.5bde4abfdaa56d5ae586d71d6ff93b9d@haskell.org> Message-ID: <059.a453855b76b003a7546146fb05e080e0@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T4114a,b,c,d Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:24:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:24:42 -0000 Subject: [GHC] #12764: Be able to pin a thread to a numa node without fixing a capabiity Message-ID: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> #12764: Be able to pin a thread to a numa node without fixing a capabiity -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a rts call `rts_setInCallCapability(int)` which pins the current thread to the given capability. If numa is on, it also pins it to the appropriate numa node. We want to be able to pin a thread to a numa node but without fixing a capability. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:25:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:25:18 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.ac56c3df7f6ad6b725b6082536026208@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:36:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:36:37 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.a0ff2cd30490a42263fde8e6fdb3775c@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | 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 niteria): I get a difference here, but not as dramatic: {{{ real 0m11.544s user 0m11.210s sys 0m0.243s }}} vs {{{ real 0m14.845s user 0m14.279s sys 0m0.291s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:47:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:47:36 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.9a547209c3dac6f55d18ef491e3b2d22@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2636 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:47:58 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.571e132e139ead83959e321915902177@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'll take a closer look later, but there seem to be multiple silly things going on. This: {{{ [section ""data" . sat_sNJ_closure" { sat_sNJ_closure: const ()_static_info; }] }}} Is **an instance of the () constructor** which is crazy because there only needs to be one instance of `()`, we don't need to create new instances of it. It's also totally silly for `Nothing` to be in an SRT. Even when we're not optimising we ought to know that nullary constructors have `NoCafRefs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 17:48:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 17:48:05 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.553cf3f9a298e66224cbd1d353b2f989@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2636 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 18:18:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 18:18:07 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.bfe5c9a5fd5bd6e1e971548feff8f418@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Mailing list discussion about what to name it: https://mail.haskell.org/pipermail/libraries/2016-October/027386.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 19:05:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 19:05:36 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.2ff8280339ff9146bd62d88beeca1a29@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): ARG! Where is my comment to Simon’s comment:22 gone? I replied to that! (Maybe got bitten by #11718 again.) So here is a second try: Re SPJ’s point 3: As I wrote in comment:14, the above happens when I change `cpe_ExprIsLiteral` to ''not'' consider data constructors as trivial: {{{ cpe_ExprIsTrivial (Var v) | isDataConWorkId v = False }}} Obviously this is not what we want, but it is the easiest way to trigger the mysterious crashes and understand more about the pipeline, in particular why is it not safe to have `MayHaveCafRefs` on such pointless bindings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 20:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 20:50:31 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.fad7d452b5d7751a3069f7b65c9734da@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): RE point 3: fair enough. I missed that. Thanks. But 1,2,4 are still odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 20:54:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 20:54:58 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.b2a4e80736708165009c4808225c8d14@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * failure: None/Unknown => Compile-time performance bug * resolution: invalid => Comment: It would be great to have some insignt into what is going on here. It's very unexpected to have such a large difference from such a small change. Profiling would be very interesting. I'll re-open. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 20:55:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 20:55:20 -0000 Subject: [GHC] #12765: Don't optimize coercions with -O0 Message-ID: <046.7e3ab84f64fb539fca4f209e81f1fa76@haskell.org> #12765: Don't optimize coercions with -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During the call today Simon and I discussed the possibility of omitting coercion optimization from the desugarer's simple optimization (`simpleOptPgm`) when compiling with `-O0`. The justification here was to perhaps speed-up unoptimized compilation times for programs like that of #12506, which has very large coercions (presumably due to #8095). The rationale was that while this first pass of coercion simplification during desugaring may reduce the size of some of these coercions, we only walk over them once more during code generation, so there's little benefit given the cost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 21:02:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 21:02:22 -0000 Subject: [GHC] #12765: Don't optimize coercions with -O0 In-Reply-To: <046.7e3ab84f64fb539fca4f209e81f1fa76@haskell.org> References: <046.7e3ab84f64fb539fca4f209e81f1fa76@haskell.org> Message-ID: <061.80a0409aacc6a11a4193317c109067d6@haskell.org> #12765: Don't optimize coercions with -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm dropping a ticket here since I'm no longer convinced that this is worthwhile. Unfortunately this would require a significant amount of plumbing of the optimization level through a bunch of pure simplification functions to make this happen. Moreover, even if we forego the coercion simplification pass in `simpleOptPgm`, we still do run the simplifier even with `-O0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 21:24:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 21:24:44 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.44b504ce53e0b654407c495d3fcc3ba0@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: phadej Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): If we build in {{{#!hs type family (++) :: Symbol -> Symbol -> Symbol }}} that doesn't prevent it from later being used in a potential later or even third-party polykinded {{{#!hs type family (<>) :: k -> k -> k type instance (<>) = (++) }}} and it would be consistent with the fact that the other `GHC.TypeLits` such as `(+)` are all specific to one kind. That said, none of the existing machinery for `KnownNat` knows anything about `(+)`, so it'd be a leap to expect `KnownSymbol` to know about `(++)`. Also note that complicating evidence by giving it more internal hidden constructors like is used to deal with `Coercible` instances is actually bad for folks who use things like reflection to mimic this behavior or construct symbols at runtime today. As an aside, you can actually get type level symbol concatenation and tools for working with it out of the `constraints` package at least in HEAD today, but it doesn't have any compiler assistance. You have to explicitly use the various axioms and `appendSymbol` proofs rather explicitly to get the resulting `KnownSymbol` instances, but you can do it. https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Symbol.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 21:55:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 21:55:22 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.28fbd226902f0cd7b953fcae93fed2a6@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Bartosz game me the command he was using. {{{ rm A.{hs,o,hi}; python gen12754.py > A.hs && time ghc A.hs }}} and I ran the test again, here are my 4 runs. {{{ [1 of 1] Compiling A ( A.hs, A.o ) real 0m26.460s user 0m24.643s sys 0m0.711s ~/Documents/haskell/ghc:vim gen.py ~/Documents/haskell/ghc:rm A.{hs,o,hi}; python gen.py > A.hs && time ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) real 0m15.743s user 0m15.100s sys 0m0.402s ~/Documents/haskell/ghc:vim gen.py ~/Documents/haskell/ghc:rm A.{hs,o,hi}; python gen.py > A.hs && time ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) real 0m24.858s user 0m24.283s sys 0m0.392s ~/Documents/haskell/ghc:vim gen.py ~/Documents/haskell/ghc:rm A.{hs,o,hi}; python gen.py > A.hs && time ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) real 0m12.098s user 0m11.672s sys 0m0.321s }}} so I do see a big difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 22:22:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 22:22:50 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.4fc79063abfb42af2f3114b9fee09fe0@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Simon: That other failure is not fixed in HEAD, but panic looks a bit different: {{{ (GHC version 8.1.20161024 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 wild_Xw wild1_XH t'_a2XC pos'_a2XD more'_a2XE a1_a2XF dt_d2iY dt1_d2iZ dt2_d2j0 dt3_d2j1 dt4_d2j2 dt5_d2j3 decodeOTCLine $trModule nt1_s3K7 ipv1_s3K9 $trModule_sc1H $trModule_sc1I lvl_sc1T $wsucc_sc5K $wdecodeOTCLine_sc5T lvl_sc6y lvl_sc6z lvl_sc6A lvl_sc6B lvl_sc6C lvl_sc6D lvl_sc6F lvl_sc6G lvl_sc6H lvl_sc6I fail_sc6K lvl_sc6L lvl_sc6M lvl_sc6N lvl_sc6O lvl_sc6P sc_sc7y sc_sc7z sc_sc7A sc_sc7B sc_sc7F $s$wsucc_sc7I} tenv [] tenvFVs [] cenv [sc7E :-> sg_sc7E] cenvFVs [sc7E :-> sg_sc7E] tys [ByteString] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1125:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2070:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2103:17 in ghc:TyCoRep substTy, called at compiler/simplCore/SimplEnv.hs:701:18 in ghc:SimplEnv Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1123:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2070:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2103:17 in ghc:TyCoRep substTy, called at compiler/simplCore/SimplEnv.hs:701:18 in ghc:SimplEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 25 23:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 25 Oct 2016 23:58:57 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.7633fc84259e6318220d232524824d67@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duncan): From the point of view of the bytestring package, what we would like is an O(1) way to convert from a constant/literal string to a pinned `ByteArray#` since we can build a `ByteString` from one of those. You may say why not just convert to a raw `Addr#` given that `ByteString` uses `ForeignPtr` which can use pointers. Well, long term we'd like to eliminate the use of `ForeignPtr` and use only pinned or unpinned `ByteArray#`s, and similarly in the long term `Text` will switch to UTF8 and it already uses `ByteArray` not `ForeignPtr`. So long term, to have O(1) `Text` or `ByteString` literals we'd need to be able to convert to `ByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 01:32:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 01:32:18 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.c0ffad919f77851849a9ac8b3d41ca20@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): The difference in allocations is significant: {{{ $ rm A.{hs,o,hi}; python gen12754no.py > A.hs && inplace/bin/ghc-stage2 A.hs +RTS -s; rm A.{hs,o,hi}; python gen12754.py > A.hs && inplace/bin /ghc-stage2 A.hs +RTS -s; [1 of 1] Compiling A ( A.hs, A.o ) 13,116,210,736 bytes allocated in the heap 1,154,829,688 bytes copied during GC 92,896,592 bytes maximum residency (13 sample(s)) 2,925,816 bytes maximum slop 225 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2658 colls, 0 par 1.433s 1.433s 0.0005s 0.0334s Gen 1 13 colls, 0 par 0.840s 0.840s 0.0646s 0.1918s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 10.539s ( 11.260s elapsed) GC time 2.273s ( 2.273s elapsed) EXIT time 0.045s ( 0.046s elapsed) Total time 12.882s ( 13.580s elapsed) Alloc rate 1,244,579,585 bytes per MUT second Productivity 82.3% of total user, 83.3% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 [1 of 1] Compiling A ( A.hs, A.o ) 7,981,835,440 bytes allocated in the heap 804,198,536 bytes copied during GC 92,485,816 bytes maximum residency (13 sample(s)) 2,114,568 bytes maximum slop 243 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 592 colls, 0 par 0.846s 0.846s 0.0014s 0.0385s Gen 1 13 colls, 0 par 0.883s 0.883s 0.0679s 0.1829s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 9.633s ( 10.229s elapsed) GC time 1.729s ( 1.728s elapsed) EXIT time 0.044s ( 0.052s elapsed) Total time 11.433s ( 12.010s elapsed) Alloc rate 828,632,869 bytes per MUT second Productivity 84.9% of total user, 85.6% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 01:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 01:52:34 -0000 Subject: [GHC] #12764: Be able to pin a thread to a numa node without fixing a capabiity In-Reply-To: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> References: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> Message-ID: <061.168ea80778b3cf6974f844bdd1194c65@haskell.org> #12764: Be able to pin a thread to a numa node without fixing a capabiity -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2637 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darshan): * differential: => D2637 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 03:31:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 03:31:39 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.1b5c5b942b3570ec687dd6ed18c35bee@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: bgamari (added) Comment: I may have found the culprit. While investigating #12754, I obtained these results: {{{ 8.0.1 HEAD HEAD (disable mkTypeableBinds) Compile time (without export list): 13.16 15.16s 12.19 -20% Compile time (with export list): 10.24s 12.06s 9.16 -24% Binary size: 5.4M 5.4M 2.5M -53% Interface size: 888K 1.1M 498K -55% #symbols in .symtab: 60034 60034 30017 -50% #relocs in .rela.data: 60024 60024 10002 -83% Size of .data section: 720272 720272 80016 -89% Size of .strtab section: 887100 887100 447902 -50% }}} For each type constructor, `mkTypeableBinds` adds: * The name of the constructor as a string into .rodata * + 1 symbol * n bytes, 8-byte aligned (there are two consecutives directives: `.align 8 .align 1` before each string) * A `GHC.Types.TrNameS` closure in .data * + 1 symbol * 8 bytes, 8-byte aligned too * A `GHC.Types.TyCon` closure in .data * + 1 symbol * 24 bytes, 8-byte aligned too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 04:55:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 04:55:04 -0000 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> References: <064.1e051c3fce5c2da263cdc0424cf20634@haskell.org> Message-ID: <079.33708acabac09580133e0ed4425aff51@haskell.org> #1687: A faster (^)-function. --------------------------------------------+----------------------------- Reporter: moonlite@… | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Prelude | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+----------------------------- Comment (by siddhanathan): rwbarton explained this earlier, but it took a while to wrap my head around it. I find this a bit clearer to understand: {{{ {-# SPECIALISE [1] (^) :: Integer -> Integer -> Integer, Integer -> Int -> Integer, Int -> Int -> Int #-} {-# INLINABLE [1] (^) #-} -- See Note [Inlining (^)] (^) :: (Num a, Integral b) => a -> b -> a x0 ^ y0 | y0 < 0 = errorWithoutStackTrace "Negative exponent" | y0 == 0 = 1 | otherwise = f x0 y0 1 where f x y z | even y = let k = f x (y `quot` 2) z in k * k | y == 1 = x * z | otherwise = let k = f x ((y - 1) `quot` 2) z in k * k * x }}} This has identical performance to the version in the description above. This makes use of the fact that x^2a^ = x^a+a^ = x^a^ * x^a^ ; and x^2a+1^ = x^a^ * x^a^ * x -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 05:26:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 05:26:31 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.c76f620acdb639c03c4d722ca40f5ff0@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I built profiled GHC and it confirms what Matthew already said, `nubAvails` makes up all the extra allocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 07:19:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 07:19:34 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output In-Reply-To: <050.6392f4ea96644f5394022cd373a55178@haskell.org> References: <050.6392f4ea96644f5394022cd373a55178@haskell.org> Message-ID: <065.2db9f4af000c5cc026d57fdc5553885f@haskell.org> #11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11292 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fair enough, but there are then three separate matters here 1. Top-level unboxed string literals: #8472 2. Disentangling `Addr#` and `String#` along the lines of comment:3 (this ticket) 3. Some kind of support for `ByteArray#` literals, as you ask. Perhaps (2) and (3) are related, beause perhaps a `String#` can ''be'' a static `ByteArray#`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 07:59:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 07:59:38 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.f0182b66a7c4bbe368220c7c41e15755@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I stupidly missed Matthew's original insight in the Description. He's absolutely right; the current thing is stupid. There should be nothing non-linear about this. We have a `[GRE]` and we want a `[AvailInfo]`. Very well: do {{{ gresToAvailInfo :: [GRE] -> [AvailInfo] gresToAvailInfo gres = nameEnvElts avail_env where avail_env :: NameEnv AvailInfo -- Keyed by the parent avail_env = foldr add emptyNameEnv gres add :: GRE -> NameEnv AvailInfo -> NameEnv AvailInfo add gre env = ... very like availFromGRE, but instead of returning an AvailInfo, it extends the appropriate AvailInfo in the env ... }}} Each GRE should take constant time to add. Each GRE deals with a different Name, so there is no need to check for duplicates. Needed in two places * `TcRnExports.exports_from_avail`, the `Nothing` case. * Same function, the `IEModuleContents` case of `exports_from_item` Hmm. The use of `nubAvails` is still needed though, in case you say {{{ module M( T( D, D3 ), T( D, D2 ) ) }}} when we should combine the two export items to `T( D, D2, D3 )`. So we might still get the non-linear cost if you have very many manually-written items, which is at least better. So an alternative, perhaps better, would be to rewrite `nubAvails` to use code very like the above function, so that each `Name` in the `[AvailInfo]` takes linear time to add. That's be more robust I guess. Finally, the other use of `nubAvails` is in `RnNames,findImportUsage`. I think `extendImportMap` could return a `[GRE]` as the second element of its result pair, instead of `[AvailInfo]`, and then we could use `gresToAvailInfo` again; but this time we'd need to worry about duplicates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 08:11:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 08:11:49 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.eb367b1a0151409516c78f3abd5c4eee@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK this is `substTy` called from `SimplEnv` i.e. in the simplifier. Again it's unlikely to be causing a problem but I'd like to nail what's going on. Do you have time to make a reproducible case? It doesn't have to be terribly small, but having few dependencies is helpful. You 8-file blob might do. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 08:59:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 08:59:24 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.11dff3ef71bddb6369098229d8487178@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): It's 5 files blob now. I'll put it somewhere once I get to my computer.1 hour or so. There are similar failures all over our codebase, the biggest one is over 3k lines long -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 09:44:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 09:44:42 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.61e404a6667f64bf5e815356a50ccf94@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pacak): * Attachment "blob.zip" added. file sample -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 09:46:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 09:46:14 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.789b08583f5e733c6d58b75d3124827e@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Simon: Attached a file sample. It produces panic if you use `ghc -O2 A.hs` for both 8.0.2 rc and latest HEAD branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 10:13:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 10:13:35 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies In-Reply-To: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> References: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> Message-ID: <062.21f5bfc0600e8a71507ea34e9be6570a@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"801c26372742fc79bd3756bdcb710031c716c402/ghc" 801c2637/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="801c26372742fc79bd3756bdcb710031c716c402" Fundeps work even for unary type classes The functional-dependency improvement functions, improveFromAnother improveFromInstEnv had a side-condition that said the type class has to have at least two arguments. But not so, as Trac #12763 shows: class C a | -> a where ... is perfectly legal, albeit a bit of a corner case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 10:26:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 10:26:54 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies In-Reply-To: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> References: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> Message-ID: <062.c9bc1e6d921eb34bad074257aab5a393@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T12763 Comment: Fixed thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 10:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 10:38:44 -0000 Subject: [GHC] #12742: Instantiation of invisible type family arguments is too eager In-Reply-To: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> References: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> Message-ID: <062.33b66ba81f40141aa63029355929e95a@haskell.org> #12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 10:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 10:47:09 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.dfe50f03c18483e29c06551e33564990@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 simonpj): * keywords: => TypeInType Comment: The stuff about representation-polymorphism is a bit of a red herring; make a new ticket. Let's not lose track of the original request here, which is well described in the Description. Richard: it might need no more than ''removing'' a test, namely the test that data families return *? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 12:22:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 12:22:07 -0000 Subject: [GHC] #12766: Allow runtime-representation polymorphic data families Message-ID: <051.3d7f378b0f8aa6ff42ef4e0c3f30e9dd@haskell.org> #12766: Allow runtime-representation polymorphic data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an offshoot of #12369 (‘ data families shouldn't be required to have return kind *, data instances should’), allowing family declarations something like: {{{#!hs data family Array a :: TYPE rep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 12:22:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 12:22:40 -0000 Subject: [GHC] #12369: data families shouldn't be required to have return kind *, data instances should In-Reply-To: <045.88f660f600999139443e7ddd5881a759@haskell.org> References: <045.88f660f600999139443e7ddd5881a759@haskell.org> Message-ID: <060.1301171580b402927754c68302e9cf37@haskell.org> #12369: data families shouldn't be required to have return kind *, data instances should -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType 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 Iceland_jack): Replying to [comment:8 simonpj]: > ''[...]'', make a new ticket. #12766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 12:22:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 12:22:59 -0000 Subject: [GHC] #12766: Allow runtime-representation polymorphic data families In-Reply-To: <051.3d7f378b0f8aa6ff42ef4e0c3f30e9dd@haskell.org> References: <051.3d7f378b0f8aa6ff42ef4e0c3f30e9dd@haskell.org> Message-ID: <066.4e2603fbfeb5d1cd6bfa0e488df0570f@haskell.org> #12766: Allow runtime-representation polymorphic data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,1 +1,1 @@ - This is an offshoot of #12369 (‘ data families shouldn't be required to + This is an offshoot of #12369 (‘data families shouldn't be required to New description: This is an offshoot of #12369 (‘data families shouldn't be required to have return kind *, data instances should’), allowing family declarations something like: {{{#!hs data family Array a :: TYPE rep }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 12:31:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 12:31:30 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.205eed50a818c69dc55439a3e72bbf7c@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2633 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * differential: D2633 => phab:D2633 Comment: Note that my patch in comment:14 doesn't make `runGhc` thread-safe if several `runGhc` are executed concurrently. E.g., in the following case: {{{#!haskell runGhc (1) install handlers runGhc (2) install handlers runGhc (1) uninstall handlers runGhc (2) uninstall handlers -- reinstall handlers installed by `runGhc (1)` -- overwriting initial handlers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 13:06:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 13:06:08 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.c3264843ba1d9b7373d93f615353f892@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2633 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Good point, maybe use a reference count instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 13:51:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 13:51:27 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.5ee11858b672da743da0b63812a04a31@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): simonpj, did you mean to use `foldr` in `avail_env`? As far as I know it's better to use `foldl'` in cases like these where the result can't be forced "incrementally". In the case of `foldr` you will first build up a chain of `add` applications on the stack before ending up with the final `NameEnv AvailInfo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 13:54:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 13:54:02 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.143c4fcf714a557c1c578b39292fdae9@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed the `Typeable` implementation was changed as a result of #9858. We were slightly concerned that resolving this issue would regress compilation times, although initial indications seemed to suggest that the issue wouldn't be noticeable in practice. It sounds like BFD `ld` is likely doing something very silly (which wouldn't be at all surprising). I'm not really sure what to recommend in the short term beyond "use `gold`". In general `gold` is significantly more sane. In the long-term there is of course the question of whether we want to revert to the previous approach of producing `Typeable` bindings during evidence generation. Given that such massive types aren't terribly common, I tend to think that the consistency that treating `Typeable` at declaration-time is probably worth the cost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 13:54:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 13:54:14 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.8f53f8f447ac02003e1e91343659ee3b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: #10000 | Differential Rev(s): Phab:D652, Wiki Page: | Phab:D757 -------------------------------------+------------------------------------- Comment (by bgamari): There are some relevant performance comments in #12748. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 14:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 14:04:18 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.bd87a6668ab88224a3971ca1b147eedd@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): maybe `foldl'` would be better, yes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 14:05:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 14:05:51 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.991339f21b7edd98c1b6364282a8a749@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Seems to be a GHCi issue. Works ok when compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 14:41:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 14:41:50 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.37f5196d9fad3e3f7eab090ba1c8a652@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 simonpj): I think my fix to #12668 may have fixed comment:3. Not certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 14:44:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 14:44:46 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.b1978e4e9af4be231d5d0a34497ece89@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash | types/should_compile/T12522, | T12522b, should_fail/T12522a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T12522, T12522b, should_fail/T12522a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 14:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 14:45:00 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.45e1bbc3e15d2707440914d00c9f6a3c@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2633 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Yes, I have updated the patch in Phab:D2633 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:50:06 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.bed87d5984e9c8da3570fd0067f16f26@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 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 Ben Gamari ): In [changeset:"925d178e023ec3c481ec8a5a38019797b779f7d7/ghc" 925d178e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="925d178e023ec3c481ec8a5a38019797b779f7d7" Make traceRn behave more like traceTc Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2586 GHC Trac Issues: #12617 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:50:06 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.58427c52ad2f6cf9e05169246bde654a@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"488a9ed3440fe882ae043ba7f44fed4e84e679ce/ghc" 488a9ed3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="488a9ed3440fe882ae043ba7f44fed4e84e679ce" rts/linker: Move loadArchive to new source file Test Plan: Validate Reviewers: erikd, simonmar, austin, DemiMarie Reviewed By: erikd, simonmar, DemiMarie Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2615 GHC Trac Issues: #12388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:50:06 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.68d8a294bcdb6c492ab94655d5c3b8a3@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: mpickering Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2624 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"23143f60680f78f80762754fe060a3e8c6dc9a01/ghc" 23143f6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23143f60680f78f80762754fe060a3e8c6dc9a01" Refine ASSERT in buildPatSyn for the nullary case. For a nullary pattern synonym we add an extra void argument to the matcher in order to preserve laziness. The check in buildPatSyn wasn't aware of this special case which was causing the assertion to fail. Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2624 GHC Trac Issues: #12746 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:50:06 -0000 Subject: [GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level In-Reply-To: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> References: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> Message-ID: <064.635502706156524884ad2541baa86a3e@haskell.org> #12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 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 Ben Gamari ): In [changeset:"48876ae04c4963f8d5a60a121ac85d52322faaee/ghc" 48876ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48876ae04c4963f8d5a60a121ac85d52322faaee" Remove -dtrace-level The flag was: 1. Not documented. 2. Only used as a boolean flag. 3. Has overlapping functionality with -dno-debug-output 4. My poll of #ghc concluded that people didn't know it existed. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2627 GHC Trac Issues: #12691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:52:34 -0000 Subject: [GHC] #12617: Make the interface of traceTc and traceRn the same In-Reply-To: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> References: <049.08fb81f1aa520077fd88dbea32002604@haskell.org> Message-ID: <064.71dc857a5612453bd63b6f1d584c9797@haskell.org> #12617: Make the interface of traceTc and traceRn the same -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:52:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:52:51 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.bc5cf3cde27c6ea9f0c6063e48873850@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: mpickering Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 15:53:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 15:53:52 -0000 Subject: [GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level In-Reply-To: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> References: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> Message-ID: <064.af89b471061bc9e631d4dac3b4f5fa19@haskell.org> #12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: I'm going to leave this out of 8.0.2 since it only affects compiler debugging functionality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 16:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 16:13:42 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.84a90a6068966b233ab6a109e95b1c46@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * differential: Phab:D2621 => Phab:D2638 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 16:13:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 16:13:50 -0000 Subject: [GHC] #12744: Register Allocator Unit Tests In-Reply-To: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> References: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> Message-ID: <061.ac9ac0b16452ec28985e8c7c8914f842@haskell.org> #12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12745 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * differential: => Phab:D2638 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 16:15:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 16:15:37 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.5ea4bf2a7b2f9a2c92555083fca264e2@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tjakway): I've submitted the first patch with a test for avoiding unnecessary spills and reloads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 17:35:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 17:35:59 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.8cf1b0fb4ba71b3d0bfe70cbdd6b8c22@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 bgamari): Simonpj, which fix is this? I haven't seen a fix for #12668 yet; presumably it has yet to be merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 17:39:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 17:39:02 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.2985ce8fe84c9f2fe36f9f4fbfe3df28@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So for what it's worth the segmentation faults alluded to in comment:6 are from testsuite tests using the GHC API. Namely the following tests fail if you make `cpe_ExprIsTrivial` use `litIsTrivial`, {{{ make test TEST="T12156 landmines parsed par01 T7478 T11430 T10313 comments parseTree annotations listcomps T12529 T8628 T6145 T8639_api T10508_api T1969 T5631 T3064 T5030 T12227" }}} I quickly looked at one particular example (`T8628`) and found shockingly few clues while running the program in `gdb`. Judging by the fact that the value of the `$rip` register points to unmapped memory I believe that the mutator is jumping to some random location in the program's image. The C stack offers essentially no hints. The Haskell stack, on the other hand, suggests that the crash was while evaluating within the lexer. Also, I have confirmed that allowing strings (but not integers) to be trivial in `cpe_ExprIsTrivial` is sufficient to prevent the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 19:03:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 19:03:30 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.9a00d0b8ab3c657b7741081c4dfde0a8@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable 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 simonpj): I think I failed to push; will do tomorrow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 19:06:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 19:06:22 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.254e7f8c4d64db0418f391e23138245f@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Right. Note that you do not actually have to ''use'' the GHC API, it is sufficient to link against it: {{{ import GHC import System.Exit main :: IO () main = putStrLn "Hi" >> exitSuccess >> GHC.runGhc undefined (return ()) }}} (can you confirm that?) Note that with my change, I could tickle the crash (assuming its the same crash) without linking against `ghc`, but the cause is still somewhere in `base` or `ghc-prim`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 20:10:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 20:10:43 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.84483d82e01eb416c32a9dd1b3a8219d@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Right. Note that you do not actually have to use the GHC API, it is sufficient to link against it I actually haven't observed that. The example that you provided didn't reproduce the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 21:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 21:27:00 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.c9789ef3e4c2ac85756541a010b02859@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One thing I'm a bit confused by is the comment on `CoreToStg.FreeVarsInfo`, > INVARIANT: Any ImportBound Ids are HaveCafRef Ids Imported Ids without CAF refs are simply not put in the FreeVarsInfo for an expression. Why is this limited to import-bound `Id`s? I would have thought that any non-thunk `Id` which has NoCafRefs would be safe to omit from the SRT, regardless of where it is defined. I must be missing something here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 21:53:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 21:53:07 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.9a72c4295b8bb82999874c8ef7930663@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Why is this limited to import-bound Ids? I would have thought that any non-thunk Id which has NoCafRefs would be safe to omit from the SRT. Non-top-level Ids must be collected in FV info, becuase they become part of the dynamically allocated closure. They never go in an SRT. For SRTs we are talking about top level Ids. For top level imported Ids that defintely don't have CAF-refs, we can neglect them entirely in this free var into. I ''think'' it'd be OK to neglect ''local'' top-level Ids that have no CAF-refs too. I think that's what you are suggesting. I don't see any reason why not... feel free to try. Should not change the resulting STG or Cmm at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 22:32:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 22:32:13 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC (was: Latest Debian GCC breajs GHC) In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.f535c3b718e8f00272b9981bf5fb1e43@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 26 23:32:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 26 Oct 2016 23:32:40 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.207cd5996045a24c435e1c843adb923e@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 05:56:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 05:56:42 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... Message-ID: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12001 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Made this its own ticket, rather than using #12001. Are these worth adding? {{{#!hs pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont a <- (runCont -> a) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer a <- (runWriter -> a) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader a <- (runReader -> a) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State a <- (runState -> a) where State a = state a }}} The mtl API was changed way back when (before advent of pattern synonyms) which caused some [http://stackoverflow.com/questions/14157090/has-the- control-monad-state-api-changed-recently confusion], [http://learnyouahaskell.com/for-a-few-monads-more LYAH] still uses `Writer`, `State` in their examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 05:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 05:57:02 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.da61f5200895d60c9d8bece79f707972@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 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 Iceland_jack): See #12767: {{{#!hs pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont a <- (runCont -> a) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer a <- (runWriter -> a) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader a <- (runReader -> a) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State a <- (runState -> a) where State a = state a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:28:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:28:43 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.ad128aeb5c73339a092a14c231e7fc02@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 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 Simon Peyton Jones ): In [changeset:"eefe86d96d40697707c3ddfb9973a30a1897241f/ghc" eefe86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eefe86d96d40697707c3ddfb9973a30a1897241f" Allow levity-polymorpic arrows This cures Trac #12668 (and cures the Lint errors you get from Trac #12718). The idea is explained in Note [Levity polymorphism], in Kind.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:28:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:28:44 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.7cbeab885a8fe5c4a13ab35f40495f04@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"eefe86d96d40697707c3ddfb9973a30a1897241f/ghc" eefe86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eefe86d96d40697707c3ddfb9973a30a1897241f" Allow levity-polymorpic arrows This cures Trac #12668 (and cures the Lint errors you get from Trac #12718). The idea is explained in Note [Levity polymorphism], in Kind.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:30:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:30:05 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.5783e04b2977aac142984479c4545df9@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T12668 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T12668 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:30:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:30:50 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.30ea7332eddcdf5d9ff5e97443397828@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch does not cure the problem; but before the patch this program generated lots of spurious Lint errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:31:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:31:25 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.cdeb22b91f4469f1385f4fceb813f9e1@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): {{{ x2 :: T IntRep INt# }}} should be `Int#`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 07:33:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 07:33:14 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.dbbff017a44f898599f4c80564efb4fd@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, thanks, fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 08:07:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 08:07:30 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.baf4830bb06d9a2a9e48b00b7ae6d94d@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > I think grsecurity tracks writability history as well, so it forbids a page from being executable that was ever writable (by a given process) Then we should do whatever `ld.so` does, or `libffi`, both of which have to solve the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 11:44:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 11:44:40 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself Message-ID: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.1 is able to compile this without a problem and doesn't require FlexibleContexts. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ConstrainedClassMethods #-} module A where class C m where foo :: C m => m () newtype N m a = N (m a) deriving C }}} Compare the output of 8.0.1, 8.0.2 and 8.1. I turned on -fdefer-type- errors in order for -ddump-deriv to work. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ ghc -ddump-deriv A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_aNK => A.C (A.N m_aNK) where A.foo = GHC.Prim.coerce (A.foo :: m_ap1 ()) :: A.N m_ap1 () GHC.Generics representation types: }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 $ ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:10:12: error: • Couldn't match type ‘m’ with ‘N m’ arising from the coercion of the method ‘foo’ from type ‘C m => m ()’ to type ‘C (N m) => N m ()’ ‘m’ is a rigid type variable bound by the deriving clause for ‘C (N m)’ at A.hs:10:12 • When deriving the instance for (C (N m)) $ ghc -ddump-deriv -fdefer-type-errors A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_awm => A.C (A.N m_awm) where A.foo = GHC.Prim.coerce @(A.C m_ap0 => m_ap0 ()) @(A.C (A.N m_ap0) => A.N m_ap0 ()) A.foo GHC.Generics representation types: A.hs:11:12: warning: [-Wdeferred-type-errors] • Couldn't match type ‘m’ with ‘N m’ arising from a use of ‘GHC.Prim.coerce’ ‘m’ is a rigid type variable bound by the instance declaration at A.hs:11:12 • In the expression: GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo In an equation for ‘foo’: foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo When typechecking the code for ‘foo’ in a derived instance for ‘C (N m)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘C (N m)’ • Relevant bindings include foo :: N m () (bound at A.hs:11:12) }}} There's no '8.0.2' version to report this against so I've chosen 8.1. GHC 8.1 gives very similar results: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160930 $ ghc A.hs [1 of 1] Compiling A ( A.hs, A.o ) A.hs:11:12: error: • Couldn't match type ‘m’ with ‘N m’ arising from the coercion of the method ‘foo’ from type ‘C m => m ()’ to type ‘C (N m) => N m ()’ ‘m’ is a rigid type variable bound by the deriving clause for ‘C (N m)’ at A.hs:11:12 • When deriving the instance for (C (N m)) $ ghc -ddump-deriv -fdefer-type-errors A.hs [1 of 1] Compiling A ( A.hs, A.o ) ==================== Derived instances ==================== Derived instances: instance A.C m_awK => A.C (A.N m_awK) where A.foo = GHC.Prim.coerce @(A.C m_app => m_app ()) @(A.C (A.N m_app) => A.N m_app ()) A.foo GHC.Generics representation types: A.hs:11:12: warning: [-Wsimplifiable-class-constraints] The constraint ‘C (N m)’ matches an instance declaration instance C m => C (N m) -- Defined at A.hs:11:12 This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance A.hs:11:12: warning: [-Wdeferred-type-errors] • Couldn't match type ‘m’ with ‘N m’ arising from a use of ‘GHC.Prim.coerce’ ‘m’ is a rigid type variable bound by the instance declaration at A.hs:11:12 • In the expression: GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo In an equation for ‘foo’: foo = GHC.Prim.coerce @(C m => m ()) @(C (N m) => N m ()) foo When typechecking the code for ‘foo’ in a derived instance for ‘C (N m)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘C (N m)’ • Relevant bindings include foo :: N m () (bound at A.hs:11:12) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 11:45:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 11:45:17 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.785c7596184e80e3eae5c57135f1ecaa@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jophish): * Attachment "A.hs" added. Minimal testcase -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 12:00:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 12:00:05 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.5a4f943be5cb0a2436f76ab0d3e9c83d@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): These types live in `transformers` so a more appropriate venue is a libraries@ request or just an email to Ross Paterson, the `transformers` maintainer. I personally think they'd be rather nice to have, as they'd fix one of the main problems users have coming in to modern Haskell from old tutorials at least based on the chatter on #haskell over the years. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 13:13:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 13:13:28 -0000 Subject: [GHC] #12769: ghc: internal error: stg_ap_pp_ret Message-ID: <045.3906df0b47185ed07f8c39e1db59841e@haskell.org> #12769: ghc: internal error: stg_ap_pp_ret ----------------------------------------+---------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- appeared when building a project on macOS Sierra: https://github.com/Potregon/while/blob See attached log file (told me to report the bug) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 13:15:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 13:15:54 -0000 Subject: [GHC] #12769: ghc: internal error: stg_ap_pp_ret In-Reply-To: <045.3906df0b47185ed07f8c39e1db59841e@haskell.org> References: <045.3906df0b47185ed07f8c39e1db59841e@haskell.org> Message-ID: <060.63121214d4a51d5c4fbf4546bbadd80e@haskell.org> #12769: ghc: internal error: stg_ap_pp_ret ----------------------------------+---------------------------------------- Reporter: kinnla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by kinnla): * Attachment "compiler-0.3.0.0.log" added. Log File -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 13:27:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 13:27:34 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.c9a03571caf8857986788baa59929cc1@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:1 ekmett]: > ''[...]'' email to Ross Paterson, the `transformers` maintainer. I directed him to this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 14:57:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 14:57:29 -0000 Subject: [GHC] #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault In-Reply-To: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> References: <047.69168c39b0d1a6f31c9e28cc13109bed@haskell.org> Message-ID: <062.ea81e47ec10ad73d6301ea8fe2fc6c8e@haskell.org> #12657: GHC and GHCi: RWX mmap denied by GrSec, results in a segfault -------------------------------------+------------------------------------- Reporter: PoroCYon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: grsec, pax, | mmap, rts Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I see this same error affecting libffi in python [http://www.gossamer- threads.com/lists/gentoo/hardened/288223 here], but then the discussion goes into a lot of PAX lingo that I don't understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 14:59:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 14:59:51 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.314852ef946bebf03b38393dcfa4fca8@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: upstream => patch * milestone: => 8.2.1 Comment: RyanGlScott has a nice [[https://github.com/Alexpux/MSYS2-packages/issues/707#issuecomment-256648193|workaround]] for this. I'm working on integrating this in Phab:D2641. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 15:21:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 15:21:15 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.0c11fe2ddf6ccc995f1351a1f003705e@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 21:34:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 21:34:38 -0000 Subject: [GHC] #12770: Shrink list of RUNPATH entries for GHC libraries Message-ID: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> #12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently Cabal/GHC acquired '''dynamic-library-dirs''' file tag support in ''' .conf''' files. Cabal-HEAD when used with GHC-HEAD puts all shared libraries into a single directory except the GHC itself (a fallout of https://github.com/haskell/cabal/issues/4046 ). In https://github.com/haskell/cabal/issues/4046#issuecomment-256603828 Christiaan explains our current sources of RUNPATH tags. Basically, current GHC dynamic library layout is still per-directory: {{{ /usr/lib64/ghc-8.1.20161026/Cabal-1.25.0.0/libHSCabal-1.25.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/array-0.5.1.1/libHSarray-0.5.1.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/base-4.9.0.0/libHSbase-4.9.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/binary-0.8.3.0/libHSbinary-0.8.3.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1/libHSbytestring-0.10.8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/compact-1.0.0.0/libHScompact-1.0.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/containers-0.5.7.1/libHScontainers-0.5.7.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0/libHSdeepseq-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/directory-1.2.6.2/libHSdirectory-1.2.6.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0/libHSfilepath-1.4.1.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-8.1/libHSghc-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-8.1/libHSghc- boot-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-boot-th-8.1/libHSghc-boot- th-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghc-prim-0.5.0.0/libHSghc- prim-0.5.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/ghci-8.1/libHSghci-8.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/haskeline-0.7.2.3/libHShaskeline-0.7.2.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hoopl-3.10.2.1/libHShoopl-3.10.2.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/hpc-0.6.0.3/libHShpc-0.6.0.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/integer-gmp-1.0.0.1/libHSinteger- gmp-1.0.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/pretty-1.1.3.3/libHSpretty-1.1.3.3-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/process-1.4.2.0/libHSprocess-1.4.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_debug-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/rts/libHSrts_thr_l-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/template-haskell-2.11.0.0/libHStemplate- haskell-2.11.0.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/terminfo-0.4.0.2/libHSterminfo-0.4.0.2-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/time-1.6.0.1/libHStime-1.6.0.1-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0/libHStransformers-0.5.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/unix-2.7.2.0/libHSunix-2.7.2.0-ghc8.1.20161026.so /usr/lib64/ghc-8.1.20161026/xhtml-3000.2.1/libHSxhtml-3000.2.1-ghc8.1.20161026.so }}} Could we store them exactly as Cabal does? Namely {{{ dynamic-library-dirs: /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} Then for globally installed packages (how distributions usually build packages) we would have exactly one RUNPATH. Currently we have: {{{ $ readelf -a /usr/bin/read-idiii | grep RUNPATH 0x000000000000001d (RUNPATH) Library runpath: [/usr/lib64/ghc-8.1.20161026/array-0.5.1.1:/usr/lib64/ghc-8.1.20161026/base-4.9.0.0:/usr/lib64/ghc-8.1.20161026/binary-0.8.3.0:/usr/lib64/ghc-8.1.20161026/bytestring-0.10.8.1:/usr/lib64/ghc-8.1.20161026/containers-0.5.7.1:/usr/lib64/ghc-8.1.20161026/deepseq-1.4.2.0:/usr/lib64/ghc-8.1.20161026/directory-1.2.6.2:/usr/lib64/ghc-8.1.20161026/filepath-1.4.1.0:/usr/lib64/ghc-8.1.20161026 /ghc-prim-0.5.0.0:/usr/lib64/ghc-8.1.20161026/integer- gmp-1.0.0.1:/usr/lib64/ghc-8.1.20161026/process-1.4.2.0:/usr/lib64/ghc-8.1.20161026/rts:/usr/lib64/ghc-8.1.20161026/time-1.6.0.1:/usr/lib64/ghc-8.1.20161026/transformers-0.5.2.0:/usr/lib64/ghc-8.1.20161026/unix-2.7.2.0:/usr/lib64/x86_64 -linux-ghc-8.1.20161026] }}} And that could be just single {{{ /usr/lib64/x86_64-linux-ghc-8.1.20161026 }}} It's close to ticket #11587. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 21:43:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 21:43:46 -0000 Subject: [GHC] #12770: Shrink list of RUNPATH entries for GHC libraries In-Reply-To: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> References: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> Message-ID: <060.089adae4e07ae6895f6811dc61c3eba8@haskell.org> #12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 ezyang): When I was fixing up the dynlibdir patch for merge, I attempted to do this. But I was stumped as to how to get the string `x86_64-linux- ghc-8.1.20161026` when writing in the RPATHs. And I hate debugging the Make build system, so I stopped looking at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 22:17:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 22:17:40 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries Message-ID: <044.697549dd86183293500a27a6383cbe15@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Given a static library and an import library in the same folder. e.g. {{{ libfoo.a libfoo.dll.a }}} running `ghci -lfoo` we should prefer the import library `libfoo.dll.a` over `libfoo.a` because we prefer having to just load the DLL. and not having to do any linking. This also more closely emulated the behaviour of LD, which has a search order of {{{ libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 22:23:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 22:23:27 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.67a1194571aa874c4eb3d2d155830491@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- * differential: => Phab:D2651 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 23:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 23:30:53 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries Message-ID: <051.7b4be1b0be287b220192621968128bf6@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> (Lift f a -> Lift g a) mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> (FreeT f m a -> FreeT f m' a) mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> (FreeT f m a -> FreeT f m' a) vmap :: (a -> a') -> (Vec a n -> Vec a' n) liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> (t m b -> t n b) }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: (f ~> g) -> (Lift f ~> Lift g) mapFreeT :: (Functor f, Functor m) => (m ~> m') -> (FreeT f m ~> FreeT f m') vmap :: (a -> a') -> (Vec a ~> Vec a') liftIO :: MonadIO m => IO ~> m hoist :: Monad m => (m ~> n) -> (t m ~> t n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 23:32:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 23:32:04 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.d24763d91ea74742febace87c7fd97e8@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -15,1 +15,1 @@ - -> (Lift f a -> Lift g a) + -> Lift f a -> Lift g a @@ -18,1 +18,1 @@ - -> (FreeT f m a -> FreeT f m' a) + -> FreeT f m a -> FreeT f m' a @@ -21,1 +21,1 @@ - -> (FreeT f m a -> FreeT f m' a) + -> FreeT f m a -> FreeT f m' a @@ -23,1 +23,1 @@ - -> (Vec a n -> Vec a' n) + -> Vec a n -> Vec a' n @@ -28,1 +28,1 @@ - -> (t m b -> t n b) + -> t m b -> t n b @@ -36,2 +36,2 @@ - mapLift :: (f ~> g) - -> (Lift f ~> Lift g) + mapLift :: f ~> g + -> Lift f ~> Lift g @@ -39,2 +39,2 @@ - => (m ~> m') - -> (FreeT f m ~> FreeT f m') + => m ~> m' + -> FreeT f m ~> FreeT f m' @@ -42,1 +42,1 @@ - -> (Vec a ~> Vec a') + -> Vec a ~> Vec a' @@ -46,2 +46,2 @@ - => (m ~> n) - -> (t m ~> t n) + => m ~> n + -> t m ~> t n New description: Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> Lift f a -> Lift g a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a vmap :: (a -> a') -> Vec a n -> Vec a' n liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: f ~> g -> Lift f ~> Lift g mapFreeT :: (Functor f, Functor m) => m ~> m' -> FreeT f m ~> FreeT f m' vmap :: (a -> a') -> Vec a ~> Vec a' liftIO :: MonadIO m => IO ~> m hoist :: Monad m => m ~> n -> t m ~> t n }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 23:32:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 23:32:44 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.d3bd4314901f6c0fad8fa2c8195c472d@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -16,3 +16,0 @@ - mapFreeT :: (Functor f, Functor m) - => (forall a. m a -> m' a) - -> FreeT f m a -> FreeT f m' a New description: Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> Lift f a -> Lift g a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a vmap :: (a -> a') -> Vec a n -> Vec a' n liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: f ~> g -> Lift f ~> Lift g mapFreeT :: (Functor f, Functor m) => m ~> m' -> FreeT f m ~> FreeT f m' vmap :: (a -> a') -> Vec a ~> Vec a' liftIO :: MonadIO m => IO ~> m hoist :: Monad m => m ~> n -> t m ~> t n }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 27 23:54:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 27 Oct 2016 23:54:23 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.f3ae2c3e52324ef319caad7b32c543a1@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -12,14 +12,44 @@ - unLift :: Applicative f - => Lift f a -> f a - mapLift :: (f a -> g a) - -> Lift f a -> Lift g a - mapFreeT :: (Functor f, Functor m) - => (forall a. m a -> m' a) - -> FreeT f m a -> FreeT f m' a - vmap :: (a -> a') - -> Vec a n -> Vec a' n - liftIO :: MonadIO m - => IO a -> m a - hoist :: Monad m - => (forall a. m a -> n a) - -> t m b -> t n b + unLift :: Applicative f + => Lift f a -> f a + mapLift :: (f a -> g a) + -> Lift f a -> Lift g a + mapFreeT :: (Functor f, Functor m) + => (forall a. m a -> m' a) + -> FreeT f m a -> FreeT f m' a + vmap :: (a -> a') + -> Vec a n -> Vec a' n + liftIO :: MonadIO m + => IO a -> m a + hoist :: Monad m + => (forall a. m a -> n a) + -> t m b -> t n b + trans :: (Monad m, Monad m') + => (forall a. m a -> m' a) + -> Bundle m v a -> Bundle m' v a + process :: Monad m + => (forall a. k a -> i -> a) + -> MachineT m k o -> ProcessT m i o + runAlt :: Alternative g + => (forall x. f x -> g x) + -> Alt f a -> g a + hoistAlt :: (forall a. f a -> g a) + -> Alt f b -> Alt g b + fromCurried :: Functor f + => (forall a. k a -> Curried f h a) + -> Day f k b -> h b + hoistScope :: Functor f + => (forall x. f x -> g x) + -> Scope b f a -> Scope b g a + + haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) -> [String] -> IO () + + newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (forall x. f + x -> g x) -> g a } + + newtype Builder = Builder (forall r. BuildStep r -> BuildStep r) + + data Zipper t a = Zipper (forall b. Seq b -> t b) {-# UNPACK #-} !Int + !(Seq a) + + class MonadCatch m => MonadMask m where + mask :: ((forall a. m a -> m a) -> m b) -> m b @@ -31,14 +61,43 @@ - unLift :: Applicative f - => Lift f ~> f - mapLift :: f ~> g - -> Lift f ~> Lift g - mapFreeT :: (Functor f, Functor m) - => m ~> m' - -> FreeT f m ~> FreeT f m' - vmap :: (a -> a') - -> Vec a ~> Vec a' - liftIO :: MonadIO m - => IO ~> m - hoist :: Monad m - => m ~> n - -> t m ~> t n + unLift :: Applicative f + => Lift f ~> f + mapLift :: f ~> g + -> Lift f ~> Lift g + mapFreeT :: (Functor f, Functor m) + => m ~> m' + -> FreeT f m ~> FreeT f m' + vmap :: (a -> a') + -> Vec a ~> Vec a' + liftIO :: MonadIO m + => IO ~> m + hoist :: Monad m + => m ~> n + -> t m ~> t n + trans :: (Monad m, Monad m') + => m ~> m' + -> Bundle m v ~> Bundle m' v + process :: Monad m + => k ~> (i -> ) + -> MachineT m k ~> ProcessT m i + runAlt :: Alternative g + => f ~> g + -> Alt f ~> g + hoistAlt :: f ~> g + -> Alt f ~> Alt g + fromCurried :: Functor f + => (k ~> Curried f h) + -> Day f k ~> h + hoistScope :: Functor f + => f ~> g + -> Scope b f ~> Scope b g + + haddockWithGhc :: ([Flag] -> Ghc ~> IO) -> [String] -> IO () + + newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (f ~> g) -> + g a } + + newtype Builder = Builder (BuildStep ~> BuildStep) + + data Zipper t a = Zipper (Seq ~> t) {-# UNPACK #-} !Int !(Seq a) + + class MonadCatch m => MonadMask m where + mask :: ((m ~> m) -> m b) -> m b @@ -46,0 +105,51 @@ + + these examples are pretty similar. + + ---- + + Same for + + {{{#!hs + mapBlock :: (forall e x. n e x -> n' e x) + -> Block n e x -> Block n' e x + mapGraph :: (forall e x. n e x -> n' e x) + -> Graph n e x -> Graph n' e x + mapGraphNodes1 :: (forall e x. CmmNode e x -> CmmNode e x) + -> CmmGraph -> CmmGraph + foldCat :: (Catenated t, Category s) + => (forall a b. r a b -> s a b) + -> t r a b -> s a b + mapCat :: Catenated t + => (forall a b. r a b -> s a b) + -> t r a b -> t s a b + + newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => + (forall x y. p x y -> r x y) -> r a b } + newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. + Cochoice r => (forall x y. p x y -> r x y) -> r a b } + }}} + + vs + + {{{#!hs + type f1 ~~> f2 = forall a b. f1 a b -> f2 a b + + mapBlock :: n ~~> n' + -> Block n ~~> Block n' + mapGraph :: n ~~> n' + -> Graph n ~~> Graph n' + mapGraphNodes1 :: CmmNode ~~> CmmNode + -> CmmGraph -> CmmGraph + foldCat :: (Catenated t, Category s) + => r ~~> s + -> t r ~~> s + mapCat :: Catenated t + => r ~~> s + -> t r ~~> t s + + + newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => + (p ~~> r) -> r a b } + newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. + Cochoice r => (p ~~> r) -> r a b } + }}} New description: Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> Lift f a -> Lift g a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a vmap :: (a -> a') -> Vec a n -> Vec a' n liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b trans :: (Monad m, Monad m') => (forall a. m a -> m' a) -> Bundle m v a -> Bundle m' v a process :: Monad m => (forall a. k a -> i -> a) -> MachineT m k o -> ProcessT m i o runAlt :: Alternative g => (forall x. f x -> g x) -> Alt f a -> g a hoistAlt :: (forall a. f a -> g a) -> Alt f b -> Alt g b fromCurried :: Functor f => (forall a. k a -> Curried f h a) -> Day f k b -> h b hoistScope :: Functor f => (forall x. f x -> g x) -> Scope b f a -> Scope b g a haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (forall x. f x -> g x) -> g a } newtype Builder = Builder (forall r. BuildStep r -> BuildStep r) data Zipper t a = Zipper (forall b. Seq b -> t b) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((forall a. m a -> m a) -> m b) -> m b }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: f ~> g -> Lift f ~> Lift g mapFreeT :: (Functor f, Functor m) => m ~> m' -> FreeT f m ~> FreeT f m' vmap :: (a -> a') -> Vec a ~> Vec a' liftIO :: MonadIO m => IO ~> m hoist :: Monad m => m ~> n -> t m ~> t n trans :: (Monad m, Monad m') => m ~> m' -> Bundle m v ~> Bundle m' v process :: Monad m => k ~> (i -> ) -> MachineT m k ~> ProcessT m i runAlt :: Alternative g => f ~> g -> Alt f ~> g hoistAlt :: f ~> g -> Alt f ~> Alt g fromCurried :: Functor f => (k ~> Curried f h) -> Day f k ~> h hoistScope :: Functor f => f ~> g -> Scope b f ~> Scope b g haddockWithGhc :: ([Flag] -> Ghc ~> IO) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (f ~> g) -> g a } newtype Builder = Builder (BuildStep ~> BuildStep) data Zipper t a = Zipper (Seq ~> t) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((m ~> m) -> m b) -> m b }}} these examples are pretty similar. ---- Same for {{{#!hs mapBlock :: (forall e x. n e x -> n' e x) -> Block n e x -> Block n' e x mapGraph :: (forall e x. n e x -> n' e x) -> Graph n e x -> Graph n' e x mapGraphNodes1 :: (forall e x. CmmNode e x -> CmmNode e x) -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => (forall a b. r a b -> s a b) -> t r a b -> s a b mapCat :: Catenated t => (forall a b. r a b -> s a b) -> t r a b -> t s a b newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (forall x y. p x y -> r x y) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (forall x y. p x y -> r x y) -> r a b } }}} vs {{{#!hs type f1 ~~> f2 = forall a b. f1 a b -> f2 a b mapBlock :: n ~~> n' -> Block n ~~> Block n' mapGraph :: n ~~> n' -> Graph n ~~> Graph n' mapGraphNodes1 :: CmmNode ~~> CmmNode -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => r ~~> s -> t r ~~> s mapCat :: Catenated t => r ~~> s -> t r ~~> t s newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (p ~~> r) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (p ~~> r) -> r a b } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 00:03:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 00:03:39 -0000 Subject: [GHC] #12773: Data.Functor.Classes instances for ZipList Message-ID: <051.45ef1ecec509b2c0184a30a9bc246f2a@haskell.org> #12773: Data.Functor.Classes instances for ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since `Data.Functor.Classes` is now maintained by the CLC, how about instances from [https://hackage.haskell.org/package/prelude- extras-0.4.0.1/src/src/Prelude/Extras.hs prelude-extras], at least instances for `ZipList` {{{#!hs instance Eq1 ZipList instance Ord1 ZipList instance Show1 ZipList }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 01:03:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 01:03:45 -0000 Subject: [GHC] #12774: bkpcabal02 test fails on OS X Message-ID: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> #12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While testing on Darwin today I noticed that the `bkpcabal02` test seems to fail. {{{ =====> bkpcabal02(normal) 1 of 1 [0, 0, 0] cd "./backpack/cabal/bkpcabal02/bkpcabal02.run" && $MAKE -s --no-print- directory bkpcabal02 CLEANUP=1 Wrong exit code (expected 0 , actual 2 ) Stdout: Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for bkpcabal01-0.1.0.0... Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for bkpcabal01-0.1.0.0... Stderr: make[2]: *** [bkpcabal02] Error 1 *** unexpected failure for bkpcabal02(normal) }}} Or more verbosely, {{{ $ make bkpcabal02 rm -f -r tmp.d inst dist Setup /Applications/Xcode-7.2/Xcode.app/Contents/Developer/usr/bin/make -s --no- print-directory clean '/Users/bgamari/ghc/inplace/test spaces/ghc-pkg' init tmp.d '/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' -v0 --make Setup cp p/H.hsig.in1 p/H.hsig # typecheck everything ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc='/Users/bgamari/ghc/inplace/test spaces/ghc-stage2' --ghc-options ='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -dno-debug-output' --package- db=tmp.d --prefix='/Users/bgamari/ghc/testsuite/tests/backpack/cabal/bkpcabal02/inst' ./Setup -v0 build ./Setup -v0 -v1 build Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-p' for bkpcabal01-0.1.0.0... Preprocessing library 'bkpcabal01-0.1.0.0-DwERz0Bcrkn4WeBnYMX11h-q' for bkpcabal01-0.1.0.0... cp p/H.hsig.in2 p/H.hsig ! ./Setup -v0 build make: *** [bkpcabal02] Error 1 }}} It looks like the `./Setup build` command is finishing successfully where it is expected to fail. I generally don't mind debugging this sort of issue but in this case it's quite unclear why this is expected to fail. Edward, can you add some comments to the `all.T` for this testcase (and perhaps the other Backpack tests too if neceessary) explaining what this test is supposed to be testing for and why `Setup build` should fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 01:09:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 01:09:46 -0000 Subject: [GHC] #12774: bkpcabal02 test fails on OS X In-Reply-To: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> References: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> Message-ID: <061.afbb9aad5f11a0ddd2bba36ad80a851c@haskell.org> #12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 Edward Z. Yang ): In [changeset:"815b837224fe8b7a43acebafcfc7b79a66311363/ghc" 815b837/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="815b837224fe8b7a43acebafcfc7b79a66311363" Minor doc addition as requested in #12774. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 01:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 01:10:27 -0000 Subject: [GHC] #12774: bkpcabal02 test fails on OS X In-Reply-To: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> References: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> Message-ID: <061.76ad01a671a6b12c38e686654fbd885b@haskell.org> #12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 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 ezyang): I just pushed a small doc addition. But it's pretty self-explanatory: one of the signatures has the right type (in1) and the second signature doesn't (in2). Maybe we need a sleep before we do the 'cp'? I would have thought build would take some time so that it wouldn't be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 07:17:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 07:17:41 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.596052abcd4b64eb6505ce4c043ca2cf@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 10:52:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 10:52:49 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.12160596960576087d2442140bc15850@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -9,1 +9,1 @@ - that maybe it's not worth it) + that maybe it's not worth it, ‘Fairbairn threshold’ something something) New description: Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it, ‘Fairbairn threshold’ something something) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> Lift f a -> Lift g a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a vmap :: (a -> a') -> Vec a n -> Vec a' n liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b trans :: (Monad m, Monad m') => (forall a. m a -> m' a) -> Bundle m v a -> Bundle m' v a process :: Monad m => (forall a. k a -> i -> a) -> MachineT m k o -> ProcessT m i o runAlt :: Alternative g => (forall x. f x -> g x) -> Alt f a -> g a hoistAlt :: (forall a. f a -> g a) -> Alt f b -> Alt g b fromCurried :: Functor f => (forall a. k a -> Curried f h a) -> Day f k b -> h b hoistScope :: Functor f => (forall x. f x -> g x) -> Scope b f a -> Scope b g a haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (forall x. f x -> g x) -> g a } newtype Builder = Builder (forall r. BuildStep r -> BuildStep r) data Zipper t a = Zipper (forall b. Seq b -> t b) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((forall a. m a -> m a) -> m b) -> m b }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: f ~> g -> Lift f ~> Lift g mapFreeT :: (Functor f, Functor m) => m ~> m' -> FreeT f m ~> FreeT f m' vmap :: (a -> a') -> Vec a ~> Vec a' liftIO :: MonadIO m => IO ~> m hoist :: Monad m => m ~> n -> t m ~> t n trans :: (Monad m, Monad m') => m ~> m' -> Bundle m v ~> Bundle m' v process :: Monad m => k ~> (i -> ) -> MachineT m k ~> ProcessT m i runAlt :: Alternative g => f ~> g -> Alt f ~> g hoistAlt :: f ~> g -> Alt f ~> Alt g fromCurried :: Functor f => (k ~> Curried f h) -> Day f k ~> h hoistScope :: Functor f => f ~> g -> Scope b f ~> Scope b g haddockWithGhc :: ([Flag] -> Ghc ~> IO) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (f ~> g) -> g a } newtype Builder = Builder (BuildStep ~> BuildStep) data Zipper t a = Zipper (Seq ~> t) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((m ~> m) -> m b) -> m b }}} these examples are pretty similar. ---- Same for {{{#!hs mapBlock :: (forall e x. n e x -> n' e x) -> Block n e x -> Block n' e x mapGraph :: (forall e x. n e x -> n' e x) -> Graph n e x -> Graph n' e x mapGraphNodes1 :: (forall e x. CmmNode e x -> CmmNode e x) -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => (forall a b. r a b -> s a b) -> t r a b -> s a b mapCat :: Catenated t => (forall a b. r a b -> s a b) -> t r a b -> t s a b newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (forall x y. p x y -> r x y) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (forall x y. p x y -> r x y) -> r a b } }}} vs {{{#!hs type f1 ~~> f2 = forall a b. f1 a b -> f2 a b mapBlock :: n ~~> n' -> Block n ~~> Block n' mapGraph :: n ~~> n' -> Graph n ~~> Graph n' mapGraphNodes1 :: CmmNode ~~> CmmNode -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => r ~~> s -> t r ~~> s mapCat :: Catenated t => r ~~> s -> t r ~~> t s newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (p ~~> r) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (p ~~> r) -> r a b } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 10:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 10:55:43 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.78484015b71230ae2214e5a34bd883af@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -12,33 +12,33 @@ - unLift :: Applicative f - => Lift f a -> f a - mapLift :: (f a -> g a) - -> Lift f a -> Lift g a - mapFreeT :: (Functor f, Functor m) - => (forall a. m a -> m' a) - -> FreeT f m a -> FreeT f m' a - vmap :: (a -> a') - -> Vec a n -> Vec a' n - liftIO :: MonadIO m - => IO a -> m a - hoist :: Monad m - => (forall a. m a -> n a) - -> t m b -> t n b - trans :: (Monad m, Monad m') - => (forall a. m a -> m' a) - -> Bundle m v a -> Bundle m' v a - process :: Monad m - => (forall a. k a -> i -> a) - -> MachineT m k o -> ProcessT m i o - runAlt :: Alternative g - => (forall x. f x -> g x) - -> Alt f a -> g a - hoistAlt :: (forall a. f a -> g a) - -> Alt f b -> Alt g b - fromCurried :: Functor f - => (forall a. k a -> Curried f h a) - -> Day f k b -> h b - hoistScope :: Functor f - => (forall x. f x -> g x) - -> Scope b f a -> Scope b g a - - haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) -> [String] -> IO () + unLift :: Applicative f + => Lift f a -> f a + mapLift :: (f a -> g a) + -> Lift f a -> Lift g a + mapFreeT :: (Functor f, Functor m) + => (forall a. m a -> m' a) + -> FreeT f m a -> FreeT f m' a + vmap :: (a -> a') + -> Vec a n -> Vec a' n + liftIO :: MonadIO m + => IO a -> m a + hoist :: Monad m + => (forall a. m a -> n a) + -> t m b -> t n b + trans :: (Monad m, Monad m') + => (forall a. m a -> m' a) + -> Bundle m v a -> Bundle m' v a + process :: Monad m + => (forall a. k a -> i -> a) + -> MachineT m k o -> ProcessT m i o + runAlt :: Alternative g + => (forall x. f x -> g x) + -> Alt f a -> g a + hoistAlt :: (forall a. f a -> g a) + -> Alt f b -> Alt g b + fromCurried :: Functor f + => (forall a. k a -> Curried f h a) + -> Day f k b -> h b + hoistScope :: Functor f + => (forall x. f x -> g x) + -> Scope b f a -> Scope b g a + haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) + -> [String] -> IO () @@ -61,33 +61,33 @@ - unLift :: Applicative f - => Lift f ~> f - mapLift :: f ~> g - -> Lift f ~> Lift g - mapFreeT :: (Functor f, Functor m) - => m ~> m' - -> FreeT f m ~> FreeT f m' - vmap :: (a -> a') - -> Vec a ~> Vec a' - liftIO :: MonadIO m - => IO ~> m - hoist :: Monad m - => m ~> n - -> t m ~> t n - trans :: (Monad m, Monad m') - => m ~> m' - -> Bundle m v ~> Bundle m' v - process :: Monad m - => k ~> (i -> ) - -> MachineT m k ~> ProcessT m i - runAlt :: Alternative g - => f ~> g - -> Alt f ~> g - hoistAlt :: f ~> g - -> Alt f ~> Alt g - fromCurried :: Functor f - => (k ~> Curried f h) - -> Day f k ~> h - hoistScope :: Functor f - => f ~> g - -> Scope b f ~> Scope b g - - haddockWithGhc :: ([Flag] -> Ghc ~> IO) -> [String] -> IO () + unLift :: Applicative f + => Lift f ~> f + mapLift :: f ~> g + -> Lift f ~> Lift g + mapFreeT :: (Functor f, Functor m) + => m ~> m' + -> FreeT f m ~> FreeT f m' + vmap :: (a -> a') + -> Vec a ~> Vec a' + liftIO :: MonadIO m + => IO ~> m + hoist :: Monad m + => m ~> n + -> t m ~> t n + trans :: (Monad m, Monad m') + => m ~> m' + -> Bundle m v ~> Bundle m' v + process :: Monad m + => k ~> (i -> ) + -> MachineT m k ~> ProcessT m i + runAlt :: Alternative g + => f ~> g + -> Alt f ~> g + hoistAlt :: f ~> g + -> Alt f ~> Alt g + fromCurried :: Functor f + => k ~> Curried f h + -> Day f k ~> h + hoistScope :: Functor f + => f ~> g + -> Scope b f ~> Scope b g + haddockWithGhc :: ([Flag] -> Ghc ~> IO) + -> [String] -> IO () New description: Is this something that belongs to core libraries (it has other names in the wild, `:~>`, `Natural`..) {{{#!hs type f1 ~> f2 = forall a. f1 a -> f2 a }}} I use it all the time and end up redefining it (it is such a short type that maybe it's not worth it, ‘Fairbairn threshold’ something something) {{{#!hs unLift :: Applicative f => Lift f a -> f a mapLift :: (f a -> g a) -> Lift f a -> Lift g a mapFreeT :: (Functor f, Functor m) => (forall a. m a -> m' a) -> FreeT f m a -> FreeT f m' a vmap :: (a -> a') -> Vec a n -> Vec a' n liftIO :: MonadIO m => IO a -> m a hoist :: Monad m => (forall a. m a -> n a) -> t m b -> t n b trans :: (Monad m, Monad m') => (forall a. m a -> m' a) -> Bundle m v a -> Bundle m' v a process :: Monad m => (forall a. k a -> i -> a) -> MachineT m k o -> ProcessT m i o runAlt :: Alternative g => (forall x. f x -> g x) -> Alt f a -> g a hoistAlt :: (forall a. f a -> g a) -> Alt f b -> Alt g b fromCurried :: Functor f => (forall a. k a -> Curried f h a) -> Day f k b -> h b hoistScope :: Functor f => (forall x. f x -> g x) -> Scope b f a -> Scope b g a haddockWithGhc :: (forall a. [Flag] -> Ghc a -> IO a) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (forall x. f x -> g x) -> g a } newtype Builder = Builder (forall r. BuildStep r -> BuildStep r) data Zipper t a = Zipper (forall b. Seq b -> t b) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((forall a. m a -> m a) -> m b) -> m b }}} becomes {{{#!hs unLift :: Applicative f => Lift f ~> f mapLift :: f ~> g -> Lift f ~> Lift g mapFreeT :: (Functor f, Functor m) => m ~> m' -> FreeT f m ~> FreeT f m' vmap :: (a -> a') -> Vec a ~> Vec a' liftIO :: MonadIO m => IO ~> m hoist :: Monad m => m ~> n -> t m ~> t n trans :: (Monad m, Monad m') => m ~> m' -> Bundle m v ~> Bundle m' v process :: Monad m => k ~> (i -> ) -> MachineT m k ~> ProcessT m i runAlt :: Alternative g => f ~> g -> Alt f ~> g hoistAlt :: f ~> g -> Alt f ~> Alt g fromCurried :: Functor f => k ~> Curried f h -> Day f k ~> h hoistScope :: Functor f => f ~> g -> Scope b f ~> Scope b g haddockWithGhc :: ([Flag] -> Ghc ~> IO) -> [String] -> IO () newtype Alt f a = Alt { _runAlt :: forall g. Alternative g => (f ~> g) -> g a } newtype Builder = Builder (BuildStep ~> BuildStep) data Zipper t a = Zipper (Seq ~> t) {-# UNPACK #-} !Int !(Seq a) class MonadCatch m => MonadMask m where mask :: ((m ~> m) -> m b) -> m b }}} these examples are pretty similar. ---- Same for {{{#!hs mapBlock :: (forall e x. n e x -> n' e x) -> Block n e x -> Block n' e x mapGraph :: (forall e x. n e x -> n' e x) -> Graph n e x -> Graph n' e x mapGraphNodes1 :: (forall e x. CmmNode e x -> CmmNode e x) -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => (forall a b. r a b -> s a b) -> t r a b -> s a b mapCat :: Catenated t => (forall a b. r a b -> s a b) -> t r a b -> t s a b newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (forall x y. p x y -> r x y) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (forall x y. p x y -> r x y) -> r a b } }}} vs {{{#!hs type f1 ~~> f2 = forall a b. f1 a b -> f2 a b mapBlock :: n ~~> n' -> Block n ~~> Block n' mapGraph :: n ~~> n' -> Graph n ~~> Graph n' mapGraphNodes1 :: CmmNode ~~> CmmNode -> CmmGraph -> CmmGraph foldCat :: (Catenated t, Category s) => r ~~> s -> t r ~~> s mapCat :: Catenated t => r ~~> s -> t r ~~> t s newtype Copastro p a b = Copastro { runCopastro :: forall r. Costrong r => (p ~~> r) -> r a b } newtype CopastroSum p a b = CopastroSum { runCopastroSum :: forall r. Cochoice r => (p ~~> r) -> r a b } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 14:51:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 14:51:12 -0000 Subject: [GHC] #12775: T3424 hangs with -fregs-graph Message-ID: <046.8eb4f2eb1a5a8ac601518c251849bb7a@haskell.org> #12775: T3424 hangs with -fregs-graph -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: T3424 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The -fregs-graph option causes rts/T3424 to hang. I waited 15+ minutes when compiling with inplace/ghc-stage2 before killing it; when run with the test suite after a similarly long time I get a compile failed (exit code 99) message. It passes when run in ghci or when using the default register allocator. To reproduce: make TEST=T3424 EXTRA_HC_OPTIONS=-fregs-graph -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 15:41:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 15:41:55 -0000 Subject: [GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant In-Reply-To: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> References: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> Message-ID: <061.57334d28ca1880d3106c535500c7aad3@haskell.org> #12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 Simon Peyton Jones ): In [changeset:"7187dedabec8e01394578c9f40241ca3d644a4f8/ghc" 7187deda/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7187dedabec8e01394578c9f40241ca3d644a4f8" Clarify comments on kinds (Trac #12536) - Remove misleading comments from TyCoRep. - Remove 'check_lifted' calls (which were no-ops) from TcValidity. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 15:49:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 15:49:08 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 Message-ID: <049.733544d3a8e60b86f28a261013106260@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm getting a panic! in GHC 8.0.1 and in 8.1.20161028 {{{ sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Main.hs -O2 [1 of 2] Compiling Factorize ( Factorize.hs, Factorize.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161028 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $slast_s_s1IU To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 18241 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached is some code which I tried to make as small as possible (it therefore does not make sense, but it reproduces the panic). The panic! only occurs with -O2 (I need the -O2 switch to optimise the automatically generated Haskell code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 15:50:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 15:50:10 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.63e470eafc190f675bff3a8b123fd4a3@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 sjcjoosten): * Attachment "Factorize.hs" added. PanicForO2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 15:51:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 15:51:41 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.3cb13431b804b3619f088fc3ba1e9d47@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjcjoosten): * priority: normal => high * failure: None/Unknown => Compile-time crash or panic @@ -5,1 +5,1 @@ - sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Main.hs -O2 + sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Factorize.hs -O2 New description: I'm getting a panic! in GHC 8.0.1 and in 8.1.20161028 {{{ sjoosten:ghcCompileBug sjc$ ghc-8.1.20161028 --make Factorize.hs -O2 [1 of 2] Compiling Factorize ( Factorize.hs, Factorize.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161028 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $slast_s_s1IU To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 18241 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Attached is some code which I tried to make as small as possible (it therefore does not make sense, but it reproduces the panic). The panic! only occurs with -O2 (I need the -O2 switch to optimise the automatically generated Haskell code). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 16:02:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 16:02:58 -0000 Subject: [GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant In-Reply-To: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> References: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> Message-ID: <061.be81a8d153bed13d827121c5d7a7657e@haskell.org> #12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 19:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 19:24:16 -0000 Subject: [GHC] #12775: T3424 hangs with -fregs-graph In-Reply-To: <046.8eb4f2eb1a5a8ac601518c251849bb7a@haskell.org> References: <046.8eb4f2eb1a5a8ac601518c251849bb7a@haskell.org> Message-ID: <061.b6e6e9d19836272662f08fcc053ddef4@haskell.org> #12775: T3424 hangs with -fregs-graph -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T3424 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * status: new => closed * resolution: => worksforme Comment: It works with THREADS=8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:30:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:30:14 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional rependencies Message-ID: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> #12777: reify yields the wrong type in the presence of functional rependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{reify}}} yields an incomplete type in the following program. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE FunctionalDependencies #-} module B where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH class C a b | a -> b where yo :: a -> IO b instance C Bool Int where yo = undefined t3 :: IO () t3 = do x <- yo True $(do addModFinalizer $ TH.reify 'x >>= runIO . print [| return () |] ) }}} {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627401898 (VarT a_1627404604) Nothing }}} The problem seems to be that finalizers run before functional dependencies are considered. Hacking ghc to run finalizers after {{{simplifyTop}}} produces the expected output instead: {{{ $ inplace/bin/ghc-stage2 B.hs -fforce-recomp [1 of 1] Compiling B ( B.hs, B.o ) VarI x_1627404863 (ConT GHC.Types.Int) Nothing }}} Would anyone object to running finalizers after {{{simplifyTop}}}? This implies that finalizers shouldn't add definitions (with {{{addTopDecls}}}) which depend on {{{simplifyTop}}} to be type-checked. Another option is to call {{{simplifyTop}}} before and after running finalizers. But is it safe to do so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:31:02 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional rependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.fc5f89737733790d0ac60953fd664fa2@haskell.org> #12777: reify yields the wrong type in the presence of functional rependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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 facundo.dominguez): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:32:42 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies (was: reify yields the wrong type in the presence of functional rependencies) In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.9696f9bec64c7d27876b6ca830870193@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:33:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:33:56 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.2e3d88f623c1397f359710468c7061f0@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 RyanGlScott): I can't reproduce it with GHC 8.0.2: {{{ $ /opt/ghc/8.0.2/bin/ghc -fobject-code -fdefer-typed-holes Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:10: error: Variable not in scope: x Bug.hs:5:27: error: Variable not in scope: x Bug.hs:6:11: error: Variable not in scope: x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:39:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:39:31 -0000 Subject: [GHC] #12730: Pattern synonym signature fails with unlifted type In-Reply-To: <051.2c91bfc5f6856413eaae1aa6a5bc0ff4@haskell.org> References: <051.2c91bfc5f6856413eaae1aa6a5bc0ff4@haskell.org> Message-ID: <066.15350a56fc859b6d4c139b10649fbd6d@haskell.org> #12730: Pattern synonym signature fails with unlifted type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12094 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12094 * milestone: => 8.0.2 Comment: It indeed works with GHC 8.0.2, so I'll close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 20:55:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 20:55:08 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.6f28e895614abd385aebe5d3f2f39077@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed Comment: Good; let's jut close it. I doubt it's even worth a regression test, but it'd do no harm to add one if someone wants to take a minute to do so. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:00:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:00:50 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify Message-ID: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{ {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH as TH import Language.Haskell.TH.Syntax as TH foo :: IO () foo = $([| let x = True in $(do addModFinalizer $ do Just name <- TH.lookupValueName "x" TH.reify name >>= runIO . print [| return () |] ) |]) }}} When compiled, {{{TH.lookupValueName}}} fails to find {{{x}}}. {{{ $ inplace/bin/ghc-stage2 A.hs -fforce-recomp [1 of 1] Compiling A ( A.hs, A.o ) A.hs:7:9: error: • Pattern match failure in do expression at A.hs:9:23-31 • In the expression: (let x_a3Jy = True in return ()) In an equation for ‘foo’: foo = (let x_a3Jy = True in return ()) }}} It would make producing bindings in {{{inline-java}}} better if the type of {{{x}}} could be found in the finalizer. According to comments in ghc, {{{[| \x -> $(f [| x |]) |]}}} desugars to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (f (var x1)) }}} which erases any hint that a splice point existed at all. This information is necessary to know which variables were in scope. How about we add a some new methods to the `Q` monad for the sake of marking inner splices: {{{ class Q m where ... qSpliceE :: m Exp -> m Exp qSpliceP :: m Pat -> m Pat qSpliceT :: m Type -> m Type ... }}} Now {{{[| \x -> $(f [| x |]) |]}}} would desugar to {{{ gensym (unpackString "x"#) `bindQ` \ x1::String -> lam (pvar x1) (qSpliceE (f (var x1))) }}} When the renamer executes these primitives, it would be aware of the inner splices and could treat them similarly to top-level splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:03:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:03:05 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.9ccc61b3886ac3da31a11bee9374da7e@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 Ryan Scott ): In [changeset:"60343a419ab44d387cfd11f0dd2b522fd922e63a/ghc" 60343a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60343a419ab44d387cfd11f0dd2b522fd922e63a" Add test for #12732 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:04:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:04:04 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.5423f017f8cf3df70a00738d609db8cf@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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 RyanGlScott): * status: closed => merge * milestone: => 8.0.2 Comment: As this works in GHC 8.0.2, this could be merged safely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:48:42 -0000 Subject: [GHC] #12779: isTrue# doesn't work in ghci anymore Message-ID: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> #12779: isTrue# doesn't work in ghci anymore -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12718 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!haskell GHCi, version 8.1.20161028: http://www.haskell.org/ghc/ :? for help Prelude> :set -XMagicHash Prelude> :m + GHC.Types Prelude GHC.Types> isTrue# 123# True Prelude GHC.Types> [1] 3181 segmentation fault ghc-stage2 --interactive }}} This is also the reason why #12718 is segfaulting. I'm currently working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:49:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:49:16 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.9eda66f3f422c07e737dbed738da0390@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #12779 Comment: This is because of #12779. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:52:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:52:43 -0000 Subject: [GHC] #12779: isTrue# doesn't work in ghci anymore In-Reply-To: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> References: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> Message-ID: <058.edab9edf34a3af564e27f1afd2d324e0@haskell.org> #12779: isTrue# doesn't work in ghci anymore -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: @@ -13,0 +13,2 @@ + + `isTrue#` is failing in 8.0.1 too. New description: {{{#!haskell GHCi, version 8.1.20161028: http://www.haskell.org/ghc/ :? for help Prelude> :set -XMagicHash Prelude> :m + GHC.Types Prelude GHC.Types> isTrue# 123# True Prelude GHC.Types> [1] 3181 segmentation fault ghc-stage2 --interactive }}} This is also the reason why #12718 is segfaulting. I'm currently working on this. `isTrue#` is failing in 8.0.1 too. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 21:58:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 21:58:10 -0000 Subject: [GHC] #12779: isTrue# doesn't work in ghci anymore In-Reply-To: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> References: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> Message-ID: <058.25f0aebe11bdead3dac309a18bf734f0@haskell.org> #12779: isTrue# doesn't work in ghci anymore -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `isTrue# 123#` isn't allowed. The argument must be `0#` or `1#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 22:33:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 22:33:58 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.00ea8fa2e8cb41e041ce6753319e478a@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104, Wiki Page: | Phab:D2655 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: closed => new * owner: facundo.dominguez => * differential: Phab:D2104 => Phab:D2104, Phab:D2655 * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 22:34:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 22:34:22 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.7fd91aeadbb3adfd123581ff1530f05e@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104, Wiki Page: | Phab:D2655 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 22:35:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 22:35:26 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.e73f8095eeeb3e6b8bae4c9a2f8cf928@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify 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 facundo.dominguez): * keywords: => template-haskell reify -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 28 22:36:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 28 Oct 2016 22:36:36 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.36991184636261765ef52ee1f4a5d8e4@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify 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 facundo.dominguez): * keywords: => template-haskell reify -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 00:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 00:01:29 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.c6b6b276e6513127824037fdd2b8e42c@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): rwbarton pointed out in #12779 that argument of `isTrue#` should be `0#` or `1#`. The documentation also says the same thing in different words: {{{#!haskell {-# INLINE isTrue# #-} -- | Alias for 'tagToEnum#'. Returns True if its parameter is 1# and False -- if it is 0#. isTrue# :: Int# -> Bool -- See Note [Optimizing isTrue#] isTrue# x = tagToEnum# x }}} So maybe this is expected and we can close this ticket and #12779. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 00:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 00:07:47 -0000 Subject: [GHC] #12779: isTrue# doesn't work in ghci anymore In-Reply-To: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> References: <043.11b457a55b036a2d5f58d2068c09e874@haskell.org> Message-ID: <058.0693a168679cd2509878774b12c898fa@haskell.org> #12779: isTrue# doesn't work in ghci anymore -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Documentation of `isTrue#` agrees with that: {{{#!haskell {-# INLINE isTrue# #-} -- | Alias for 'tagToEnum#'. Returns True if its parameter is 1# and False -- if it is 0#. isTrue# :: Int# -> Bool -- See Note [Optimizing isTrue#] isTrue# x = tagToEnum# x }}} but there's also this in the same file: {{{#!haskell {- Note [Optimizing isTrue#] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Current definition of isTrue# is a temporary workaround. We would like to have functions isTrue# and isFalse# defined like this: isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} So I'm not sure what's the correct behavior here. Would raising a panic be too costly here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 04:05:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 04:05:12 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.dc915bdfc58f53a178269f5681a867d6@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:7 osa1]: > rwbarton pointed out in #12779 that argument of `isTrue#` should be `0#` or `1#`. ''[...]'' Liquid Haskell be like?? {{{#!hs isTrue# :: { v:Int# | v == 0# || v == 1# } -> Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 05:56:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 05:56:16 -0000 Subject: [GHC] #12042: Infinite loop with type synonyms and hs-boot In-Reply-To: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> References: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> Message-ID: <060.0c25aaefa7ea6c52750590aaf8f9b5f2@haskell.org> #12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2656 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 05:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 05:57:25 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't Message-ID: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following has been compiled against ghc version 8.1.20161022, my apologies if this bug has already been fixed. The following program compiles fine: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} main :: IO () main = return () type family F p = t | t -> p type IsF p t = (C p, t ~ F p) class C p where f :: (IsF p t) => t f = undefined g :: (IsF p t) => t g = f }}} But if we define a "do nothing" type checker plugin like so: {{{#!hs {-# OPTIONS_GHC -dynamic-too #-} module MyPlugin (plugin) where import Plugins ( Plugin(tcPlugin), defaultPlugin, tcPlugin ) import TcRnTypes ( TcPlugin(TcPlugin), tcPluginInit, tcPluginSolve, tcPluginStop, TcPluginSolver, TcPluginResult(TcPluginContradiction, TcPluginOk) ) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } myPlugin :: TcPlugin myPlugin = TcPlugin { tcPluginInit = return (), tcPluginSolve = const solver, tcPluginStop = const (return ()) } solver :: TcPluginSolver solver _ _ _ = return $ TcPluginOk [] [] }}} And call it from our original source file by adding: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} }}} We get the following error: {{{ pluginbug.hs:18:5: error: • Could not deduce (C p0, t ~ F p0) arising from a use of ‘f’ from the context: IsF p t bound by the type signature for: g :: IsF p t => t at pluginbug.hs:17:1-19 The type variable ‘p0’ is ambiguous Relevant bindings include g :: t (bound at pluginbug.hs:18:1) • In the expression: f In an equation for ‘g’: g = f }}} Note that not just calling my "do nothing" type checking plugin does this, to be sure, instead I called `ghc-typelits-natnormalise` like so: {{{#!hs {-# OPTIONS_GHC -fplugin GHC.TypeLits.Normalise #-} }}} And the same error results. One solution is to remove `(C p)` from the `IsF` type declaration, and instead adding it to `g`s definition, like so: {{{#!hs --type IsF p t = (C p, t ~ F p) type IsF p t = (t ~ F p) --g :: (IsF p t) => t g :: (C p, IsF p t) => t }}} But I'm unsure why this should be necessary, and I certainly don't think this should only be necessary if one calls a type checker plugin. Note that the error requires a type checking plugin to be called, if one does not override `defaultPlugin` like so: {{{#!hs plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } }}} and instead just does: {{{#!hs plugin = defaultPlugin }}} then the issue will not occur. So in summary, it seems that calling a type checking plugin somehow affects ordinary type checking. I don't think this should happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 05:58:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 05:58:17 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.77a5e90a27e023a86a5b93d618976b9c@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "pluginbug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 05:58:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 05:58:32 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.0e73125d8908c7880c2c47076357d460@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "MyPlugin.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 06:00:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 06:00:26 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.9d81496d3bd77e76ebbe50b2f91275ac@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 06:50:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 06:50:43 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.c17ed32bf8b7da7850280a5399eeab34@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by clinton: @@ -101,2 +101,36 @@ - But I'm unsure why this should be necessary, and I certainly don't think - this should only be necessary if one calls a type checker plugin. + In addition, either of the following two solutions will get the code to + compile: + + 1. Replacing the reference to `IsF p t` in the class signature with `t ~ F + p` like so: + + {{{#!hs + -- f :: (IsF p t) => t + f :: (t ~ F p) => t + }}} + + 2. Alternatively, expanding out `IsF p t` in the signature of `g` as + follows: + + {{{#!hs + --g :: (IsF p t) => t + g :: (C p, t ~ F p) => t + }}} + + Note that is we remove the class `C` entirely (making `f` an ordinary + function) the bug disappears, but if instead replace the class with a + constraint `C` like so: + + {{{#!hs + type family C t :: Constraint + }}} + + the bug still appears. + + So it seems this bug needs four things to all occur for it to appear: + + 1. A type constraint synonym in the calling code. + 2. A type constraint synonym in the called code. + 3. The type constraint synonym to contain a class constraint, or at least + a non-equality one. + 4. A type checking plugin to be called. @@ -120,1 +154,2 @@ - affects ordinary type checking. I don't think this should happen. + affects ordinary type checking in particular circumstances. I don't think + this should happen. New description: The following has been compiled against ghc version 8.1.20161022, my apologies if this bug has already been fixed. The following program compiles fine: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} main :: IO () main = return () type family F p = t | t -> p type IsF p t = (C p, t ~ F p) class C p where f :: (IsF p t) => t f = undefined g :: (IsF p t) => t g = f }}} But if we define a "do nothing" type checker plugin like so: {{{#!hs {-# OPTIONS_GHC -dynamic-too #-} module MyPlugin (plugin) where import Plugins ( Plugin(tcPlugin), defaultPlugin, tcPlugin ) import TcRnTypes ( TcPlugin(TcPlugin), tcPluginInit, tcPluginSolve, tcPluginStop, TcPluginSolver, TcPluginResult(TcPluginContradiction, TcPluginOk) ) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } myPlugin :: TcPlugin myPlugin = TcPlugin { tcPluginInit = return (), tcPluginSolve = const solver, tcPluginStop = const (return ()) } solver :: TcPluginSolver solver _ _ _ = return $ TcPluginOk [] [] }}} And call it from our original source file by adding: {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} }}} We get the following error: {{{ pluginbug.hs:18:5: error: • Could not deduce (C p0, t ~ F p0) arising from a use of ‘f’ from the context: IsF p t bound by the type signature for: g :: IsF p t => t at pluginbug.hs:17:1-19 The type variable ‘p0’ is ambiguous Relevant bindings include g :: t (bound at pluginbug.hs:18:1) • In the expression: f In an equation for ‘g’: g = f }}} Note that not just calling my "do nothing" type checking plugin does this, to be sure, instead I called `ghc-typelits-natnormalise` like so: {{{#!hs {-# OPTIONS_GHC -fplugin GHC.TypeLits.Normalise #-} }}} And the same error results. One solution is to remove `(C p)` from the `IsF` type declaration, and instead adding it to `g`s definition, like so: {{{#!hs --type IsF p t = (C p, t ~ F p) type IsF p t = (t ~ F p) --g :: (IsF p t) => t g :: (C p, IsF p t) => t }}} In addition, either of the following two solutions will get the code to compile: 1. Replacing the reference to `IsF p t` in the class signature with `t ~ F p` like so: {{{#!hs -- f :: (IsF p t) => t f :: (t ~ F p) => t }}} 2. Alternatively, expanding out `IsF p t` in the signature of `g` as follows: {{{#!hs --g :: (IsF p t) => t g :: (C p, t ~ F p) => t }}} Note that is we remove the class `C` entirely (making `f` an ordinary function) the bug disappears, but if instead replace the class with a constraint `C` like so: {{{#!hs type family C t :: Constraint }}} the bug still appears. So it seems this bug needs four things to all occur for it to appear: 1. A type constraint synonym in the calling code. 2. A type constraint synonym in the called code. 3. The type constraint synonym to contain a class constraint, or at least a non-equality one. 4. A type checking plugin to be called. Note that the error requires a type checking plugin to be called, if one does not override `defaultPlugin` like so: {{{#!hs plugin = defaultPlugin { tcPlugin = const (Just myPlugin) } }}} and instead just does: {{{#!hs plugin = defaultPlugin }}} then the issue will not occur. So in summary, it seems that calling a type checking plugin somehow affects ordinary type checking in particular circumstances. I don't think this should happen. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 06:52:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 06:52:17 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.d1907adadf120c88a0ba1e4fe06f745e@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "pluginbug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 06:52:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 06:52:17 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.77a5e90a27e023a86a5b93d618976b9c@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "pluginbug.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 08:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 08:42:11 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.d1907adadf120c88a0ba1e4fe06f745e@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "pluginbug.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 08:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 08:42:11 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.3522d801c484f0bee085c21df0645e2a@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * Attachment "pluginbug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 10:23:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 10:23:09 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.556ace1506a18c9b4d744f67e8082a26@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -2,2 +2,2 @@ - users!),[#point1 (1)] precedence levels may vary between languages and - then there are user-defined operators. + users!),[#point1 ¹][#point2 ²] precedence levels may vary between + languages and then there are user-defined operators. @@ -9,1 +9,2 @@ - {{{ + + {{{#!hs @@ -25,2 +26,6 @@ - [=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer - beliefs about binary operator precedence] + [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs + about binary operator precedence] + [=#point2 ²] + [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace + Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 + tweet]) New description: Operator fixity can be a source of bugs (even for experienced users!),[#point1 ¹][#point2 ²] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{#!hs ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] [=#point2 ²] [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 tweet]) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 10:23:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 10:23:40 -0000 Subject: [GHC] #8751: Show parenthesised output of expressions in ghci In-Reply-To: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> References: <051.64a3a6e4a9644c56cf4e2e987a774ebd@haskell.org> Message-ID: <066.d3133dc89cedd5c570ed8267ded33d85@haskell.org> #8751: Show parenthesised output of expressions in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -2,1 +2,1 @@ - users!),[#point1 ¹][#point2 ²] precedence levels may vary between + users!),[#point1 ¹] [#point2 ²] precedence levels may vary between @@ -28,0 +28,1 @@ + New description: Operator fixity can be a source of bugs (even for experienced users!),[#point1 ¹] [#point2 ²] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{#!hs ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 ¹] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] [=#point2 ²] [http://ieeexplore.ieee.org/document/7548903/?platform=hootsuite Brace Yourself] ([https://twitter.com/ieeesoftware/status/791882437295038464 tweet]) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 15:56:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 15:56:06 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE Message-ID: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program allocates much more memory ("bytes allocated in the heap") in its current form than with INLINE replaced by NOINLINE, as in the comment. That may be normal, but virtually every feature of this example is needed to trigger the behaviour and so I have no clear idea which language feature is responsible and should be avoided and, consequently, how to optimize my much more complex codebase (in which INLINES of once used functions tend to help and sometimes significantly so). As a comment to this ticket I will post another example, where the difference in allocation is pumped to a factor of 2000, as a proof that the issue is serious. {{{ {-# LANGUAGE RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE and observe lower alloc dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (_, x) = pI `quotRem` z in P x m = IM.lookup (fromEnum p0) IM.empty b = IM.member (fromEnum p1) IM.empty in m == Just 'c' `seq` b `seq` () {-# NOINLINE l #-} l = [0..10000000] mapVT :: forall s. () -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l return $! runST (mapVT ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 15:57:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 15:57:39 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.699958db69d08c793323d0300ac971d6@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Here is the example where the code with INLINE allocates 2000 times more heap memory that with NOINLINE: {{{ {-# LANGUAGE BangPatterns, RankNTypes #-} import Control.Monad.ST.Strict import qualified Data.IntMap.Strict as IM import Data.List import Data.Maybe -- ghc --make -O1 InlineBloat.hs; ./InlineBloat +RTS -s data P = P !Int instance Enum P where fromEnum (P x) = x toEnum n = undefined main = do let {-# NOINLINE z #-} z = 44 dis :: Int -> () {-# INLINE dis #-} -- change here to NOINLINE -- -- with INLINE: -- 384,409,080 bytes allocated in the heap -- with NOINLINE: -- 169,080 bytes allocated in the heap dis pI = let p0 = let (_, x) = pI `quotRem` z in P x p1 = let (y, _) = pI `quotRem` z in P y !_ = isJust $ IM.lookup (fromEnum p0) IM.empty !_ = isJust $ IM.lookup (fromEnum p1) IM.empty in () {-# NOINLINE l #-} l = [0..1600] mapVT :: forall s. Int -> ST s () {-# INLINE mapVT #-} mapVT _ = mapM_ (\x -> return $! dis x) l !runRes = foldl' (\() n -> runST (mapVT n)) () [1..10000] return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:04:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:04:34 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.c7e830fa6eb04fa697c86c1dc145860d@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12747, 12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => 12747, 12781 @@ -8,0 +8,38 @@ + + + Edit: here is a minimal example: + + {{{ + -- ghc --make Main.hs -O1; ./Main +RTS -s -RTS + + seqFrame2 :: [Int] -> IO () + {-# NOINLINE seqFrame2 #-} + seqFrame2 l = do + let crux = attrFromInt + -- Total time 2.052s ( 2.072s elapsed) + -- but the following version is many times slower: + -- let crux = attrFromIntINLINE + -- Total time 7.896s ( 7.929s elapsed) + mapM_ (\a -> crux a `seq` return ()) l + + main :: IO () + main = seqFrame2 $ replicate 100000000 0 + + + data Attr = Attr !Int --- the bang is essential + + attrFromInt :: Int -> Attr + {-# NOINLINE attrFromInt #-} + attrFromInt w = Attr (w + (2 ^ (8 :: Int))) + + fgFromInt :: Int -> Int + {-# INLINE fgFromInt #-} -- removing this INLINE makes it many times + faster + -- just like the manually inlined version + -- and NOINLINE lands in between + fgFromInt w = w + (2 ^ (8 :: Int)) + + attrFromIntINLINE :: Int -> Attr + {-# NOINLINE attrFromIntINLINE #-} + attrFromIntINLINE w = Attr (fgFromInt w) + }}} New description: Mikolaj reported that he was seeing significantly different code generated in the case of an `INLINE` pragma versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb001020870b2d/Game/LambdaHack/Common/Color.hs#L99. Edit: here is a minimal example: {{{ -- ghc --make Main.hs -O1; ./Main +RTS -s -RTS seqFrame2 :: [Int] -> IO () {-# NOINLINE seqFrame2 #-} seqFrame2 l = do let crux = attrFromInt -- Total time 2.052s ( 2.072s elapsed) -- but the following version is many times slower: -- let crux = attrFromIntINLINE -- Total time 7.896s ( 7.929s elapsed) mapM_ (\a -> crux a `seq` return ()) l main :: IO () main = seqFrame2 $ replicate 100000000 0 data Attr = Attr !Int --- the bang is essential attrFromInt :: Int -> Attr {-# NOINLINE attrFromInt #-} attrFromInt w = Attr (w + (2 ^ (8 :: Int))) fgFromInt :: Int -> Int {-# INLINE fgFromInt #-} -- removing this INLINE makes it many times faster -- just like the manually inlined version -- and NOINLINE lands in between fgFromInt w = w + (2 ^ (8 :: Int)) attrFromIntINLINE :: Int -> Attr {-# NOINLINE attrFromIntINLINE #-} attrFromIntINLINE w = Attr (fgFromInt w) }}} -- Comment: I've created a separate ticket for the case 2 (much more allocation with INLINE than NOINLINE): https://ghc.haskell.org/trac/ghc/ticket/12781 So, now cases 3 and 2 have separate tickets and so I move (a new version of) minimal example for case 1 to the main ticket description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:07:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:07:07 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.67c99168e5d7002e86c0bc7c9a0b18b8@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #12747 #12781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:07:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:07:28 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.5d5298564ea7506312effb6478d7a7ab@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #12747 #12781 => #12747 #12603 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:08:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:08:57 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.f792cb9dcce5e3b7d71fddbd747c6ebc@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #12603 #12781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:09:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:09:14 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.cba4d9ac138f68bb8ac68786c7751830@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: 12747, 12781 => #12747 #12781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:14:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:14:35 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.7a1152549fe7322c5343541efdcf9036@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -5,3 +5,1 @@ - produces distinct figures in all three cases. - - See + produces distinct heap memory allocation figures in all three cases, see @@ -30,0 +28,3 @@ + + [Edit: another example is the code in description of ticket #12603, where + INLINE, NOINLINE and each produce different "MUT time".] New description: INLINE vs NOINLE vs for this function https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145 produces distinct heap memory allocation figures in all three cases, see https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be , and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. [Edit: another example is the code in description of ticket #12603, where INLINE, NOINLINE and each produce different "MUT time".] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:15:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:15:05 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.8acb97a353e6ec1c2570e09f311d07a1@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -29,2 +29,3 @@ - [Edit: another example is the code in description of ticket #12603, where - INLINE, NOINLINE and each produce different "MUT time".] + [Edit: another example is the code in description of ticket + https://ghc.haskell.org/trac/ghc/ticket/12603, where INLINE, NOINLINE and + each produce different "MUT time".] New description: INLINE vs NOINLE vs for this function https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145 produces distinct heap memory allocation figures in all three cases, see https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be , and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. [Edit: another example is the code in description of ticket https://ghc.haskell.org/trac/ghc/ticket/12603, where INLINE, NOINLINE and each produce different "MUT time".] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:15:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:15:51 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.4a0b96d6b265b0d25240be7bc357aef0@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -31,1 +31,2 @@ - each produce different "MUT time".] + each produce different "MUT time" in the place marked with "and + NOINLINE lands in between".] New description: INLINE vs NOINLE vs for this function https://github.com/LambdaHack/LambdaHack/blob/e7b31a0d937b6ef6e53665eab23663dcaf4ced81/Game/LambdaHack/Client/UI/DrawM.hs#L145 produces distinct heap memory allocation figures in all three cases, see https://ghc.haskell.org/trac/ghc/ticket/12603?replyto=8#comment:7 and some later comments, but I'd like to move here the discussion of the specific feature request that should at any given point be equivalent to either INLINE or NOINLINE. Three different results are very unwieldy while optimizing code, because one cannot tweak the INLINE pragma for functions in isolation, via fixing INLINE or NOINLINE for all other functions and varying only one, because the optimal setting for some functions may be , and it naturally varies (as it should; that is fine; but in each particular codebase/compilation flags state it should be equal to either of INLINE or NOINLINE). It seems almost as if GHC considers a function for inlining in some stages, optimizes accordingly, but changes its mind in other places, not being bound by either INLINE nor NOINLINE, and so the resulting stack of optimizations is different than in either case. IMHO that's too complex behaviour for the programmer to follow, it should irreversibly decide whether to inline at exactly the same place it first takes into account the NO/INLINE pragmas, if present. [Edit: another example is the code in description of ticket https://ghc.haskell.org/trac/ghc/ticket/12603, where INLINE, NOINLINE and each produce different "MUT time" in the place marked with "and NOINLINE lands in between".] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:27:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:27:45 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.d6b41a2ccacaa62eb180e48e1c3f080d@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * priority: normal => high @@ -10,1 +10,1 @@ - Edit: here is a minimal example: + Edit, by Mikolaj: here is a minimal example: New description: Mikolaj reported that he was seeing significantly different code generated in the case of an `INLINE` pragma versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb001020870b2d/Game/LambdaHack/Common/Color.hs#L99. Edit, by Mikolaj: here is a minimal example: {{{ -- ghc --make Main.hs -O1; ./Main +RTS -s -RTS seqFrame2 :: [Int] -> IO () {-# NOINLINE seqFrame2 #-} seqFrame2 l = do let crux = attrFromInt -- Total time 2.052s ( 2.072s elapsed) -- but the following version is many times slower: -- let crux = attrFromIntINLINE -- Total time 7.896s ( 7.929s elapsed) mapM_ (\a -> crux a `seq` return ()) l main :: IO () main = seqFrame2 $ replicate 100000000 0 data Attr = Attr !Int --- the bang is essential attrFromInt :: Int -> Attr {-# NOINLINE attrFromInt #-} attrFromInt w = Attr (w + (2 ^ (8 :: Int))) fgFromInt :: Int -> Int {-# INLINE fgFromInt #-} -- removing this INLINE makes it many times faster -- just like the manually inlined version -- and NOINLINE lands in between fgFromInt w = w + (2 ^ (8 :: Int)) attrFromIntINLINE :: Int -> Attr {-# NOINLINE attrFromIntINLINE #-} attrFromIntINLINE w = Attr (fgFromInt w) }}} -- Comment: IMHO, inlining forced with INLINE is just broken in GHC 8.0.1 --- it omits some optimizations that ghc normally does when performing the inlining without pragmas (may be related to the fact that .hi files function code with INLINE is not optimized, as opposed INLINABLE or without pragmas). So I'm bumping the priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 16:39:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 16:39:21 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.ea0c0d135a1f43fb15a204b3f260195c@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 18:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 18:45:33 -0000 Subject: [GHC] #12782: Type inference shows (Num (a -> a), Num a) Message-ID: <049.a84bcd7f189aaadcb5dd4d03b729c93b@haskell.org> #12782: Type inference shows (Num (a -> a), Num a) -------------------------------------+------------------------------------- Reporter: ciupakabra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Defining f and g as: > f x = x + 1 > g x y = x + y Entering :t f . g gives: f . g :: (Num (a -> a), Num a) => a -> a -> a Formally, it is correct, since Num (a -> a) is never going to be a number. Though me and my tutor thought it might be a bug, and f . g shouldn't be recognised as a well-formed expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 18:58:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 18:58:47 -0000 Subject: [GHC] #12782: Type inference shows (Num (a -> a), Num a) In-Reply-To: <049.a84bcd7f189aaadcb5dd4d03b729c93b@haskell.org> References: <049.a84bcd7f189aaadcb5dd4d03b729c93b@haskell.org> Message-ID: <064.b125065854e98930dfb0755eeb63df09@haskell.org> #12782: Type inference shows (Num (a -> a), Num a) -------------------------------------+------------------------------------- Reporter: ciupakabra | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: > Num (a -> a) is never going to be a number. It could be. Someone just has to give an `instance Num (a -> b)`. The compiler cannot assume that no such instance will ever be around. It seems to me that the compiler behaviour is ok and desired as is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 21:09:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 21:09:34 -0000 Subject: [GHC] #12773: Data.Functor.Classes instances for ZipList In-Reply-To: <051.45ef1ecec509b2c0184a30a9bc246f2a@haskell.org> References: <051.45ef1ecec509b2c0184a30a9bc246f2a@haskell.org> Message-ID: <066.e009cf8820f76c054bdf967bc46da010@haskell.org> #12773: Data.Functor.Classes instances for ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 8.0.1 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 RyanGlScott): I'll repeat what I stated [https://ghc.haskell.org/trac/ghc/ticket/11135#comment:25 here]: if you really want these instances now, we'd be happy to take a patch that adds them. I avoided any new `Eq1`/`Ord1`/`Read1`/`Show1`/`Eq2`/`Ord2`/`Read2`/`Show2` instances (other than the ones brought over from `transformers`) since I lacked a mechanism to derive all of these classes, which would have made implementing a lot of these instances tiresome. See also #12457, which aims to find a way to integrate `deriving` into the larger metaprogramming picture. If we had this, we wouldn't have to bake the deriving algorithms for eight more typeclasses into GHC, which would make adding all of these instances far less painful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 21:17:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 21:17:12 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.723422827d6259322c16ab5854b2bb09@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 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 RyanGlScott): > Is this something that belongs to core libraries I don't know. Which "core libraries" are you referring to? `base`, presumably? If so, this proposal should probably be advertised through the [https://mail.haskell.org/mailman/listinfo/libraries libraries mailing list] to gain a wider audience. But I can offer my two cents here: I really don't think this something that `base` urgently needs. For one thing, this is pretty non-standard Haskell in the sense that (1) it requires a GHC extension to use, and (2) it relies on a peculiarity of the GHC parser in order to even be //parsed// correctly (i.e., the definition of `(~>)` won't even parse prior to GHC 7.6). Portability issues aside, you mentioned the other issue looming over this proposal—its usefulness. It certainly straddles the Fairbairn threshold quite closely, and moreover, I'm unconvinced that adding this to `base` will be of much use at all considering the ease with which you can redefine `(~>)` in your own projects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 21:59:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 21:59:04 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.91b341daeacc5e8fdd922b6f7e0b8b67@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify 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 goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 22:04:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 22:04:59 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.a0bb464426ad68315191920d56dc6558@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify 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 goldfire): Calling `simplifyTop` multiple times should be OK, as long as it's passed different constraints each time. Actually seems reasonable here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 22:06:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 22:06:22 -0000 Subject: [GHC] #12778: Expose variables bound in quotations to reify In-Reply-To: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> References: <056.ae7347f3834b6f538314d4417b60f405@haskell.org> Message-ID: <071.a19f385c93119f7f185ae10526ced393@haskell.org> #12778: Expose variables bound in quotations to reify -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify 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 goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 29 22:28:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 29 Oct 2016 22:28:49 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.cc09454d2a47842fb4c01e26edd194e1@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Can't you just delete the `C m =>` constraint on `foo`? Is this reduced from a real program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 04:27:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 04:27:39 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.1024a50c8b8db5a6c502fb4a996219b3@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): The Debian package for GHC 8.0 now carries two patches: {{{ --- a/compiler/main/DynFlags.hs +++ b/compiler/main/DynFlags.hs @@ -3631,14 +3631,8 @@ default_PIC :: Platform -> [GeneralFlag] default_PIC platform = case (platformOS platform, platformArch platform) of - (OSDarwin, ArchX86_64) -> [Opt_PIC] - (OSOpenBSD, ArchX86_64) -> [Opt_PIC] -- Due to PIE support in - -- OpenBSD since 5.3 release - -- (1 May 2013) we need to - -- always generate PIC. See - -- #10597 for more - -- information. - _ -> [] + (OSLinux, ArchPPC) -> [] + _ -> [Opt_PIC] -- General flags that are switched on/off when other general flags are switched -- on }}} and {{{ Description: Pass -no-pie along with -Wl,-r GHC uncoditionally passes `-Wl,-r' to gcc in `compiler/main/DriverPipeline.hs'. This fails in cases where PIE is enabled by default with the following error: . /usr/bin/ld: -r and -pie may not be used together . Fix the above error by passing `-no-pie' along with `-Wl,-r' to the compiler. Author: Ilias Tsitsimpis Bug: https://ghc.haskell.org/trac/ghc/ticket/11834 Bug-Debian: https://bugs.debian.org/712228 Forwarded: no Index: b/compiler/main/DriverPipeline.hs =================================================================== --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -2145,7 +2145,8 @@ joinObjectFiles dflags o_files output_fn osInfo = platformOS (targetPlatform dflags) ld_r args cc = SysTools.runLink dflags ([ SysTools.Option "-nostdlib", - SysTools.Option "-Wl,-r" + SysTools.Option "-Wl,-r", + SysTools.Option "-no-pie" ] ++ (if any (cc ==) [Clang, AppleClang, AppleClang51] then [] }}} Obviously these patches, in their current state, are not suitable for inclusion in GHC. It looks like the use of PIC and PIE needs to be detected at configure/compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 04:59:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 04:59:09 -0000 Subject: [GHC] #12783: RecordWildCards trigger "Impossible happened" in Lucius Message-ID: <050.c9c7f287c44173b9ed94f48c18e19f4f@haskell.org> #12783: RecordWildCards trigger "Impossible happened" in Lucius -------------------------------------+------------------------------------- Reporter: Koterpillar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The presence of `RecordWildCards` in the following code makes GHC crash with "impossible happened". {{{#!hs #!/usr/bin/env stack -- stack --resolver lts-7.5 runghc --package shakespeare {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE RecordWildCards #-} import Text.Lucius renderPrintStylesheet = [lucius|p{}|] main :: IO () main = return () }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Removing `RecordWildCards` makes the program compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 09:03:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 09:03:47 -0000 Subject: [GHC] #12783: RecordWildCards trigger "Impossible happened" in Lucius In-Reply-To: <050.c9c7f287c44173b9ed94f48c18e19f4f@haskell.org> References: <050.c9c7f287c44173b9ed94f48c18e19f4f@haskell.org> Message-ID: <065.83eecb773b81d07eb991937d43b3c130@haskell.org> #12783: RecordWildCards trigger "Impossible happened" in Lucius -------------------------------------+------------------------------------- Reporter: Koterpillar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | 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 mpickering): * status: new => closed * resolution: => duplicate Comment: Seems like #12130 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 13:40:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 13:40:46 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.24ee9eae16e3ce6f9eaef01a89a6c055@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2659 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D2659 * component: Template Haskell => Compiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 15:07:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 15:07:12 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.c30e9b038ee24468baaae5ea4d3c04cf@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jophish): Yes, as 8.1 suggests, this constraint is redundant. I encountered this in the trifecta library. It can be seen in the `rend` and `restOfLine` member functions of the `DeltaParsing` class here https://hackage.haskell.org/package/trifecta-1.6/docs/src/Text.Trifecta.Combinators.html#DeltaParsing (this is fixed in trifecta's HEAD now). I imagine that this can happen when a top level constrained function is moved to be a member of a class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 15:15:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 15:15:22 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.9c02cc6e855a68d16d960d5e93657bac@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 15:40:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 15:40:27 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.9df310303829886ac1093306af82d724@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2659 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell Comment: The "Template Haskell" component applies to all bugs/fixes that are primarily about TH, even if the code changed is in GHC proper. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 17:54:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 17:54:04 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures Message-ID: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code compiles without issue on GHC 8.0.1 and earlier, but not with GHC 8.0.2 or HEAD. This was adapted from the [https://github.com/kazu- yamamoto/logger/blob/master/monad-logger/Control/Monad/Logger.hs monad- logger] library (which fails to build with GHC 8.0.2 and HEAD due to the same issue): {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE GADTs #-} module MonadLogger where import Control.Monad.IO.Class import qualified Control.Monad.Trans.Class as Trans import Control.Monad.Trans.Identity data Loc data LogSource data LogLevel data LogStr class ToLogStr msg class Monad m => MonadLogger m class (MonadLogger m, MonadIO m) => MonadLoggerIO m where askLoggerIO :: m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) default askLoggerIO :: (Trans.MonadTrans t, MonadLogger (t m), MonadIO (t m)) => t m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) askLoggerIO = Trans.lift askLoggerIO instance MonadLogger m => MonadLogger (IdentityT m) instance MonadLoggerIO m => MonadLoggerIO (IdentityT m) }}} On GHC HEAD, this fails with: {{{ [1 of 1] Compiling MonadLogger ( MonadLogger.hs, interpreted ) MonadLogger.hs:23:10: error: • Couldn't match type ‘m’ with ‘IdentityT m’ ‘m’ is a rigid type variable bound by the instance declaration at MonadLogger.hs:23:10-55 Expected type: IdentityT m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) Actual type: IdentityT (IdentityT m) (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) • In the expression: MonadLogger.$dmaskLoggerIO @IdentityT m In an equation for ‘askLoggerIO’: askLoggerIO = MonadLogger.$dmaskLoggerIO @IdentityT m In the instance declaration for ‘MonadLoggerIO (IdentityT m)’ • Relevant bindings include askLoggerIO :: IdentityT m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) (bound at MonadLogger.hs:23:10) }}} This stopped typechecking after d2958bd08a049b61941f078e51809c7e63bc3354 (i.e, #12220). As a workaround, you can change the default signature to: {{{#!hs default askLoggerIO :: (Trans.MonadTrans t, MonadLoggerIO n, t n ~ m) => t n (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) }}} And it'll work. Any thoughts on this, Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 18:00:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 18:00:52 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.8542e869210097482872656abcd8bd70@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This also introduced another typechecker regression in GHC 8.0.2: #12784. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 18:21:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 18:21:52 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint Message-ID: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached module I get {{{ $ ghc --interactive Tree.hs GHCi, version 8.1.20161030: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( Tree.hs, interpreted ) Tree.hs:28:63: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161030 for x86_64-apple-darwin): tcTyVarDetails cobox0_a1eK :: (m_a1ej[sk:2] :: Peano) ~# ('S n_a1eJ[ssk:3] :: Peano) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:457:22 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When switching the call to `SBranchX` in line 29 to a call to `SBranch` the program compiles. So I suspect that the problem is rooted in the extra constraint attached to constructor `SBranchX`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 18:22:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 18:22:08 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.5d35304a1130613d44564c77cb46e25a@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 heisenbug): * Attachment "Tree.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 18:27:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 18:27:31 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.7b3e81bc563feb982b1b54525ee398b7@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 heisenbug): Seems to be related to #12590, but it is not obvious how they are similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 18:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 18:43:58 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.443074e45a28ddb9bf3d0d7b65bb10f1@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 heisenbug): Hmmm, looks like a case is not implemented. in `tcTyVarDetails` this constructor should be checked: {{{#!haskell Id { varName :: !Name, realUnique :: {-# UNPACK #-} !Int, varType :: Type, idScope :: IdScope, id_details :: IdDetails, -- Stable, doesn't change id_info :: IdInfo } -- Unstable, updated by simplifier }}} '''Note:''' `setTcTyVarDetails` also looks like it is not total. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 19:48:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 19:48:30 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.536cc1f6a16e742c83e1f2538755a6ac@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) * milestone: => 8.0.2 Comment: Simon, the code above stopped typechecking after one of your commits: 96d451450923a80b043b5314c5eaaa9d0eab7c56. Is this expected behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 20:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 20:31:02 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.6918e7fdd23277621e0e50b1df46ce40@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12771 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * testcase: => T12771 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 21:30:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 21:30:13 -0000 Subject: [GHC] #12786: genericReplicateM and genericReplicateM_ Message-ID: <043.ee983564a6d0b7f3921260b9aa87df25@haskell.org> #12786: genericReplicateM and genericReplicateM_ -------------------------------------+------------------------------------- Reporter: uznx | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add genericReplicateM and genericReplicateM_ to core libraries, probably Control.Monad, generalizing replicateM and replicateM_ to any Integral type, similar to all the other generic* functions. This was proposed and supported with no objections on the libraries mailing list: https://mail.haskell.org/pipermail/libraries/2015-July/026016.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 21:37:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 21:37:34 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.dcac7e997ea84505eea05bd1ab17a55e@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 heisenbug): * Attachment "Var.hs.diff" added. This fixes the panic for me -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 30 21:42:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 30 Oct 2016 21:42:46 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.6757e9b4090cdadd9bba150d85c851fc@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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 heisenbug): With the attached patch I get: {{{ $ ghci Tree.hs GHCi, version 8.1.20161030: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Tree ( Tree.hs, interpreted ) Tree.hs:29:63: error: • Could not deduce: Payload ('S n1) (Payload n1 s1) ~ s arising from a use of ‘SBranchX’ from the context: m1 ~ 'S n1 bound by a pattern with constructor: Branch :: forall a (n :: Peano). a -> HTree n (HTree ('S n) a) -> HTree ('S n) a, in an equation for ‘nest’ at Tree.hs:29:7-51 • In the second argument of ‘($)’, namely ‘a `SBranchX` tr’ In the expression: Hide $ a `SBranchX` tr In an equation for ‘nest’: nest (Hide a `Branch` (nest . hmap nest -> Hide tr)) = Hide $ a `SBranchX` tr • Relevant bindings include tr :: STree n1 (STree ('S n1) (STree ('S ('S n1)) f)) s1 (bound at Tree.hs:29:49) a :: STree ('S m1) f s (bound at Tree.hs:29:12) nest :: HTree m1 (Hidden ('S m1) f) -> Hidden m1 (STree ('S m1) f) (bound at Tree.hs:27:1) Failed, modules loaded: none. }}} Please review... (and consider the note above) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 07:49:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 07:49:43 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances Message-ID: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Linux UndecidableInstances | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimal example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module Test where class PreOrd a where (<~) :: a -> a -> Bool class PreOrd a => PartialOrd a where tryCompare :: a -> a -> Maybe Ordering instance PartialOrd a => PreOrd a where x <~ y = let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ class PartialOrd a => TotalOrd a where tcompare :: a -> a -> Ordering instance TotalOrd a => PartialOrd a where tryCompare x y = Just $ tcompare x y instance TotalOrd Int where tcompare x y = compare x y }}} GHC (tested with 7.10.3 and 8.0.1) rejects this with the following error: {{{ test.hs:11:24: error: • Could not deduce (TotalOrd a) arising from a use of ‘tryCompare’ from the context: PartialOrd a bound by the instance declaration at test.hs:10:10-33 Possible fix: add (TotalOrd a) to the context of the instance declaration • In the expression: tryCompare x y In an equation for ‘cmp’: cmp = tryCompare x y In the expression: let cmp = tryCompare x y in cmp == Just LT || cmp == Just EQ }}} After banging my head against this for a while, and having successfully run this in Hugs, I tend to see it as a bug in GHC. Which is to say, I have no idea why tryCompare could possibly require TotalOrd when it's actually defined in its superclass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 09:38:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 09:38:53 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.fb9dde10affecfc30f6c065f6ca000f1@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 12:33:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 12:33:15 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances In-Reply-To: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> References: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> Message-ID: <058.107bca2d57a6e34b760fc43df6b302aa@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | UndecidableInstances Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This looks like correct behavior to me. There is one, universal instance of `PartialOrd`. As soon as GHC needs the `PartialOrd` constraint to accept the use of `tryCompare`, it will find this instance. But the instance context requires an instance for `TotalOrd`, which does not exist. How would you expect this to be accepted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 14:13:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 14:13:22 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" Message-ID: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got the following error compiling simple source file Bad.hs. The bug is likely related to TH as the crash vanishes without the TH line. $ stack ghc -- -c Bad.hs Run from outside a project, using implicit global project config Using resolver: lts-7.5 from implicit global project's config file: /home/jchia/.stack/global-project/stack.yaml ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): compiler/typecheck/TcExpr.hs:798:15-35: Irrefutable pattern failed for pattern sel_id : _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 14:13:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 14:13:40 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.21a1daa7cea883b830d3e66fcc61972d@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 jchia): * Attachment "Bad.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 14:23:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 14:23:53 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.9fe60b51ce9fe86c6caa102cbf64f220@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 jchia): I can reproduce the error under Stack LTS-7.5, so this is with aeson-0.11.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 16:38:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 16:38:01 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. Message-ID: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ----------------------------------------+--------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I encountered the "Simplifier ticks exhausted" error when compiling some code generated by hprotoc in GHC 8.0.1. It works with -O0, but fails with -O1. The code compiles successfully with GHC 7.10, but fails with 8.0.1. Specifying a larger value for 'simpl-tick-factor' doesn't seem to help. The original code was generated by hprotoc, but a much simplified version is attached. Here is the output with '-ddump-simpl-stats' enabled: {{{ stack build cycle-test --ghc-options -ddump-simpl-stats cycle-test-0.1.0.0: configure Configuring cycle-test-0.1.0.0... cycle-test-0.1.0.0: build Preprocessing library cycle-test-0.1.0.0... [1 of 4] Compiling Thing2[boot] ( src/Thing2.hs-boot, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing2.o-boot ) [2 of 4] Compiling Thing1 ( src/Thing1.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing1.o ) [3 of 4] Compiling Thing2 ( src/Thing2.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Thing2.o ) [4 of 4] Compiling Box ( src/Box.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.0.0/build/Box.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $fxEqThing2 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 6442 1681 PreInlineUnconditionally 280 $dEq_a1AB 280 ds_a1AC 280 ds_i28z 280 ds1_i28A 279 ds_i29a 279 ds1_i29b 1 ds_a1As 1 ds_d28r 1 ds_d28s 280 PostInlineUnconditionally 280 ds1_a1AD 1120 UnfoldingDone 280 $fEqMaybe_$c== 280 $fEqThing1_$c== 279 $fxEqThing2 279 $fEqThing2_$c== 1 $c==_a289 1 not 279 RuleFired 279 Class op == 2241 BetaReduction 280 a_a1AA 280 $dEq_a1AB 280 ds_a1AC 280 ds1_a1AD 280 ds_i28z 280 ds1_i28A 279 ds_i29a 279 ds1_i29b 1 ds_a1As 1 ds_d28r 1 ds_d28s 1 CaseOfCase 1 wild_a1At 840 KnownBranch 840 wild_a1At }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 16:38:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 16:38:28 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.9baaeaa1c414d02d6bf789969f9e86ef@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by rdwebster): * Attachment "cycle-test-src.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:46:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:46:56 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins Message-ID: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building lambdabot-haskell-plugins, Lambdabot.Plugin.Haskell.Pl.Parser compiles without incident on the non- profiling run, but cripples the build machine on the profiling run. An excerpt of -v3 output is below to show the number of terms skyrocketing. *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Common sub-expression = {terms: 39,049, types: 30,851, coercions: 990} !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 72.00 milliseconds, allocated 44.536 megabytes *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Float inwards = {terms: 39,049, types: 30,851, coercions: 990} !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 milliseconds, allocated 60.337 megabytes *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Simplifier iteration=1 = {terms: 977,045, types: 299,334, coercions: 1,058} Result size of Simplifier iteration=2 = {terms: 926,036, types: 263,306, coercions: 932} Result size of Simplifier = {terms: 922,724, types: 262,202, coercions: 932} !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 milliseconds, allocated 9384.823 megabytes *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Tidy Core = {terms: 922,623, types: 261,789, coercions: 865} !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 milliseconds, allocated 613.585 megabytes writeBinIface: 95 Names writeBinIface: 259 dict entries *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of CorePrep = {terms: 1,128,145, types: 347,063, coercions: 865} !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 milliseconds, allocated 1718.453 megabytes *** Stg2Stg: *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:48:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:48:16 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.21d1c1bf4e1a964a6dfaa63423cdda24@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by clint: @@ -7,23 +7,24 @@ - *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: - Result size of Common sub-expression - = {terms: 39,049, types: 30,851, coercions: 990} - !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: - finished in 72.00 milliseconds, allocated 44.536 megabytes - *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: - Result size of Float inwards - = {terms: 39,049, types: 30,851, coercions: 990} - !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in - 68.00 milliseconds, allocated 60.337 megabytes - *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: - Result size of Simplifier iteration=1 - = {terms: 977,045, types: 299,334, coercions: 1,058} - Result size of Simplifier iteration=2 - = {terms: 926,036, types: 263,306, coercions: 932} - Result size of Simplifier - = {terms: 922,724, types: 262,202, coercions: 932} - !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in - 15480.00 milliseconds, allocated 9384.823 megabytes - *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: - Result size of Tidy Core - = {terms: 922,623, types: 261,789, coercions: 865} - !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 + {{{ + *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: + Result size of Common sub-expression + = {terms: 39,049, types: 30,851, coercions: 990} + !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished + in 72.00 milliseconds, allocated 44.536 megabytes + *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: + Result size of Float inwards + = {terms: 39,049, types: 30,851, coercions: 990} + !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 + milliseconds, allocated 60.337 megabytes + *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: + Result size of Simplifier iteration=1 + = {terms: 977,045, types: 299,334, coercions: 1,058} + Result size of Simplifier iteration=2 + = {terms: 926,036, types: 263,306, coercions: 932} + Result size of Simplifier + = {terms: 922,724, types: 262,202, coercions: 932} + !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 + milliseconds, allocated 9384.823 megabytes + *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: + Result size of Tidy Core + = {terms: 922,623, types: 261,789, coercions: 865} + !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 @@ -31,6 +32,6 @@ - writeBinIface: 95 Names - writeBinIface: 259 dict entries - *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: - Result size of CorePrep - = {terms: 1,128,145, types: 347,063, coercions: 865} - !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 + writeBinIface: 95 Names + writeBinIface: 259 dict entries + *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: + Result size of CorePrep + = {terms: 1,128,145, types: 347,063, coercions: 865} + !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 @@ -38,2 +39,3 @@ - *** Stg2Stg: - *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: + *** Stg2Stg: + *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: + }}} New description: When building lambdabot-haskell-plugins, Lambdabot.Plugin.Haskell.Pl.Parser compiles without incident on the non- profiling run, but cripples the build machine on the profiling run. An excerpt of -v3 output is below to show the number of terms skyrocketing. {{{ *** Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Common sub-expression = {terms: 39,049, types: 30,851, coercions: 990} !!! Common sub-expression [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 72.00 milliseconds, allocated 44.536 megabytes *** Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Float inwards = {terms: 39,049, types: 30,851, coercions: 990} !!! Float inwards [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 68.00 milliseconds, allocated 60.337 megabytes *** Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Simplifier iteration=1 = {terms: 977,045, types: 299,334, coercions: 1,058} Result size of Simplifier iteration=2 = {terms: 926,036, types: 263,306, coercions: 932} Result size of Simplifier = {terms: 922,724, types: 262,202, coercions: 932} !!! Simplifier [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 15480.00 milliseconds, allocated 9384.823 megabytes *** CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of Tidy Core = {terms: 922,623, types: 261,789, coercions: 865} !!! CoreTidy [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 2060.00 milliseconds, allocated 613.585 megabytes writeBinIface: 95 Names writeBinIface: 259 dict entries *** CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: Result size of CorePrep = {terms: 1,128,145, types: 347,063, coercions: 865} !!! CorePrep [Lambdabot.Plugin.Haskell.Pl.Parser]: finished in 3468.00 milliseconds, allocated 1718.453 megabytes *** Stg2Stg: *** CodeGen [Lambdabot.Plugin.Haskell.Pl.Parser]: }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:49:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:49:54 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances In-Reply-To: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> References: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> Message-ID: <058.b5c128f481c411ec97122ca3f14761c3@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | UndecidableInstances Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nome): Maybe I've minimized the example a bit too much. The `PartialOrd` instance given is not meant to be universal, but as a default. In a slightly more realistic example, it would be made overlappable, like so: {{{#!hs instance {-# OVERLAPPABLE #-} TotalOrd a => PartialOrd a where tryCompare x y = Just $ tcompare x y }}} And there would be additional instances, e.g. {{{#!hs import Data.List -- insert classes and instances as above instance Eq a => PartialOrd [a] where tryCompare xs ys = if xs == ys then Just EQ else if null (xs \\ ys) then Just LT else if null (ys \\ xs) then Just GT else Nothing }}} If I understand [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #instance-overlap overlapping instances] correctly, GHC should consider ''all'' applicable instances and be "conservative about committing to an overlapping instance", so I would expect it to refrain from committing to the `TotalOrd a => PartialOrd a` one. Still, even with these additions, I get the same error. Ideally, the default implementation would be part of the `PartialOrd` class (like default implementations of the class's own methods); but it seems that there's no way to provide default implementations for superclass methods in a class declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:53:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:53:25 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. Message-ID: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use the specific dictionary. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:54:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:54:39 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.79ccb0d3404098d8c4de2dc5c5c5ec62@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by mpickering: @@ -2,2 +2,3 @@ - If this type variable is fixed then we know that we are going to use the - specific dictionary. Thus, the optimiser *could* specialise all methods + If this type variable is fixed then we know that we are going to use a + specific instance for `R`. Thus, the optimiser *could* specialise all + methods New description: Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use a specific instance for `R`. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 20:55:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 20:55:44 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.af6a9a550890f40224ab905eadc76616@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 mpickering): * Attachment "newfoo.dump-simpl" added. Core Dump -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:03:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:03:35 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.0772d3a471ad15c94d06000586f32179@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12771 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"795be0ea60fc81aefdaf6ecb1dc9b03c4a5c9f86/ghc" 795be0e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="795be0ea60fc81aefdaf6ecb1dc9b03c4a5c9f86" Align GHCi's library search order more closely with LDs Summary: Given a static library and an import library in the same folder. e.g. ``` libfoo.a libfoo.dll.a ``` running `ghci -lfoo` we should prefer the import library `libfoo.dll.a` over `libfoo.a` because we prefer having to just load the DLL. And not having to do any linking. This also more closely emulated the behaviour of LD, which has a search order of ``` libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll ``` Test Plan: ./validate Reviewers: RyanGlScott, austin, hvr, bgamari, erikd, simonmar Reviewed By: RyanGlScott Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2651 GHC Trac Issues: #12771 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:07:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:07:35 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.8056b12f5ebf2f5225c4937a9e3d640d@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12771 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => merge * milestone: 8.2.1 => 8.0.2 Comment: Small patch that re-orders import lib searching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:18:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:18:21 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.6c4f5cbcd32a59314a29c6fc5139f5a3@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I wasn't able to reproduce this with a `cabal install -w ghc-8.0.1 lambdabot-haskell-plugins`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:18:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:18:44 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head Message-ID: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Prelude> data List a = Nil | Cons a (List a) Prelude> instance List a :3:10: error: • Expected a constraint, but ‘List a’ has kind ‘*’ • In the instance declaration for ‘List a’ Prelude> instance List a where foo = foo :2:23: error: ‘foo’ is not a (visible) method of class ‘List’ }}} Clearly, the constraint check should happen before we look at the method names. Happens with 7.10 and 8.0.1 and HEAD. Shouldn’t be hard, marking at newcomer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:21:17 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.c0006edc509005c980589987659f7ee3@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:2 rwbarton]: > I wasn't able to reproduce this with a `cabal install -w ghc-8.0.1 lambdabot-haskell-plugins`. Have you tried `cabal install -w ghc-8.0.1 lambdabot-haskell-plugins --enable-library-profiling`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 21:32:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 21:32:31 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.5e03924c51832885710217ecb06c76f8@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oops, I misread a comment in IRC :/ It's sufficient to just try to build the module `Lambdabot.Plugin.Haskell.Pl.Parser` along with its dependency `Lambdabot.Plugin.Haskell.Pl.Common` (with `-O -prof`). Only package dependencies are mtl, text and parsec. GHC 7.10.1 works okay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 22:14:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 22:14:21 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances In-Reply-To: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> References: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> Message-ID: <058.e53562f4ab3875ea3edd2255a123de77@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | UndecidableInstances Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nome): * status: new => closed * resolution: => invalid Comment: After some more head banging and scratching, I'm heading towards the conclusion that I simply can't use the context of an instance declaration to put a restriction on the types it applies to. It looks like it should be possible in principle, but if that's not how the language works, there's little point in arguing. Unlike the minimal example, the extended one given above doesn't work in Hugs either. I'm still not entirely sure about all of this stuff, particularly the overlapping instances bit, but it appears that the bug was really in my interpretation. Sorry for the noise... I've never met a language that's both so beautiful and so liable to tying knots into my brain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 22:52:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 22:52:41 -0000 Subject: [GHC] #11834: GHC master, not compiling on Archlinux In-Reply-To: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> References: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> Message-ID: <060.1cc5caf7bcc76fa1f825831c673bcc48@haskell.org> #11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This seems to affect users on Debian unstable (e.g. me) now as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 31 23:56:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 31 Oct 2016 23:56:44 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.c7202ac3777d656d6535fd5ddf531ab6@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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 Darwin226): I'm facing the same issue on Windows with both GHC 7.10.3 and GHC 8.0.1. In my case it's the curl library. I've provided a way to reproduce this in this ticket https://github.com/commercialhaskell/stack/issues/2752 The error I'm getting is the following {{{ ghc.EXE: unable to load package `curl-1.3.8' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `stricmp' ghc.EXE: Could not on-demand load symbol 'curl_strequal' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_strequal' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cstrdup' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cstrdup' ghc.EXE: Could not on-demand load symbol 'curl_slist_free_all' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_slist_free_all' ghc.EXE: Could not on-demand load symbol 'Curl_ssl_connect_nonblocking' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_ssl_connect_nonblocking' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_crealloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_crealloc' ghc.EXE: Could not on-demand load symbol 'curl_msnprintf' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_msnprintf' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cmalloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cmalloc' ghc.EXE: Could not on-demand load symbol 'Curl_verify_windows_version' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_verify_windows_version' ghc.EXE: Could not on-demand load symbol 'Curl_sspi_global_init' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_sspi_global_init' ghc.EXE: Could not on-demand load symbol 'curl_global_init' ghc.EXE: C:\sr\snapshots\df48cbae\lib\x86_64-windows- ghc-8.0.1\curl-1.3.8-B8AxMCtSRkiFrZLK4gerBe\HScurl-1.3.8-B8AxMCtSRkiFrZLK4gerBe.o: unknown symbol `curl_global_init' }}} This is the GHC 8 error. The 7.10.3 is different and shorter but in the same gist. I've seen the `ghc --info` mentioned above and I indeed get `("GHC Dynamic","NO")`. I installed both versions of GHC through stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 3 20:05:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 03 Oct 2016 20:05:53 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.0a81902ef06ae96f5049ab813196b527@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): {{{ 2444: created capset 0 of type 2 2444: created capset 1 of type 3 2444: cap 0: initialised 2444: assigned cap 0 to capset 0 2444: assigned cap 0 to capset 1 2444: cap 1: initialised 2444: assigned cap 1 to capset 0 2444: assigned cap 1 to capset 1 2444: cap 2: initialised 2444: assigned cap 2 to capset 0 2444: assigned cap 2 to capset 1 2444: cap 3: initialised 2444: assigned cap 3 to capset 0 2444: assigned cap 3 to capset 1 2444: cap 4: initialised 2444: assigned cap 4 to capset 0 2444: assigned cap 4 to capset 1 2444: cap 5: initialised 2444: assigned cap 5 to capset 0 2444: assigned cap 5 to capset 1 2444: cap 6: initialised 2444: assigned cap 6 to capset 0 2444: assigned cap 6 to capset 1 2444: cap 7: initialised 2444: assigned cap 7 to capset 0 2444: assigned cap 7 to capset 1 2444: cap 8: initialised 2444: assigned cap 8 to capset 0 2444: assigned cap 8 to capset 1 2444: cap 9: initialised 2444: assigned cap 9 to capset 0 2444: assigned cap 9 to capset 1 2444: cap 10: initialised 2444: assigned cap 10 to capset 0 2444: assigned cap 10 to capset 1 2444: cap 11: initialised 2444: assigned cap 11 to capset 0 2444: assigned cap 11 to capset 1 2444: cap 12: initialised 2444: assigned cap 12 to capset 0 2444: assigned cap 12 to capset 1 2444: cap 13: initialised 2444: assigned cap 13 to capset 0 2444: assigned cap 13 to capset 1 2444: cap 14: initialised 2444: assigned cap 14 to capset 0 2444: assigned cap 14 to capset 1 2444: cap 15: initialised 2444: assigned cap 15 to capset 0 2444: assigned cap 15 to capset 1 2444: cap 16: initialised 2444: assigned cap 16 to capset 0 2444: assigned cap 16 to capset 1 2444: cap 17: initialised 2444: assigned cap 17 to capset 0 2444: assigned cap 17 to capset 1 2444: cap 18: initialised 2444: assigned cap 18 to capset 0 2444: assigned cap 18 to capset 1 2444: cap 19: initialised 2444: assigned cap 19 to capset 0 2444: assigned cap 19 to capset 1 2444: cap 20: initialised 2444: assigned cap 20 to capset 0 2444: assigned cap 20 to capset 1 2444: cap 21: initialised 2444: assigned cap 21 to capset 0 2444: assigned cap 21 to capset 1 2444: cap 22: initialised 2444: assigned cap 22 to capset 0 2444: assigned cap 22 to capset 1 2444: cap 23: initialised 2444: assigned cap 23 to capset 0 2444: assigned cap 23 to capset 1 2444: cap 24: initialised 2444: assigned cap 24 to capset 0 2444: assigned cap 24 to capset 1 2444: cap 25: initialised 2444: assigned cap 25 to capset 0 2444: assigned cap 25 to capset 1 2444: cap 26: initialised 2444: assigned cap 26 to capset 0 2444: assigned cap 26 to capset 1 2444: cap 27: initialised 2444: assigned cap 27 to capset 0 2444: assigned cap 27 to capset 1 2444: cap 28: initialised 2444: assigned cap 28 to capset 0 2444: assigned cap 28 to capset 1 2444: cap 29: initialised 2444: assigned cap 29 to capset 0 2444: assigned cap 29 to capset 1 2444: cap 30: initialised 2444: assigned cap 30 to capset 0 2444: assigned cap 30 to capset 1 2444: cap 31: initialised 2444: assigned cap 31 to capset 0 2444: assigned cap 31 to capset 1 2444: cap 32: initialised 2444: assigned cap 32 to capset 0 2444: assigned cap 32 to capset 1 2444: cap 33: initialised 2444: assigned cap 33 to capset 0 2444: assigned cap 33 to capset 1 2444: cap 34: initialised 2444: assigned cap 34 to capset 0 2444: assigned cap 34 to capset 1 2444: cap 35: initialised 2444: assigned cap 35 to capset 0 2444: assigned cap 35 to capset 1 2444: cap 36: initialised 2444: assigned cap 36 to capset 0 2444: assigned cap 36 to capset 1 2444: cap 37: initialised 2444: assigned cap 37 to capset 0 2444: assigned cap 37 to capset 1 2444: cap 38: initialised 2444: assigned cap 38 to capset 0 2444: assigned cap 38 to capset 1 2444: cap 39: initialised 2444: assigned cap 39 to capset 0 2444: assigned cap 39 to capset 1 2444: cap 40: initialised 2444: assigned cap 40 to capset 0 2444: assigned cap 40 to capset 1 2444: cap 41: initialised 2444: assigned cap 41 to capset 0 2444: assigned cap 41 to capset 1 2444: cap 42: initialised 2444: assigned cap 42 to capset 0 2444: assigned cap 42 to capset 1 2444: cap 43: initialised 2444: assigned cap 43 to capset 0 2444: assigned cap 43 to capset 1 2444: cap 44: initialised 2444: assigned cap 44 to capset 0 2444: assigned cap 44 to capset 1 2444: cap 45: initialised 2444: assigned cap 45 to capset 0 2444: assigned cap 45 to capset 1 2444: cap 46: initialised 2444: assigned cap 46 to capset 0 2444: assigned cap 46 to capset 1 2444: cap 47: initialised 2444: assigned cap 47 to capset 0 2444: assigned cap 47 to capset 1 2444: cap 48: initialised 2444: assigned cap 48 to capset 0 2444: assigned cap 48 to capset 1 2444: cap 49: initialised 2444: assigned cap 49 to capset 0 2444: assigned cap 49 to capset 1 2444: cap 50: initialised 2444: assigned cap 50 to capset 0 2444: assigned cap 50 to capset 1 2444: cap 51: initialised 2444: assigned cap 51 to capset 0 2444: assigned cap 51 to capset 1 2444: cap 52: initialised 2444: assigned cap 52 to capset 0 2444: assigned cap 52 to capset 1 2444: cap 53: initialised 2444: assigned cap 53 to capset 0 2444: assigned cap 53 to capset 1 2444: cap 54: initialised 2444: assigned cap 54 to capset 0 2444: assigned cap 54 to capset 1 2444: cap 55: initialised 2444: assigned cap 55 to capset 0 2444: assigned cap 55 to capset 1 2444: cap 56: initialised 2444: assigned cap 56 to capset 0 2444: assigned cap 56 to capset 1 2444: cap 57: initialised 2444: assigned cap 57 to capset 0 2444: assigned cap 57 to capset 1 2444: cap 58: initialised 2444: assigned cap 58 to capset 0 2444: assigned cap 58 to capset 1 2444: cap 59: initialised 2444: assigned cap 59 to capset 0 2444: assigned cap 59 to capset 1 2444: cap 60: initialised 2444: assigned cap 60 to capset 0 2444: assigned cap 60 to capset 1 2444: cap 61: initialised 2444: assigned cap 61 to capset 0 2444: assigned cap 61 to capset 1 2444: cap 62: initialised 2444: assigned cap 62 to capset 0 2444: assigned cap 62 to capset 1 2444: cap 63: initialised 2444: assigned cap 63 to capset 0 2444: assigned cap 63 to capset 1 2444: cap 64: initialised 2444: assigned cap 64 to capset 0 2444: assigned cap 64 to capset 1 2444: cap 65: initialised 2444: assigned cap 65 to capset 0 2444: assigned cap 65 to capset 1 2444: cap 66: initialised 2444: assigned cap 66 to capset 0 2444: assigned cap 66 to capset 1 2444: cap 67: initialised 2444: assigned cap 67 to capset 0 2444: assigned cap 67 to capset 1 2444: cap 68: initialised 2444: assigned cap 68 to capset 0 2444: assigned cap 68 to capset 1 2444: cap 69: initialised 2444: assigned cap 69 to capset 0 2444: assigned cap 69 to capset 1 2444: cap 70: initialised 2444: assigned cap 70 to capset 0 2444: assigned cap 70 to capset 1 2444: cap 71: initialised 2444: assigned cap 71 to capset 0 2444: assigned cap 71 to capset 1 2444: cap 72: initialised 2444: assigned cap 72 to capset 0 2444: assigned cap 72 to capset 1 2444: cap 73: initialised 2444: assigned cap 73 to capset 0 2444: assigned cap 73 to capset 1 2444: cap 74: initialised 2444: assigned cap 74 to capset 0 2444: assigned cap 74 to capset 1 2444: cap 75: initialised 2444: assigned cap 75 to capset 0 2444: assigned cap 75 to capset 1 2444: cap 76: initialised 2444: assigned cap 76 to capset 0 2444: assigned cap 76 to capset 1 2444: cap 77: initialised 2444: assigned cap 77 to capset 0 2444: assigned cap 77 to capset 1 2444: cap 78: initialised 2444: assigned cap 78 to capset 0 2444: assigned cap 78 to capset 1 2444: cap 79: initialised 2444: assigned cap 79 to capset 0 2444: assigned cap 79 to capset 1 2444: cap 80: initialised 2444: assigned cap 80 to capset 0 2444: assigned cap 80 to capset 1 2444: cap 81: initialised 2444: assigned cap 81 to capset 0 2444: assigned cap 81 to capset 1 2444: cap 82: initialised 2444: assigned cap 82 to capset 0 2444: assigned cap 82 to capset 1 2444: cap 83: initialised 2444: assigned cap 83 to capset 0 2444: assigned cap 83 to capset 1 2444: cap 84: initialised 2444: assigned cap 84 to capset 0 2444: assigned cap 84 to capset 1 2444: cap 85: initialised 2444: assigned cap 85 to capset 0 2444: assigned cap 85 to capset 1 2444: cap 86: initialised 2444: assigned cap 86 to capset 0 2444: assigned cap 86 to capset 1 2444: cap 87: initialised 2444: assigned cap 87 to capset 0 2444: assigned cap 87 to capset 1 2444: allocated 88 more capabilities 2444: new worker task (taskCount: 1) 2444: new worker task (taskCount: 2) [*] Number of processor groups detected: 2 [*] Number of active processors in group 0 detected: 44 2444: new worker task (taskCount: 3) [*] Number of active processors in group 0 detected: 44 [*] Number of active processors in group 1 detected: 44 [*] Processor group map created 2444: new worker task (taskCount: 4) [*] Number of active processors in group 2600: 1cap 3: schedule() 1d40: cap 1: schedule() d 1d40: giving up capability 1 e 1d40: freeing capability 1 te 2600: giving up capability 3 2600: freeing capability 3c ted: 44 [*] Cumulative active processors for group 0: 0 [*] Cumulative active processors for group 1: 44 25fc: cap 4: schedule() 25fc: giving up capability 4 25fc: freeing capability 4 2444: new worker task (taskCount: 5) 166c: cap 2: schedule() 166c: giving up capability 2 166c: freeing capability 2 2444: new worker task (taskCount: 6) 25f8: cap 5: schedule() 25f8: giving up capability 5 25f8: freeing capability 5 2444: new worker task (taskCount: 7) 25f0: cap 6: schedule() 25f0: giving up capability 6 25f0: freeing capability 6 2444: new worker task (taskCount: 8) 25f4: cap 7: schedule() 25f4: giving up capability 7 25f4: freeing capability 7 2444: new worker task (taskCount: 9) 2210: cap 8: schedule() 2210: giving up capability 8 2210: freeing capability 8 2444: new worker task (taskCount: 10) 270: cap 9: schedule() 270: giving up capability 9 270: freeing capability 9 2444: new worker task (taskCount: 11) 6c8: cap 10: schedule() 6c8: giving up capability 10 6c8: freeing capability 10 2444: new worker task (taskCount: 12) 17b8: cap 11: schedule() 17b8: giving up capability 11 17b8: freeing capability 11 2444: new worker task (taskCount: 13) 1aa8: cap 12: schedule() 1aa8: giving up capability 12 1aa8: freeing capability 12 2444: new worker task (taskCount: 14) 454: cap 13: schedule() 454: giving up capability 13 454: freeing capability 13 2444: new worker task (taskCount: 15) 2720: cap 14: schedule() 2444: new worker task (taskCount: 16) 15e8: cap 15: schedule() 2720: giving up capability 14 2720: freeing capability 14 85c: cap 16: schedule() 15e8: giving up capability 15 15e8: freeing capability 15 85c: giving up capability 16 85c: freeing capability 16 2444: new worker task (taskCount: 17) 2444: new worker task (taskCount: 18) 9b8: cap 17: schedule() 9b8: giving up capability 17 9b8: freeing capability 17 2444: new worker task (taskCount: 19) 464: cap 18: schedule() 464: giving up capability 18 464: freeing capability 18 2444: new worker task (taskCount: 20) 13a8: cap 19: schedule() 2444: new worker task (taskCount: 21) 1244: cap 20: schedule() 1244: giving up capability 20 1244: freeing capability 20 1510: cap 21: schedule() 1510: giving up capability 21 1510: freeing capability 21 13a8: giving up capability 19 13a8: freeing capability 19 2444: new worker task (taskCount: 22) 2444: new worker task (taskCount: 23) 229c: cap 23: schedule() 229c: giving up capability 23 229c: freeing capability 23 2444: new worker task (taskCount: 24) 1848: cap 22: schedule() 1848: giving up capability 22 1848: freeing capability 22 2444: new worker task (taskCount: 25) 2178: cap 24: schedule() 2444: new worker task (taskCount: 26) 212c: cap 25: schedule() 2178: giving up capability 24 2178: freeing capability 24 1eb4: cap 26: schedule() 1eb4: giving up capability 26 1eb4: freeing capability 26 212c: giving up capability 25 212c: freeing capability 25 2444: new worker task (taskCount: 27) 2444: new worker task (taskCount: 28) 1a9c: cap 27: schedule() 1a9c: giving up capability 27 1a9c: freeing capability 27 2444: new worker task (taskCount: 29) 1860: cap 28: schedule() 1860: giving up capability 28 1860: freeing capability 28 2444: new worker task (taskCount: 30) 94c: cap 29: schedule() 2444: new worker task (taskCount: 31) so me : 24SetThreadGroupAffinitye0: : Tcap 30: schedule() he parame te r is incorrect. 94c: giving up capability 29 94c: freeing capability 29 24e0: giving up capability 30 24e0: freeing capability 30 2444: new worker task (taskCount: 32) 1768: cap 31: schedule() 1768: giving up capability 31 1768: freeing capability 31 2444: new worker task (taskCount: 33) 2570: cap 32: schedule() 2570: giving up capability 32 2570: freeing capability 32 2444: new worker task (taskCount: 34) 2574: cap 33: schedule() 2574: giving up capability 33 2574: freeing capability 33 2444: new worker task (taskCount: 35) 58c: cap 34: schedule() 58c: giving up capability 34 58c: freeing capability 34 2444: new worker task (taskCount: 36) 11bc: cap 35: schedule() 11bc: giving up capability 35 11bc: freeing capability 35 2444: new worker task (taskCount: 37) 2444: new worker task (taskCount: 38) 2444: new worker task (taskCount: 39) bd4: cap 37: schedule() 18b0: cap 36: schedule() 18b0: giving up capability 36 18b0: freeing capability 36 b98: cap 39: schedule() bd4: giving up capability 37 bd4: freeing capability 37 2444: new worker task (taskCount: 40) b98: giving up capability 39 b98: freeing capability 39 2444: new worker task (taskCount: 41) 24dc: cap 40: schedule() 24dc: giving up capability 40 24dc: freeing capability 40 1838: cap 41: schedule() 1838: giving up capability 41 1838: freeing capability 41 1590: cap 38: schedule() 1590: giving up capability 38 1590: freeing capability 38 2444: new worker task (taskCount: 42) 2444: new worker task (taskCount: 43) 480: cap 42: schedule() 480: giving up capability 42 480: freeing capability 42 2444: new worker task (taskCount: 44) 1ac0: cap 43: schedule() 1ac0: giving up capability 43 1ac0: freeing capability 43 2444: new worker task (taskCount: 45) 18e0: cap 44: schedule() 18e0: giving up capability 44 18e0: freeing capability 44 2444: new worker task (taskCount: 46) 1fd0: cap 45: schedule() 1fd0: giving up capability 45 1fd0: freeing capability 45 2444: new worker task (taskCount: 47) 1fac: cap 46: schedule() 1fac: giving up capability 46 1fac: freeing capability 46 2444: new worker task (taskCount: 48) 11e8: cap 47: schedule() 11e8: giving up capability 47 11e8: freeing capability 47 2444: new worker task (taskCount: 49) 2444: new worker task (taskCount: 50) 2444: new worker task (taskCount: 51) 2444: new worker task (taskCount: 52) 2444: new worker task (taskCount: 53) 12b8: cap 50: schedule() 12b8: giving up capability 50 12b8: freeing capability 50 1ec0: cap 49: schedule() 1ec0: giving up capability 49 1ec0: freeing capability 49 1ebc: cap 53: schedule() 1908: cap 48: schedule() 1908: giving up capability 48 1908: freeing capability 48 2444: new worker task (taskCount: 54) 2444: new worker task (taskCount: 55) 1eb8: cap 51: schedule() 1eb8: giving up capability 51 1eb8: freeing capability 51 418: cap 54: schedule() 418: giving up capability 54 418: freeing capability 54 610: cap 52: schedule() 1ebc: giving up capability 53 1ebc: freeing capability 53 1564: cap 55: schedule() 1564: giving up capability 55 1564: freeing capability 55 610: giving up capability 52 610: freeing capability 52 2444: new worker task (taskCount: 56) a04: cap 56: schedule() a04: giving up capability 56 a04: freeing capability 56 2444: new worker task (taskCount: 57) 2444: new worker task (taskCount: 58) 140c: cap 57: schedule() 140c: giving up capability 57 140c: freeing capability 57 2444: new worker task (taskCount: 59) 2444: new worker task (taskCount: 60) 1b30: cap 58: schedule() 1a34: cap 59: schedule() 2444: new worker task (taskCount: 61) 14b8: cap 60: schedule() 14b8: giving up capability 60 14b8: freeing capability 60 1944: cap 61: schedule() 1944: giving up capability 61 1944: freeing capability 61 1a34: giving up capability 59 1a34: freeing capability 59 1b30: giving up capability 58 1b30: freeing capability 58 2444: new worker task (taskCount: 62) 2444: new worker task (taskCount: 63) 2444: new worker task (taskCount: 64) 8cc: cap 62: schedule() 2108: cap 63: schedule() 2108: giving up capability 63 2108: freeing capability 63 8cc: giving up capability 62 8cc: freeing capability 62 2180: cap 64: schedule() 2444: new worker task (taskCount: 65) 2180: giving up capability 64 2180: freeing capability 64 221c: cap 65: schedule() 221c: giving up capability 65 221c: freeing capability 65 2444: new worker task (taskCount: 66) 1b60: cap 66: schedule() 1b60: giving up capability 66 1b60: freeing capability 66 2444: new worker task (taskCount: 67) 2340: cap 67: schedule() 2340: giving up capability 67 2340: freeing capability 67 2444: new worker task (taskCount: 68) 2444: new worker task (taskCount: 69) 2444: new worker task (taskCount: 70) 188c: cap 68: schedule() 188c: giving up capability 68 188c: freeing capability 68 2454: cap 70: schedule() 2454: giving up capability 70 2454: freeing capability 70 1d50: cap 69: schedule() 1d50: giving up capability 69 1d50: freeing capability 69 2444: new worker task (taskCount: 71) 2444: new worker task (taskCount: 72) 1a38: cap 71: schedule() 1a38: giving up capability 71 1a38: freeing capability 71 2444: new worker task (taskCount: 73) 2444: new worker task (taskCount: 74) 7e0: cap 72: schedule() 2404: cap 73: schedule() 2404: giving up capability 73 2404: freeing capability 73 7e0: giving up capability 72 7e0: freeing capability 72 2428: cap 74: schedule() 2428: giving up capability 74 2428: freeing capability 74 2444: new worker task (taskCount: 75) some: SetThreadGroupAffinity: The parameter is incorrect. 2444: new worker task (taskCount: 76) 2444: new worker task (taskCount: 77) 2424: cap 75: schedule() 2424: giving up capability 75 2424: freeing capability 75 1a28: cap 77: schedule() 1ef0: cap 76: schedule() 1ef0: giving up capability 76 1ef0: freeing capability 76 2444: new worker task (taskCount: 78) 1a28: giving up capability 77 1a28: freeing capability 77 8a8: cap 78: schedule() 8a8: giving up capability 78 8a8: freeing capability 78 2444: new worker task (taskCount: 79) 2444: new worker task (taskCount: 80) 1c2c: cap 79: schedule() 2444: new worker task (taskCount: 81) 1be8: cap 80: schedule() 1be8: giving up capability 80 1be8: freeing capability 80 1534: cap 81: schedule() 1534: giving up capability 81 1534: freeing capability 81 1c2c: giving up capability 79 1c2c: freeing capability 79 2444: new worker task (taskCount: 82) 2444: new worker task (taskCount: 83) 1254: cap 82: schedule() 1254: giving up capability 82 1254: freeing capability 82 2444: new worker task (taskCount: 84) 948: cap 83: schedule() 948: giving up capability 83 948: freeing capability 83 2444: new worker task (taskCount: 85) 17f8: cap 84: schedule() 17f8: giving up capability 84 17f8: freeing capability 84 2444: new worker task (taskCount: 86) 1be4: cap 85: schedule() 1be4: giving up capability 85 1be4: freeing capability 85 2444: new worker task (taskCount: 87) 240c: cap 86: schedule() 11b4: cap 87: schedule() 11b4: giving up capability 87 11b4: freeing capability 87 2444: new task (taskCount: 88) 2444: returning; I want capability 87 2444: resuming capability 87 2444: cap 87: created thread 1 2444: new bound thread (1) 2444: cap 87: schedule() 2444: cap 87: running thread 1 (ThreadRunGHC) 240c: giving up capability 86 240c: freeing capability 86 2444: cap 87: created thread 2 2444: cap 87: thread 1 stopped (yielding) 2444: cap 87: 2 threads, 0 sparks, and 1 free capabilities, sharing... 2444: cap 87: thread 2 migrating to cap 0 2444: starting new worker on capability 0 2444: new worker task (taskCount: 89) 2444: cap 87: running thread 1 (ThreadRunGHC) 2444: cap 87: thread 1 stopped (finished) 2444: bound thread (1) finished 2444: freeing capability 87 2444: task exiting 2444: new task (taskCount: 89) 2444: returning; I want capability 87 2444: resuming capability 87 2444: cap 87: created thread 3 2444: new bound thread (3) 2444: cap 87: schedule() 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: created thread 4 2444: cap 87: created thread 5 2444: cap 87: created thread 6 2444: cap 87: created thread 7 2444: cap 87: created thread 8 2444: cap 87: thread 3 stopped (yielding) 2444: cap 87: 6 threads, 0 sparks, and 5 free capabilities, sharing... 2444: cap 87: thread 4 migrating to cap 1 2444: cap 87: thread 5 migrating to cap 2 2444: cap 87: thread 6 migrating to cap 3 2444: cap 87: thread 7 migrating to cap 4 2444: cap 87: thread 8 migrating to cap 5 2444: passing capability 1 to worker 0x1d40 2444: passing capability 2 to worker 0x166c 2444: passing capability 3 to worker 0x2600 2444: passing capability 4 to worker 0x25fc 1de4: cap 0: schedule() 1de4: cap 0: running thread 2 (ThreadRunGHC) 1d40: woken up on capability 1 1d40: resuming capability 1 1d40: cap 1: running thread 4 (ThreadRunGHC) 2444: passing capability 5 to worker 0x25f8 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: created thread 9 2444: cap 87: thread 3 stopped (yielding) 2444: passing capability 2 to worker 0x166c 2444: passing capability 3 to worker 0x2600 2444: passing capability 4 to worker 0x25fc 2444: passing capability 5 to worker 0x25f8 2444: cap 87: 2 threads, 0 sparks, and 1 free capabilities, sharing... 2444: cap 87: thread 9 migrating to cap 6 2444: passing capability 6 to worker 0x25f0 2444: cap 87: running thread 3 (ThreadRunGHC) 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: cap 5: running thread 8 (ThreadRunGHC) 25f8: cap 5: message: thread 8 blocking on blackhole 0000000030404000 25f8: cap 5: forwarding message to cap 1 25f8: cap 5: thread 8 stopped (blocked on black hole owned by thread 4) thread 25f0: 8 woken up on capability 6@ 25f0: resuming capability 6 25f0: cap 6: running thread 9 (ThreadRunGHC) 25f0: cap 6: message: thread 9 blocking on blackhole 0000000030404000 25f0: cap 6: forwarding message to cap 1 0000000035b07000 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 25fc: woken up on capability 4 25fc: resuming capability 4 25fc: cap 4: running thread 7 (ThreadRunGHC) 25fc: cap 4: message: thread 7 blocking on blackhole 0000000030404000 25fc: cap 4: forwarding message to cap 1 25fc: cap 4: thread 7 stopped (blocked on black hole owned by thread 4) t hread 7 @ 0000000035b06c00 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 25f0: cap 6: thread 9 stopped (blocked on black hole owned by thread 4) thread 9 @ 0000000035b07400 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 25f8: giving up capability 5 25f8: freeing capability 5 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: giving up capability 5 25f8: freeing capability 5 25fc: giving up capability 4 25fc: freeing capability 4 25fc: woken up on capability 4 25fc: resuming capability 4 25fc: giving up capability 4 25fc: freeing capability 4 2600: woken up on capability 3 2600: resuming capability 3 2600: cap 3: running thread 6 (ThreadRunGHC) 2600: cap 3: message: thread 6 blocking on blackhole 0000000030404000 2600: cap 3: forwarding message to cap 1 2600: cap 3: thread 6 stopped (blocked on black hole owned by thread 4) t 25f0: giving up capability 6 hr 25f0: freeing capability 6 ead 6 @ 0000000035b06800 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 2444: cap 87: created thread 10 2444: cap 87: thread 3 stopped (yielding) 2444: passing capability 2 to worker 0x166c 2444: cap 87: 2 threads, 0 sparks, and 1 free capabilities, sharing... 2444: cap 87: thread 10 migrating to cap 4 2444: passing capability 4 to worker 0x25fc 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: created thread 11 2444: cap 87: created thread 12 2444: cap 87: thread 3 stopped (blocked on an MVar) thread 3 @ 0000000035b05b98 is blocked on an MVar @ 0000000035b049a8 (TSO_DIRTY) 25fc: woken up on capability 4 25fc: resuming capability 4 25fc: cap 4: running thread 10 (ThreadRunGHC) 25fc: cap 4: message: thread 10 blocking on blackhole 0000000030404000 25fc: cap 4: forwarding message to cap 1 25fc: cap 4: thread 10 stopped (blocked on black hole owned by thread 4) t 1de4: hread cap 0: thread 2 stopped (suspended while making a foreign call) 1 1de4: 0starting new worker on capability 0 @ 0000000035b07800 is blocked on a black 2600: hgiving up capability 3 ol 2600: freeing capability 3 e 0000000030404000 (TSO_DIRTY) 2600: woken up on capability 3 2600: resuming capability 3 2600: giving up capability 3 2600: freeing capability 3 2444: passing capability 2 to worker 0x166c 2444: cap 87: 2 threads, 0 sparks, and 1 free capabilities, sharing... 2444: cap 87: thread 11 migrating to cap 3 2444: passing capability 3 to worker 0x2600 2444: giving up capability 87 2444: passing capability 87 to worker 0x11b4 1d40: cap 1: thread 4 stopped (yielding) 1de4: new worker task (taskCount: 90) 1de4: returning; I want capability 0 2600: woken up on capability 3 2600: resuming capability 3 2600: cap 3: running thread 11 (ThreadRunGHC) 2600: cap 3: message: thread 11 blocking on blackhole 0000000030404000 2600: cap 3: forwarding message to cap 1 2600: cap 3: thread 11 stopped (blocked on black hole owned by thread 4) thread 11 @ 0000000035b07c00 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 25fc: giving up capability 4 25fc: freeing capability 4 1d40: cap 1: message: thread 10 blocking on blackhole 0000000030404000 1d40: cap 1: thread 10 blocked on thread 4 1d40: cap 1: message: thread 6 blocking on blackhole 0000000030404000 1d40: cap 1: thread 6 blocked on thread 4 1d40: cap 1: message: thread 7 blocking on blackhole 0000000030404000 1d40: cap 1: thread 7 blocked on thread 4 1d40: cap 1: message: thread 9 blocking on blackhole 0000000030404000 1d40: cap 1: thread 9 blocked on thread 4 1d40: cap 1: message: thread 8 blocking on blackhole 0000000030404000 1d40: cap 1: thread 8 blocked on thread 4 1d40: cap 1: message: thread 11 blocking on blackhole 0000000030404000 1d40: cap 1: thread 11 blocked on thread 4 1d40: cap 1: running thread 4 (ThreadRunGHC) 1d40: cap 1: thread 4 stopped (yielding) 1d40: cap 1: running thread 4 (ThreadRunGHC) 2600: giving up capability 3 2600: freeing capability 3 166c: woken up on capability 2 166c: resuming capability 2 166c: cap 2: running thread 5 (ThreadRunGHC) 166c: cap 2: message: thread 5 blocking on blackhole 0000000030404000 166c: cap 2: forwarding message to cap 1 166c: cap 2: thread 5 stopped (blocked on black hole owned by thread 4) t 11b4: woken up on capability 87 hread 5 @ 11b4: resuming capability 87 11b4: cap 87: running thread 12 (ThreadRunGHC) 0000000035b06400 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 11b4: cap 87: message: thread 12 blocking on blackhole 0000000030404000 11b4: cap 87: forwarding message to cap 1 11b4: cap 87: thread 12 stopped (blocked on black hole owned by thread 4) thread 12 @ 0000000035b08000 is blocked on a black hole 0000000030404000 (TSO_DIRTY) 166c: giving up capability 2 166c: freeing capability 2 166c: woken up on capability 2 166c: resuming capability 2 166c: giving up capability 2 166c: freeing capability 2 11b4: giving up capability 87 11b4: freeing capability 87 1f58: cap 0: schedule() 1d40: cap 1: thread 4 stopped (stack overflow) 1d40: cap 1: allocating new stack chunk of size 32768 bytes 1f58: giving up capability 0 1f58: passing capability 0 to worker 0x1de4 1d40: cap 1: message: thread 12 blocking on blackhole 0000000030404000 1d40: cap 1: thread 12 blocked on thread 4 1d40: cap 1: message: thread 5 blocking on blackhole 0000000030404000 1d40: cap 1: thread 5 blocked on thread 4 1d40: cap 1: running thread 4 (ThreadRunGHC) 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1d40: cap 1: thread 4 stopped (yielding) 1d40: cap 1: running thread 4 (ThreadRunGHC) 1de4: cap 0: waking up thread 3 on cap 87 1de4: passing capability 87 to worker 0x11b4 1de4: cap 0: message: try wakeup thread 3 on cap 87 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: freeing capability 0 1d40: cap 1: thread 4 stopped (yielding) 1d40: cap 1: running thread 4 (ThreadRunGHC) 11b4: woken up on capability 87 11b4: resuming capability 87 11b4: cap 87: message: try wakeup thread 3 11b4: cap 87: waking up thread 3 on cap 87 11b4: giving up capability 87 11b4: passing capability 87 to bound task 0x2444 2444: woken up on capability 87 2444: resuming capability 87 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (yielding) 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (blocked on an MVar) thread 3 @ 1d40: 0000000035b05b98 is blocked on an MVar @ cap 1: thread 4 stopped (heap overflow) 00 1de4: 0returning; I want capability 0 00 1de4: 00035b04ca8 (TSO_DIRTY) resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1de4: cap 0: waking up thread 3 on cap 87 1de4: cap 0: message: try wakeup thread 3 on cap 87 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: freeing capability 0 2444: cap 87: starting GC 1d40: cap 1: requesting parallel GC 1d40: 0 idle caps 1d40: passing capability 0 to worker 0x1f58 1d40: passing capability 2 to worker 0x166c 1d40: passing capability 3 to worker 0x2600 1d40: passing capability 4 to worker 0x25fc 1d40: passing capability 5 to worker 0x25f8 1d40: passing capability 6 to worker 0x25f0 1d40: passing capability 7 to worker 0x25f4 1d40: passing capability 8 to worker 0x2210 1d40: passing capability 9 to worker 0x270 1f58: woken up on capability 0 1f58: resuming capability 0 1f58: cap 0: starting GC 25f0: woken up on capability 6 25f0: resuming capability 6 25f0: cap 6: starting GC 166c: woken up on capability 2 166c: resuming capability 2 166c: cap 2: starting GC 270: woken up on capability 9 270: resuming capability 9 270: cap 9: starting GC 25fc: woken up on capability 4 25fc: resuming capability 4 25fc: cap 4: starting GC 1d40: passing capability 10 to worker 0x6c8 1d40: passing capability 11 to worker 0x17b8 1d40: passing capability 12 to worker 0x1aa8 1d40: passing capability 13 to worker 0x454 1d40: passing capability 14 to worker 0x2720 1d40: passing capability 15 to worker 0x15e8 1d40: passing capability 16 to worker 0x85c 1d40: passing capability 17 to worker 0x9b8 1d40: passing capability 18 to worker 0x464 1aa8: woken up on capability 12 1aa8: resuming capability 12 1aa8: cap 12: starting GC 454: woken up on capability 13 454: resuming capability 13 454: cap 13: starting GC 15e8: woken up on capability 15 15e8: resuming capability 15 15e8: cap 15: starting GC 85c: woken up on capability 16 85c: resuming capability 16 85c: cap 16: starting GC 1d40: passing capability 19 to worker 0x13a8 464: woken up on capability 18 464: resuming capability 18 464: cap 18: starting GC 2720: woken up on capability 14 2720: resuming capability 14 2720: cap 14: starting GC 2600: woken up on capability 3 2600: resuming capability 3 2600: cap 3: starting GC 1d40: passing capability 20 to worker 0x1244 1d40: passing capability 21 to worker 0x1510 1d40: passing capability 22 to worker 0x1848 1d40: passing capability 23 to worker 0x229c 1d40: passing capability 24 to worker 0x2178 1d40: passing capability 25 to worker 0x212c 1d40: passing capability 26 to worker 0x1eb4 1d40: passing capability 27 to worker 0x1a9c 1d40: passing capability 28 to worker 0x1860 1244: woken up on capability 20 1244: resuming capability 20 1244: cap 20: starting GC 2210: woken up on capability 8 2210: resuming capability 8 2210: cap 8: starting GC 229c: woken up on capability 23 229c: resuming capability 23 229c: cap 23: starting GC 9b8: woken up on capability 17 9b8: resuming capability 17 9b8: cap 17: starting GC 1eb4: woken up on capability 26 1eb4: resuming capability 26 1eb4: cap 26: starting GC 1d40: passing capability 29 to worker 0x94c 1d40: passing capability 30 to worker 0x24e0 1d40: passing capability 31 to worker 0x1768 1d40: passing capability 32 to worker 0x2570 1d40: passing capability 33 to worker 0x2574 1d40: passing capability 34 to worker 0x58c 1de4: returning; I want capability 0 6c8: woken up on capability 10 6c8: resuming capability 10 6c8: cap 10: starting GC 17b8: woken up on capability 11 17b8: resuming capability 11 17b8: cap 11: starting GC 1860: woken up on capability 28 1860: resuming capability 28 1860: cap 28: starting GC 24e0: woken up on capability 30 24e0: resuming capability 30 24e0: cap 30: starting GC 2570: woken up on capability 32 2570: resuming capability 32 2570: cap 32: starting GC 2574: woken up on capability 33 2574: resuming capability 33 2574: cap 33: starting GC 2178: woken up on capability 24 2178: resuming capability 24 2178: cap 24: starting GC 1a9c: woken up on capability 27 1a9c: resuming capability 27 1a9c: cap 27: starting GC 1510: woken up on capability 21 1510: resuming capability 21 1510: cap 21: starting GC 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: cap 5: starting GC 212c: woken up on capability 25 212c: resuming capability 25 212c: cap 25: starting GC 25f4: woken up on capability 7 25f4: resuming capability 7 25f4: cap 7: starting GC 1d40: passing capability 35 to worker 0x11bc 58c: woken up on capability 34 58c: resuming capability 34 58c: cap 34: starting GC 1768: woken up on capability 31 1768: resuming capability 31 1768: cap 31: starting GC 11bc: woken up on capability 35 11bc: resuming capability 35 11bc: cap 35: starting GC 1848: woken up on capability 22 1848: resuming capability 22 1848: cap 22: starting GC 94c: woken up on capability 29 94c: resuming capability 29 94c: cap 29: starting GC 1d40: passing capability 36 to worker 0x18b0 1d40: passing capability 37 to worker 0xbd4 18b0: woken up on capability 36 18b0: resuming capability 36 18b0: cap 36: starting GC bd4: woken up on capability 37 bd4: resuming capability 37 bd4: cap 37: starting GC 13a8: woken up on capability 19 13a8: resuming capability 19 13a8: cap 19: starting GC 1d40: passing capability 38 to worker 0x1590 1d40: passing capability 39 to worker 0xb98 1590: woken up on capability 38 1590: resuming capability 38 1590: cap 38: starting GC 1d40: passing capability 40 to worker 0x24dc b98: woken up on capability 39 b98: resuming capability 39 b98: cap 39: starting GC 1d40: passing capability 41 to worker 0x1838 24dc: woken up on capability 40 24dc: resuming capability 40 24dc: cap 40: starting GC 1d40: passing capability 42 to worker 0x480 1838: woken up on capability 41 1838: resuming capability 41 1838: cap 41: starting GC 1d40: passing capability 43 to worker 0x1ac0 480: woken up on capability 42 480: resuming capability 42 480: cap 42: starting GC 1d40: passing capability 44 to worker 0x18e0 1ac0: woken up on capability 43 1ac0: resuming capability 43 1ac0: cap 43: starting GC 1d40: passing capability 45 to worker 0x1fd0 1d40: passing capability 46 to worker 0x1fac 1d40: passing capability 47 to worker 0x11e8 1d40: passing capability 48 to worker 0x1908 1d40: passing capability 49 to worker 0x1ec0 1d40: passing capability 50 to worker 0x12b8 1d40: passing capability 51 to worker 0x1eb8 1d40: passing capability 52 to worker 0x610 1d40: passing capability 53 to worker 0x1ebc 1d40: passing capability 54 to worker 0x418 1d40: passing capability 55 to worker 0x1564 1d40: passing capability 56 to worker 0xa04 1d40: passing capability 57 to worker 0x140c 1d40: passing capability 58 to worker 0x1b30 1d40: passing capability 59 to worker 0x1a34 1d40: passing capability 60 to worker 0x14b8 1d40: passing capability 61 to worker 0x1944 1d40: passing capability 62 to worker 0x8cc 1d40: passing capability 63 to worker 0x2108 1d40: passing capability 64 to worker 0x2180 1d40: passing capability 65 to worker 0x221c 1d40: passing capability 66 to worker 0x1b60 1d40: passing capability 67 to worker 0x2340 1d40: passing capability 68 to worker 0x188c 1d40: passing capability 69 to worker 0x1d50 1d40: passing capability 70 to worker 0x2454 1d40: passing capability 71 to worker 0x1a38 1d40: passing capability 72 to worker 0x7e0 1d40: passing capability 73 to worker 0x2404 1d40: passing capability 74 to worker 0x2428 1d40: passing capability 75 to worker 0x2424 1d40: passing capability 76 to worker 0x1ef0 1d40: passing capability 77 to worker 0x1a28 1d40: passing capability 78 to worker 0x8a8 1d40: passing capability 79 to worker 0x1c2c 1d40: passing capability 80 to worker 0x1be8 1d40: passing capability 81 to worker 0x1534 1d40: passing capability 82 to worker 0x1254 1d40: passing capability 83 to worker 0x948 1d40: passing capability 84 to worker 0x17f8 1d40: passing capability 85 to worker 0x1be4 1d40: passing capability 86 to worker 0x240c 221c: woken up on capability 65 221c: resuming capability 65 221c: cap 65: starting GC 1ec0: woken up on capability 49 1ec0: resuming capability 49 1ec0: cap 49: starting GC 18e0: woken up on capability 44 188c: woken up on capability 68 188c: resuming capability 68 188c: cap 68: starting GC 12b8: woken up on capability 50 12b8: resuming capability 50 12b8: cap 50: starting GC 1a38: woken up on capability 71 1a38: resuming capability 71 1a38: cap 71: starting GC 2404: woken up on capability 73 2404: resuming capability 73 2404: cap 73: starting GC 2428: woken up on capability 74 2428: resuming capability 74 2428: cap 74: starting GC 1fd0: woken up on capability 45 1fd0: resuming capability 45 1fd0: cap 45: starting GC 1a28: woken up on capability 77 1a28: resuming capability 77 1a28: cap 77: starting GC 1c2c: woken up on capability 79 1c2c: resuming capability 79 1c2c: cap 79: starting GC 1be8: woken up on capability 80 1be8: resuming capability 80 1be8: cap 80: starting GC 1ebc: woken up on capability 53 1ebc: resuming capability 53 1ebc: cap 53: starting GC 948: woken up on capability 83 948: resuming capability 83 948: cap 83: starting GC 2180: woken up on capability 64 2180: resuming capability 64 2180: cap 64: starting GC 1d40: passing capability 44 to worker 0x18e0 1d40: passing capability 46 to worker 0x1fac 1d40: passing capability 47 to worker 0x11e8 1d40: passing capability 48 to worker 0x1908 1d40: passing capability 51 to worker 0x1eb8 1d40: passing capability 52 to worker 0x610 1d40: passing capability 54 to worker 0x418 1d40: passing capability 55 to worker 0x1564 1d40: passing capability 56 to worker 0xa04 1d40: passing capability 57 to worker 0x140c 1d40: passing capability 58 to worker 0x1b30 1d40: passing capability 59 to worker 0x1a34 1d40: passing capability 60 to worker 0x14b8 1d40: passing capability 61 to worker 0x1944 1d40: passing capability 62 to worker 0x8cc 1d40: passing capability 63 to worker 0x2108 1d40: passing capability 66 to worker 0x1b60 1d40: passing capability 67 to worker 0x2340 1d40: passing capability 69 to worker 0x1d50 1d40: passing capability 70 to worker 0x2454 1d40: passing capability 72 to worker 0x7e0 1d40: passing capability 75 to worker 0x2424 1d40: passing capability 76 to worker 0x1ef0 1d40: passing capability 78 to worker 0x8a8 1d40: passing capability 81 to worker 0x1534 1d40: passing capability 82 to worker 0x1254 1d40: passing capability 84 to worker 0x17f8 1d40: passing capability 85 to worker 0x1be4 1d40: passing capability 86 to worker 0x240c 18e0: resuming capability 44 18e0: cap 44: starting GC 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: cap 66: starting GC a04: woken up on capability 56 a04: resuming capability 56 a04: cap 56: starting GC 140c: woken up on capability 57 140c: resuming capability 57 140c: cap 57: starting GC 1b30: woken up on capability 58 1b30: resuming capability 58 1b30: cap 58: starting GC 1a34: woken up on capability 59 1a34: resuming capability 59 1a34: cap 59: starting GC 610: woken up on capability 52 610: resuming capability 52 610: cap 52: starting GC 1908: woken up on capability 48 1908: resuming capability 48 1908: cap 48: starting GC 1254: woken up on capability 82 1254: resuming capability 82 1254: cap 82: starting GC 17f8: woken up on capability 84 17f8: resuming capability 84 17f8: cap 84: starting GC 1d40: passing capability 46 to worker 0x1fac 1d40: passing capability 47 to worker 0x11e8 1d40: passing capability 51 to worker 0x1eb8 1d40: passing capability 54 to worker 0x418 1d40: passing capability 55 to worker 0x1564 1d40: passing capability 60 to worker 0x14b8 1d40: passing capability 61 to worker 0x1944 1d40: passing capability 62 to worker 0x8cc 1d40: passing capability 63 to worker 0x2108 1d40: passing capability 67 to worker 0x2340 1d40: passing capability 69 to worker 0x1d50 1d40: passing capability 70 to worker 0x2454 1d40: passing capability 72 to worker 0x7e0 1d40: passing capability 75 to worker 0x2424 1d40: passing capability 76 to worker 0x1ef0 1d40: passing capability 78 to worker 0x8a8 1d40: passing capability 81 to worker 0x1534 1d40: passing capability 85 to worker 0x1be4 1d40: passing capability 86 to worker 0x240c 240c: woken up on capability 86 240c: resuming capability 86 240c: cap 86: starting GC 2340: woken up on capability 67 2340: resuming capability 67 2340: cap 67: starting GC 11e8: woken up on capability 47 11e8: resuming capability 47 11e8: cap 47: starting GC 2424: woken up on capability 75 2424: resuming capability 75 2424: cap 75: starting GC 8a8: woken up on capability 78 8a8: resuming capability 78 8a8: cap 78: starting GC 8cc: woken up on capability 62 8cc: resuming capability 62 8cc: cap 62: starting GC 1be4: woken up on capability 85 1be4: resuming capability 85 1be4: cap 85: starting GC 1564: woken up on capability 55 1564: resuming capability 55 1564: cap 55: starting GC 7e0: woken up on capability 72 7e0: resuming capability 72 7e0: cap 72: starting GC 14b8: woken up on capability 60 14b8: resuming capability 60 14b8: cap 60: starting GC 2108: woken up on capability 63 2108: resuming capability 63 2108: cap 63: starting GC 418: woken up on capability 54 418: resuming capability 54 418: cap 54: starting GC 1eb8: woken up on capability 51 1eb8: resuming capability 51 1eb8: cap 51: starting GC 1534: woken up on capability 81 1534: resuming capability 81 1534: cap 81: starting GC 1d50: woken up on capability 69 1d50: resuming capability 69 1d50: cap 69: starting GC 1944: woken up on capability 61 1944: resuming capability 61 1944: cap 61: starting GC 2454: woken up on capability 70 2454: resuming capability 70 2454: cap 70: starting GC 1d40: passing capability 46 to worker 0x1fac 1d40: passing capability 76 to worker 0x1ef0 1fac: woken up on capability 46 1ef0: woken up on capability 76 1ef0: resuming capability 76 1ef0: cap 76: starting GC 1d40: passing capability 46 to worker 0x1fac 1fac: resuming capability 46 1fac: cap 46: starting GC all threads: threads on capability 0: threads on capability 1: thread 4 @ 0000000035b06000 is not blocked (TSO_DIRTY) threads on capability 2: threads on capability 3: threads on capability 4: threads on capability 5: threads on capability 6: threads on capability 7: threads on capability 8: threads on capability 9: threads on capability 10: threads on capability 11: threads on capability 12: threads on capability 13: threads on capability 14: threads on capability 15: threads on capability 16: threads on capability 17: threads on capability 18: threads on capability 19: threads on capability 20: threads on capability 21: threads on capability 22: threads on capability 23: threads on capability 24: threads on capability 25: threads on capability 26: threads on capability 27: threads on capability 28: threads on capability 29: threads on capability 30: threads on capability 31: threads on capability 32: threads on capability 33: threads on capability 34: threads on capability 35: threads on capability 36: threads on capability 37: threads on capability 38: threads on capability 39: threads on capability 40: threads on capability 41: threads on capability 42: threads on capability 43: threads on capability 44: threads on capability 45: threads on capability 46: threads on capability 47: threads on capability 48: threads on capability 49: threads on capability 50: threads on capability 51: threads on capability 52: threads on capability 53: threads on capability 54: threads on capability 55: threads on capability 56: threads on capability 57: threads on capability 58: threads on capability 59: threads on capability 60: threads on capability 61: threads on capability 62: threads on capability 63: threads on capability 64: threads on capability 65: threads on capability 66: threads on capability 67: threads on capability 68: threads on capability 69: threads on capability 70: threads on capability 71: threads on capability 72: threads on capability 73: threads on capability 74: threads on capability 75: threads on capability 76: threads on capability 77: threads on capability 78: threads on capability 79: threads on capability 80: threads on capability 81: threads on capability 82: threads on capability 83: threads on capability 84: threads on capability 85: threads on capability 86: threads on capability 87: other threads: thread 12 @ 0000000035b08000 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 11 @ 0000000035b07c00 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 10 @ 0000000035b07800 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 9 @ 0000000035b07400 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 8 @ 0000000035b07000 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 7 @ 0000000035b06c00 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 6 @ 0000000035b06800 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 5 @ 0000000035b06400 is blocked on a black hole 0000000030404000 (TSO_DIRTY) thread 3 @ 0000000035b05b98 is blocked on an MVar @ 0000000035b04ca8 (TSO_DIRTY) thread 2 @ 0000000035b05798 is blocked on an external call (TSO_DIRTY) 1d40: cap 1: starting GC 1f58: cap 0: GC working 25f0: cap 6: GC working 8a8: cap 78: GC working 1a9c: cap 27: GC working 166c: cap 2: GC working 240c: cap 86: GC working 140c: cap 57: GC working 1be4: cap 85: GC working 1838: cap 41: GC working 1838: cap 41: GC idle 1ebc: cap 53: GC working 1ebc: cap 53: GC idle 94c: cap 29: GC working 1d40: cap 1: GC working 1534: cap 81: GC working 270: cap 9: GC working 270: cap 9: GC idle 188c: cap 68: GC working 2404: cap 73: GC working 2404: cap 73: GC idle 24dc: cap 40: GC working 24dc: cap 40: GC idle 24e0: cap 30: GC working 24e0: cap 30: GC idle 15e8: cap 15: GC working 15e8: cap 15: GC idle 221c: cap 65: GC working 221c: cap 65: GC idle 2428: cap 74: GC working 2428: cap 74: GC idle 480: cap 42: GC working 2210: cap 8: GC working 2210: cap 8: GC idle 1ef0: cap 76: GC working 1ef0: cap 76: GC idle 1590: cap 38: GC working 1590: cap 38: GC idle 1be8: cap 80: GC working 85c: cap 16: GC working 85c: cap 16: GC idle 17f8: cap 84: GC working 17f8: cap 84: GC idle 1510: cap 21: GC working 1510: cap 21: GC idle 11bc: cap 35: GC working 11bc: cap 35: GC idle 454: cap 13: GC working 454: cap 13: GC idle 2570: cap 32: GC working 2570: cap 32: GC idle 2574: cap 33: GC working 2574: cap 33: GC idle 2340: cap 67: GC working 2340: cap 67: GC idle 18b0: cap 36: GC working 18b0: cap 36: GC idle 948: cap 83: GC working 948: cap 83: GC idle 1aa8: cap 12: GC working 1aa8: cap 12: GC idle 2108: cap 63: GC working 1eb8: cap 51: GC working 1eb8: cap 51: GC idle b98: cap 39: GC working b98: cap 39: GC idle 1a28: cap 77: GC working 1a28: cap 77: GC idle 1254: cap 82: GC working 1254: cap 82: GC idle 13a8: cap 19: GC working 13a8: cap 19: GC idle 464: cap 18: GC working 464: cap 18: GC idle 11e8: cap 47: GC working 11e8: cap 47: GC idle 25f8: cap 5: GC working 25f8: cap 5: GC idle 1eb4: cap 26: GC working 1eb4: cap 26: GC idle 1ec0: cap 49: GC working 1ec0: cap 49: GC idle 2178: cap 24: GC working 2178: cap 24: GC idle 6c8: cap 10: GC working 2444: cap 87: GC working 9b8: cap 17: GC working 9b8: cap 17: GC idle 212c: cap 25: GC working 1f58: cap 0: GC idle 25f0: cap 6: GC idle 8a8: cap 78: GC idle 1a9c: cap 27: GC idle 166c: cap 2: GC idle 240c: cap 86: GC idle 140c: cap 57: GC idle 1be4: cap 85: GC idle 1d50: cap 69: GC working 1908: cap 48: GC working 1908: cap 48: GC idle 1d40: cap 1: GC idle 1534: cap 81: GC idle 18e0: cap 44: GC working 18e0: cap 44: GC idle 1848: cap 22: GC working 1fd0: cap 45: GC working 58c: cap 34: GC working 1768: cap 31: GC working 418: cap 54: GC working 418: cap 54: GC idle 480: cap 42: GC idle 2720: cap 14: GC working 25fc: cap 4: GC working 25fc: cap 4: GC idle 1be8: cap 80: GC idle 25f4: cap 7: GC working 2600: cap 3: GC working 2600: cap 3: GC idle 1860: cap 28: GC working 12b8: cap 50: GC working 1564: cap 55: GC working 1564: cap 55: GC idle bd4: cap 37: GC working bd4: cap 37: GC idle 1a38: cap 71: GC working 229c: cap 23: GC working 229c: cap 23: GC idle 2454: cap 70: GC working 1ac0: cap 43: GC working 1ac0: cap 43: GC idle 1c2c: cap 79: GC working 2180: cap 64: GC working 1244: cap 20: GC working 1244: cap 20: GC idle 7e0: cap 72: GC working 17b8: cap 11: GC working 17b8: cap 11: GC idle 8cc: cap 62: GC working 6c8: cap 10: GC idle 2444: cap 87: GC idle 1fac: cap 46: GC working 1fac: cap 46: GC idle 1d50: cap 69: GC idle 94c: cap 29: GC idle 188c: cap 68: GC idle 1848: cap 22: GC idle 1fd0: cap 45: GC idle 58c: cap 34: GC idle 1768: cap 31: GC idle 1a34: cap 59: GC working 2720: cap 14: GC idle a04: cap 56: GC working 25f4: cap 7: GC idle 2424: cap 75: GC working 1860: cap 28: GC idle 12b8: cap 50: GC idle 1b60: cap 66: GC working 610: cap 52: GC working 610: cap 52: GC idle 2108: cap 63: GC idle 2454: cap 70: GC idle 1944: cap 61: GC working 1c2c: cap 79: GC idle 2180: cap 64: GC idle 1b30: cap 58: GC working 7e0: cap 72: GC idle 14b8: cap 60: GC working 14b8: cap 60: GC idle 14b8: cap 60: GC done 1d40: cap 1: GC done 1838: cap 41: GC done 1b30: cap 58: GC idle 1b30: cap 58: GC done 212c: cap 25: GC idle 212c: cap 25: GC done 25f0: cap 6: GC done 2574: cap 33: GC done 7e0: cap 72: GC done 1eb8: cap 51: GC done 24e0: cap 30: GC done a04: cap 56: GC idle a04: cap 56: GC done 25f4: cap 7: GC done 270: cap 9: GC done 9b8: cap 17: GC done 2108: cap 63: GC done 480: cap 42: GC done 15e8: cap 15: GC done 2340: cap 67: GC done 221c: cap 65: GC done 1aa8: cap 12: GC done 1a28: cap 77: GC done 1848: cap 22: GC done 6c8: cap 10: GC done bd4: cap 37: GC done 1590: cap 38: GC done 464: cap 18: GC done 1254: cap 82: GC done 1fac: cap 46: GC done 1908: cap 48: GC done 1ec0: cap 49: GC done 1860: cap 28: GC done 11bc: cap 35: GC done 1f58: cap 0: GC done 948: cap 83: GC done 24dc: cap 40: GC done 2180: cap 64: GC done 1eb4: cap 26: GC done b98: cap 39: GC done 13a8: cap 19: GC done 140c: cap 57: GC done 1ebc: cap 53: GC done 2570: cap 32: GC done 1fd0: cap 45: GC done 1be8: cap 80: GC done 1ac0: cap 43: GC done 166c: cap 2: GC done 18e0: cap 44: GC done 11e8: cap 47: GC done 1be4: cap 85: GC done 17f8: cap 84: GC done 12b8: cap 50: GC done 229c: cap 23: GC done 1768: cap 31: GC done 610: cap 52: GC done 2600: cap 3: GC done 1534: cap 81: GC done 58c: cap 34: GC done 454: cap 13: GC done 1244: cap 20: GC done 2424: cap 75: GC idle 2424: cap 75: GC done 188c: cap 68: GC done 1564: cap 55: GC done 85c: cap 16: GC done 1d50: cap 69: GC done 1944: cap 61: GC idle 1944: cap 61: GC done 2404: cap 73: GC done 25fc: cap 4: GC done 1b60: cap 66: GC idle 1b60: cap 66: GC done 8cc: cap 62: GC idle 8cc: cap 62: GC done 2454: cap 70: GC done 25f8: cap 5: GC done 8a8: cap 78: GC done 1a34: cap 59: GC idle 1a34: cap 59: GC done 94c: cap 29: GC done 418: cap 54: GC done 18b0: cap 36: GC done 240c: cap 86: GC done 2444: cap 87: GC done 2720: cap 14: GC done 1a9c: cap 27: GC done 1d40: cap 1: GC idle 1d40: cap 1: GC done 1d40: cap 1: GC idle 1d40: cap 1: GC done 1c2c: cap 79: GC done 2178: cap 24: GC done 17b8: cap 11: GC done 1510: cap 21: GC done 1a38: cap 71: GC idle 1a38: cap 71: GC done 1ef0: cap 76: GC done 2428: cap 74: GC done 2210: cap 8: GC done 1d40: cap 1: all caps stopped for GC 1d40: cap 1: finished GC 1f58: cap 0: finished GC 1f58: giving up capability 0 1f58: passing capability 0 to worker 0x1de4 212c: cap 25: finished GC 610: cap 52: finished GC 25f0: cap 6: finished GC 17f8: cap 84: finished GC 2570: cap 32: finished GC 270: cap 9: finished GC 270: giving up capability 9 270: freeing capability 9 454: cap 13: finished GC 1eb4: cap 26: finished GC 1eb4: giving up capability 26 1eb4: freeing capability 26 1d40: cap 1: running thread 4 (ThreadRunGHC) 18b0: cap 36: finished GC 221c: cap 65: finished GC 1ebc: cap 53: finished GC 1ebc: giving up capability 53 1ebc: freeing capability 53 2444: cap 87: finished GC 2444: cap 87: message: try wakeup thread 3 2444: cap 87: waking up thread 3 on cap 87 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (yielding) 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (blocked on an MVar) thread 3 @ 1a28: cap 77: finished GC 0000000 1a28: giving up capability 77 035c92028 is blocked on an MVar @ 0000000035b08000 (TSO_DIRTY) 1a28: freeing capability 77 1a38: cap 71: finished GC 1a38: giving up capability 71 1a38: freeing capability 71 2210: cap 8: finished GC 2210: giving up capability 8 2210: freeing capability 8 25f8: cap 5: finished GC 25f8: giving up capability 5 25f8: freeing capability 5 418: cap 54: finished GC 418: giving up capability 54 418: freeing capability 54 418: woken up on capability 54 418: resuming capability 54 418: giving up capability 54 418: freeing capability 54 2180: cap 64: finished GC 2180: giving up capability 64 2180: freeing capability 64 1fac: cap 46: finished GC 1fac: giving up capability 46 1fac: freeing capability 46 1fac: woken up on capability 46 1fac: resuming capability 46 1fac: giving up capability 46 1fac: freeing capability 46 bd4: cap 37: finished GC bd4: giving up capability 37 bd4: freeing capability 37 188c: cap 68: finished GC 188c: giving up capability 68 188c: freeing capability 68 1254: cap 82: finished GC 1b60: cap 66: finished GC 1b60: giving up capability 66 1b60: freeing capability 66 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: giving up capability 66 1b60: freeing capability 66 1eb8: cap 51: finished GC 1eb8: giving up capability 51 1eb8: freeing capability 51 1eb8: woken up on capability 51 1eb8: resuming capability 51 1eb8: giving up capability 51 1eb8: freeing capability 51 2340: cap 67: finished GC 2340: giving up capability 67 2340: freeing capability 67 2340: woken up on capability 67 2340: resuming capability 67 2340: giving up capability 67 2340: freeing capability 67 8cc: cap 62: finished GC 8cc: giving up capability 62 8cc: freeing capability 62 8cc: woken up on capability 62 8cc: resuming capability 62 8cc: giving up capability 62 8cc: freeing capability 62 610: giving up capability 52 610: freeing capability 52 610: woken up on capability 52 610: resuming capability 52 610: giving up capability 52 610: freeing capability 52 454: giving up capability 13 454: freeing capability 13 1be4: cap 85: finished GC 1be4: giving up capability 85 1be4: freeing capability 85 1be4: woken up on capability 85 1be4: resuming capability 85 1be4: giving up capability 85 1be4: freeing capability 85 58c: cap 34: finished GC 1aa8: cap 12: finished GC 1aa8: giving up capability 12 1aa8: freeing capability 12 94c: cap 29: finished GC 94c: giving up capability 29 94c: freeing capability 29 2444: giving up capability 87 2444: freeing capability 87 1510: cap 21: finished GC 1510: giving up capability 21 1510: freeing capability 21 229c: cap 23: finished GC 229c: deadlocked, forcing major GC... 229c: cap 23: requesting parallel GC 229c: 0 idle caps 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 229c: passing capability 5 to worker 0x25f8 229c: passing capability 8 to worker 0x2210 229c: passing capability 9 to worker 0x270 229c: passing capability 12 to worker 0x1aa8 229c: passing capability 13 to worker 0x454 229c: passing capability 21 to worker 0x1510 229c: passing capability 26 to worker 0x1eb4 229c: passing capability 29 to worker 0x94c 229c: passing capability 37 to worker 0xbd4 229c: passing capability 46 to worker 0x1fac 229c: passing capability 51 to worker 0x1eb8 229c: passing capability 52 to worker 0x610 229c: passing capability 53 to worker 0x1ebc 229c: passing capability 54 to worker 0x418 229c: passing capability 62 to worker 0x8cc 229c: passing capability 64 to worker 0x2180 229c: passing capability 66 to worker 0x1b60 229c: passing capability 67 to worker 0x2340 229c: passing capability 68 to worker 0x188c 229c: passing capability 71 to worker 0x1a38 229c: passing capability 77 to worker 0x1a28 229c: passing capability 85 to worker 0x1be4 229c: passing capability 87 to worker 0x11b4 1aa8: woken up on capability 12 1aa8: resuming capability 12 1aa8: cap 12: starting GC 1908: cap 48: finished GC 1510: woken up on capability 21 1510: resuming capability 21 1510: cap 21: starting GC 1eb4: woken up on capability 26 1eb4: resuming capability 26 1eb4: cap 26: starting GC bd4: woken up on capability 37 bd4: resuming capability 37 bd4: cap 37: starting GC 1fac: woken up on capability 46 1fac: resuming capability 46 1fac: cap 46: starting GC 610: woken up on capability 52 610: resuming capability 52 610: cap 52: starting GC 2404: cap 73: finished GC 2404: deadlocked, forcing major GC... 2404: someone else is trying to sync (2)... 2404: cap 73: starting GC 8cc: woken up on capability 62 8cc: resuming capability 62 8cc: cap 62: starting GC a04: cap 56: finished GC a04: deadlocked, forcing major GC... 85c: cap 16: finished GC 85c: deadlocked, forcing major GC... 85c: someone else is trying to sync (2)... 85c: cap 16: starting GC 188c: woken up on capability 68 188c: resuming capability 68 188c: cap 68: starting GC 1a38: woken up on capability 71 1a38: resuming capability 71 1a38: cap 71: starting GC 1944: cap 61: finished GC 1be4: woken up on capability 85 1be4: resuming capability 85 1be4: cap 85: starting GC 18e0: cap 44: finished GC 9b8: cap 17: finished GC 2108: cap 63: finished GC 2108: deadlocked, forcing major GC... 2108: someone else is trying to sync (2)... 2108: cap 63: starting GC 2600: cap 3: finished GC 2600: deadlocked, forcing major GC... 1c2c: cap 79: finished GC 1c2c: deadlocked, forcing major GC... 1c2c: someone else is trying to sync (2)... 1c2c: cap 79: starting GC 2720: cap 14: finished GC 2720: deadlocked, forcing major GC... 2720: someone else is trying to sync (2)... 2720: cap 14: starting GC 212c: giving up capability 25 212c: passing capability 25 to worker 0x212c 212c: woken up on capability 25 212c: resuming capability 25 212c: cap 25: starting GC 1fd0: cap 45: finished GC 2454: cap 70: finished GC 2454: deadlocked, forcing major GC... 18b0: giving up capability 36 18b0: passing capability 36 to worker 0x18b0 18b0: woken up on capability 36 18b0: resuming capability 36 18b0: cap 36: starting GC 58c: giving up capability 34 58c: passing capability 34 to worker 0x58c 58c: woken up on capability 34 58c: resuming capability 34 58c: cap 34: starting GC 6c8: cap 10: finished GC 6c8: deadlocked, forcing major GC... 15e8: cap 15: finished GC 15e8: deadlocked, forcing major GC... 15e8: someone else is trying to sync (2)... 15e8: cap 15: starting GC 1ac0: cap 43: finished GC 25f8: woken up on capability 5 2574: cap 33: finished GC 166c: cap 2: finished GC 166c: deadlocked, forcing major GC... 11bc: cap 35: finished GC 11bc: deadlocked, forcing major GC... 11bc: someone else is trying to sync (2)... 11bc: cap 35: starting GC 454: woken up on capability 13 454: resuming capability 13 454: cap 13: starting GC 2424: cap 75: finished GC 2424: deadlocked, forcing major GC... 2424: someone else is trying to sync (2)... 2424: cap 75: starting GC 1564: cap 55: finished GC 1564: deadlocked, forcing major GC... 1564: someone else is trying to sync (2)... 1564: cap 55: starting GC 1ebc: woken up on capability 53 1ebc: resuming capability 53 1ebc: cap 53: starting GC b98: cap 39: finished GC b98: deadlocked, forcing major GC... b98: someone else is trying to sync (2)... b98: cap 39: starting GC a04: someone else is trying to sync (2)... a04: cap 56: starting GC 1590: cap 38: finished GC 25fc: cap 4: finished GC 1a9c: cap 27: finished GC 1a9c: deadlocked, forcing major GC... 1a9c: someone else is trying to sync (2)... 1a9c: cap 27: starting GC 140c: cap 57: finished GC 11b4: woken up on capability 87 11b4: resuming capability 87 11b4: cap 87: starting GC 14b8: cap 60: finished GC 14b8: deadlocked, forcing major GC... 8a8: cap 78: finished GC 1838: cap 41: finished GC 2600: someone else is trying to sync (2)... 2600: cap 3: starting GC 11e8: cap 47: finished GC 11e8: deadlocked, forcing major GC... 11e8: someone else is trying to sync (2)... 11e8: cap 47: starting GC 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 17f8: giving up capability 84 17f8: passing capability 84 to worker 0x17f8 17f8: woken up on capability 84 17f8: resuming capability 84 17f8: cap 84: starting GC 2454: someone else is trying to sync (2)... 2454: cap 70: starting GC 24e0: cap 30: finished GC 1244: cap 20: finished GC 1244: deadlocked, forcing major GC... 1244: someone else is trying to sync (2)... 1244: cap 20: starting GC 25f4: cap 7: finished GC 2178: cap 24: finished GC 1848: cap 22: finished GC 1848: deadlocked, forcing major GC... 1848: someone else is trying to sync (2)... 1848: cap 22: starting GC 1534: cap 81: finished GC 1534: deadlocked, forcing major GC... 2574: deadlocked, forcing major GC... 2574: someone else is trying to sync (2)... 2574: cap 33: starting GC 270: woken up on capability 9 270: resuming capability 9 270: cap 9: starting GC 1908: deadlocked, forcing major GC... 1908: someone else is trying to sync (2)... 1908: cap 48: starting GC 94c: woken up on capability 29 94c: resuming capability 29 94c: cap 29: starting GC 24dc: cap 40: finished GC 240c: cap 86: finished GC 240c: deadlocked, forcing major GC... 240c: someone else is trying to sync (2)... 240c: cap 86: starting GC 2180: woken up on capability 64 2180: resuming capability 64 2180: cap 64: starting GC 1590: deadlocked, forcing major GC... 25fc: deadlocked, forcing major GC... 25fc: someone else is trying to sync (2)... 25fc: cap 4: starting GC 140c: deadlocked, forcing major GC... 140c: someone else is trying to sync (2)... 140c: cap 57: starting GC 12b8: cap 50: finished GC 12b8: deadlocked, forcing major GC... 8a8: deadlocked, forcing major GC... 8a8: someone else is trying to sync (2)... 8a8: cap 78: starting GC 1ef0: cap 76: finished GC 1768: cap 31: finished GC 1768: deadlocked, forcing major GC... 1768: someone else is trying to sync (2)... 1768: cap 31: starting GC 2570: giving up capability 32 2570: passing capability 32 to worker 0x2570 2570: woken up on capability 32 2570: resuming capability 32 2570: cap 32: starting GC 24e0: deadlocked, forcing major GC... 24e0: someone else is trying to sync (2)... 24e0: cap 30: starting GC 1d50: cap 69: finished GC 25f4: deadlocked, forcing major GC... 25f4: someone else is trying to sync (2)... 25f4: cap 7: starting GC 1ec0: cap 49: finished GC 1ec0: deadlocked, forcing major GC... 1ec0: someone else is trying to sync (2)... 1ec0: cap 49: starting GC 2210: woken up on capability 8 2210: resuming capability 8 2210: cap 8: starting GC 1b30: cap 58: finished GC 1860: cap 28: finished GC 1860: deadlocked, forcing major GC... 1860: someone else is trying to sync (2)... 1860: cap 28: starting GC 24dc: deadlocked, forcing major GC... 1be8: cap 80: finished GC 418: woken up on capability 54 418: resuming capability 54 418: cap 54: starting GC 2340: woken up on capability 67 2340: resuming capability 67 2340: cap 67: starting GC 1944: deadlocked, forcing major GC... 1944: someone else is trying to sync (2)... 1944: cap 61: starting GC 14b8: someone else is trying to sync (2)... 14b8: cap 60: starting GC 1838: deadlocked, forcing major GC... 1838: someone else is trying to sync (2)... 1838: cap 41: starting GC 948: cap 83: finished GC 25f0: giving up capability 6 25f0: passing capability 6 to worker 0x25f0 25f0: woken up on capability 6 25f0: resuming capability 6 25f0: cap 6: starting GC 221c: giving up capability 65 221c: passing capability 65 to worker 0x221c 221c: woken up on capability 65 221c: resuming capability 65 221c: cap 65: starting GC 6c8: someone else is trying to sync (2)... 6c8: cap 10: starting GC 1ac0: deadlocked, forcing major GC... 1534: someone else is trying to sync (2)... 1534: cap 81: starting GC 229c: passing capability 5 to worker 0x25f8 25f8: resuming capability 5 25f8: cap 5: starting GC 7e0: cap 72: finished GC 7e0: deadlocked, forcing major GC... 24dc: someone else is trying to sync (2)... 24dc: cap 40: starting GC 1254: giving up capability 82 1254: passing capability 82 to worker 0x1254 1254: woken up on capability 82 1254: resuming capability 82 1254: cap 82: starting GC 9b8: deadlocked, forcing major GC... 9b8: someone else is trying to sync (2)... 9b8: cap 17: starting GC 1ef0: deadlocked, forcing major GC... 1ef0: someone else is trying to sync (2)... 1ef0: cap 76: starting GC 2428: cap 74: finished GC 1fd0: deadlocked, forcing major GC... 1d40: cap 1: thread 4 stopped (yielding) 1d40: cap 1: starting GC 464: cap 18: finished GC 1d50: deadlocked, forcing major GC... 2178: deadlocked, forcing major GC... 2178: someone else is trying to sync (2)... 2178: cap 24: starting GC 166c: someone else is trying to sync (2)... 166c: cap 2: starting GC 1b30: deadlocked, forcing major GC... 480: cap 42: finished GC 480: deadlocked, forcing major GC... 480: someone else is trying to sync (2)... 480: cap 42: starting GC 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: cap 66: starting GC 18e0: deadlocked, forcing major GC... 12b8: someone else is trying to sync (2)... 12b8: cap 50: starting GC 948: deadlocked, forcing major GC... 1de4: cap 0: waking up thread 3 on cap 87 1de4: cap 0: message: try wakeup thread 3 on cap 87 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: passing capability 0 to worker 0x1f58 1de4: returning; I want capability 0 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: passing capability 0 to worker 0x1f58 1de4: returning; I want capability 0 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1be8: deadlocked, forcing major GC... 1590: someone else is trying to sync (2)... 1590: cap 38: starting GC 18e0: someone else is trying to sync (2)... 18e0: cap 44: starting GC 948: someone else is trying to sync (2)... 948: cap 83: starting GC 1fd0: someone else is trying to sync (2)... 1fd0: cap 45: starting GC 1f58: woken up on capability 0 1f58: capability 0 is owned by another task 1f58: woken up on capability 0 1f58: capability 0 is owned by another task 1f58: woken up on capability 0 1f58: capability 0 is owned by another task 1b30: someone else is trying to sync (2)... 1b30: cap 58: starting GC 7e0: someone else is trying to sync (2)... 7e0: cap 72: starting GC 1be8: someone else is trying to sync (2)... 1be8: cap 80: starting GC 17b8: cap 11: finished GC 17b8: deadlocked, forcing major GC... 17b8: someone else is trying to sync (2)... 17b8: cap 11: starting GC 1d50: someone else is trying to sync (2)... 1d50: cap 69: starting GC 1ac0: someone else is trying to sync (2)... 1ac0: cap 43: starting GC 1eb8: woken up on capability 51 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: passing capability 0 to worker 0x1f58 1f58: woken up on capability 0 1f58: resuming capability 0 1f58: cap 0: starting GC 1a34: cap 59: finished GC 229c: passing capability 51 to worker 0x1eb8 1a28: woken up on capability 77 2428: deadlocked, forcing major GC... 2428: someone else is trying to sync (2)... 2428: cap 74: starting GC 1a34: deadlocked, forcing major GC... 1a34: someone else is trying to sync (2)... 1a34: cap 59: starting GC 13a8: cap 19: finished GC 464: deadlocked, forcing major GC... 229c: passing capability 77 to worker 0x1a28 1eb8: resuming capability 51 1eb8: cap 51: starting GC 464: someone else is trying to sync (2)... 464: cap 18: starting GC 13a8: deadlocked, forcing major GC... 1a28: resuming capability 77 1a28: cap 77: starting GC 13a8: someone else is trying to sync (2)... 13a8: cap 19: starting GC all threads: threads on capability 0: threads on capability 1: thread 4 @ 0000000035ba5000 is not blocked (TSO_DIRTY) threads on capability 2: threads on capability 3: threads on capability 4: threads on capability 5: threads on capability 6: threads on capability 7: threads on capability 8: threads on capability 9: threads on capability 10: threads on capability 11: threads on capability 12: threads on capability 13: threads on capability 14: threads on capability 15: threads on capability 16: threads on capability 17: threads on capability 18: threads on capability 19: threads on capability 20: threads on capability 21: threads on capability 22: threads on capability 23: threads on capability 24: threads on capability 25: threads on capability 26: threads on capability 27: threads on capability 28: threads on capability 29: threads on capability 30: threads on capability 31: threads on capability 32: threads on capability 33: threads on capability 34: threads on capability 35: threads on capability 36: threads on capability 37: threads on capability 38: threads on capability 39: threads on capability 40: threads on capability 41: threads on capability 42: threads on capability 43: threads on capability 44: threads on capability 45: threads on capability 46: threads on capability 47: threads on capability 48: threads on capability 49: threads on capability 50: threads on capability 51: threads on capability 52: threads on capability 53: threads on capability 54: threads on capability 55: threads on capability 56: threads on capability 57: threads on capability 58: threads on capability 59: threads on capability 60: threads on capability 61: threads on capability 62: threads on capability 63: threads on capability 64: threads on capability 65: threads on capability 66: threads on capability 67: threads on capability 68: threads on capability 69: threads on capability 70: threads on capability 71: threads on capability 72: threads on capability 73: threads on capability 74: threads on capability 75: threads on capability 76: threads on capability 77: threads on capability 78: threads on capability 79: threads on capability 80: threads on capability 81: threads on capability 82: threads on capability 83: threads on capability 84: threads on capability 85: threads on capability 86: threads on capability 87: other threads: thread 2 @ 0000000035ba7000 is blocked on an external call (TSO_DIRTY) thread 3 @ 0000000035c92028 is blocked on an MVar @ 0000000035b08000 (TSO_DIRTY) thread 5 @ 0000000035ba5340 is blocked on a black hole 0000000035ba5228 thread 6 @ 0000000035bfd8c8 is blocked on a black hole 0000000035ba5228 thread 7 @ 0000000035bfd820 is blocked on a black hole 0000000035ba5228 thread 8 @ 0000000035ba5d08 is blocked on a black hole 0000000035ba5228 thread 9 @ 0000000035bca000 is blocked on a black hole 0000000035ba5228 thread 10 @ 0000000035bfdcc8 is blocked on a black hole 0000000035ba5228 thread 11 @ 0000000035ba58a0 is blocked on a black hole 0000000035ba5228 thread 12 @ 0000000035ba5460 is blocked on a black hole 0000000035ba5228 229c: cap 23: starting GC 1f58: cap 0: GC working 1ec0: cap 49: GC working 2570: cap 32: GC working 18b0: cap 36: GC working 2340: cap 67: GC working 58c: cap 34: GC working 454: cap 13: GC working 1a38: cap 71: GC working 1eb8: cap 51: GC working 1590: cap 38: GC working 2428: cap 74: GC working 25fc: cap 4: GC working 1534: cap 81: GC working 480: cap 42: GC working 1908: cap 48: GC working 11bc: cap 35: GC working 229c: cap 23: GC working 17b8: cap 11: GC working 25f0: cap 6: GC working 14b8: cap 60: GC working 2424: cap 75: GC working 2424: cap 75: GC idle 1564: cap 55: GC working 1564: cap 55: GC idle 1254: cap 82: GC working 1254: cap 82: GC idle 1860: cap 28: GC working 1860: cap 28: GC idle 85c: cap 16: GC working 85c: cap 16: GC idle 418: cap 54: GC working 12b8: cap 50: GC working 9b8: cap 17: GC working 9b8: cap 17: GC idle 2454: cap 70: GC working 2454: cap 70: GC idle 240c: cap 86: GC working 948: cap 83: GC working 948: cap 83: GC idle 1a28: cap 77: GC working 1a28: cap 77: GC idle 1768: cap 31: GC working 1768: cap 31: GC idle 2720: cap 14: GC working 2720: cap 14: GC idle 1eb4: cap 26: GC working 1eb4: cap 26: GC idle 1ef0: cap 76: GC working 1ef0: cap 76: GC idle 7e0: cap 72: GC working 1a9c: cap 27: GC working 1a9c: cap 27: GC idle 18e0: cap 44: GC working 18e0: cap 44: GC idle 25f8: cap 5: GC working 25f8: cap 5: GC idle 2404: cap 73: GC working 2404: cap 73: GC idle 221c: cap 65: GC working 221c: cap 65: GC idle 94c: cap 29: GC working 94c: cap 29: GC idle 1c2c: cap 79: GC working 1c2c: cap 79: GC idle 166c: cap 2: GC working 2180: cap 64: GC working 15e8: cap 15: GC working 11b4: cap 87: GC working 212c: cap 25: GC working 212c: cap 25: GC idle 13a8: cap 19: GC working 13a8: cap 19: GC idle a04: cap 56: GC working 1aa8: cap 12: GC working 1fd0: cap 45: GC working 24e0: cap 30: GC working 24e0: cap 30: GC idle 188c: cap 68: GC working 188c: cap 68: GC idle 464: cap 18: GC working 11e8: cap 47: GC working 11e8: cap 47: GC idle 610: cap 52: GC working 1fac: cap 46: GC working 1fac: cap 46: GC idle 8a8: cap 78: GC working 8a8: cap 78: GC idle 17f8: cap 84: GC working 17f8: cap 84: GC idle 1ec0: cap 49: GC idle 2570: cap 32: GC idle 18b0: cap 36: GC idle 2340: cap 67: GC idle 58c: cap 34: GC idle 454: cap 13: GC idle 1a38: cap 71: GC idle 1eb8: cap 51: GC idle 1590: cap 38: GC idle 2428: cap 74: GC idle 25fc: cap 4: GC idle 1534: cap 81: GC idle 480: cap 42: GC idle 1908: cap 48: GC idle 11bc: cap 35: GC idle 229c: cap 23: GC idle 17b8: cap 11: GC idle 25f0: cap 6: GC idle 14b8: cap 60: GC idle 25f4: cap 7: GC working 1ac0: cap 43: GC working 6c8: cap 10: GC working 6c8: cap 10: GC idle 1be4: cap 85: GC working 418: cap 54: GC idle 12b8: cap 50: GC idle 2210: cap 8: GC working 2574: cap 33: GC working 240c: cap 86: GC idle bd4: cap 37: GC working 1b60: cap 66: GC working 1510: cap 21: GC working 1ebc: cap 53: GC working 1d50: cap 69: GC working 2108: cap 63: GC working 7e0: cap 72: GC idle 1838: cap 41: GC working 1be8: cap 80: GC working 2600: cap 3: GC working 2600: cap 3: GC idle 2178: cap 24: GC working 1d40: cap 1: GC working 212c: cap 25: GC working 6c8: cap 10: GC working 1944: cap 61: GC working 85c: cap 16: GC working 25f0: cap 6: GC working 1f58: cap 0: GC idle 229c: cap 23: GC working 25f4: cap 7: GC idle 11e8: cap 47: GC working 1ac0: cap 43: GC idle 1848: cap 22: GC working 1be8: cap 80: GC idle 1d50: cap 69: GC idle 1908: cap 48: GC working 1a9c: cap 27: GC working 1590: cap 38: GC working 94c: cap 29: GC working 1be4: cap 85: GC idle 610: cap 52: GC idle 270: cap 9: GC working 270: cap 9: GC idle 17b8: cap 11: GC working 17b8: cap 11: GC idle 1510: cap 21: GC idle a04: cap 56: GC idle 1768: cap 31: GC working 1768: cap 31: GC idle 2428: cap 74: GC working 2428: cap 74: GC idle 2178: cap 24: GC idle 17f8: cap 84: GC working 17f8: cap 84: GC idle 8a8: cap 78: GC working 1ebc: cap 53: GC idle 1860: cap 28: GC working 480: cap 42: GC working 480: cap 42: GC idle bd4: cap 37: GC idle 11b4: cap 87: GC idle 1254: cap 82: GC working 25f8: cap 5: GC working 25f8: cap 5: GC idle 1564: cap 55: GC working 1564: cap 55: GC idle 24e0: cap 30: GC working 25fc: cap 4: GC working 24dc: cap 40: GC working 24dc: cap 40: GC idle 58c: cap 34: GC working 58c: cap 34: GC idle b98: cap 39: GC working b98: cap 39: GC idle 18e0: cap 44: GC working 1838: cap 41: GC idle 11bc: cap 35: GC working 11bc: cap 35: GC idle 1a28: cap 77: GC working 1ec0: cap 49: GC working 2600: cap 3: GC working 240c: cap 86: GC working 221c: cap 65: GC working 1534: cap 81: GC working 1534: cap 81: GC idle 1eb4: cap 26: GC working 418: cap 54: GC working 454: cap 13: GC working 454: cap 13: GC idle 2570: cap 32: GC working 2570: cap 32: GC idle 2720: cap 14: GC working 1aa8: cap 12: GC idle 14b8: cap 60: GC working 18b0: cap 36: GC working 15e8: cap 15: GC idle 2210: cap 8: GC idle 140c: cap 57: GC working 140c: cap 57: GC idle 1b30: cap 58: GC working 1b30: cap 58: GC idle 948: cap 83: GC working 2404: cap 73: GC working 1c2c: cap 79: GC working 188c: cap 68: GC working 188c: cap 68: GC idle 2454: cap 70: GC working 1d40: cap 1: GC idle 2574: cap 33: GC idle 1244: cap 20: GC working 212c: cap 25: GC idle 6c8: cap 10: GC idle 1944: cap 61: GC idle 85c: cap 16: GC idle 25f0: cap 6: GC idle 229c: cap 23: GC idle 11e8: cap 47: GC idle 1848: cap 22: GC idle 1908: cap 48: GC idle 1a9c: cap 27: GC idle 1590: cap 38: GC idle 94c: cap 29: GC idle 13a8: cap 19: GC working 13a8: cap 19: GC idle 8cc: cap 62: GC working 8cc: cap 62: GC idle 2424: cap 75: GC working 8a8: cap 78: GC idle 1860: cap 28: GC idle 2108: cap 63: GC idle 1254: cap 82: GC idle 464: cap 18: GC idle 12b8: cap 50: GC working 12b8: cap 50: GC idle 25fc: cap 4: GC idle 9b8: cap 17: GC working 166c: cap 2: GC idle 1fac: cap 46: GC working 1fac: cap 46: GC idle 1fd0: cap 45: GC idle 1a28: cap 77: GC idle 1ec0: cap 49: GC idle 2600: cap 3: GC idle 240c: cap 86: GC idle 221c: cap 65: GC idle 2180: cap 64: GC idle 1eb4: cap 26: GC idle 418: cap 54: GC idle 2340: cap 67: GC working 1a34: cap 59: GC working 2720: cap 14: GC idle 14b8: cap 60: GC idle 18b0: cap 36: GC idle 7e0: cap 72: GC working 1eb8: cap 51: GC working 1eb8: cap 51: GC idle 2404: cap 73: GC idle 1c2c: cap 79: GC idle 1a38: cap 71: GC working 2454: cap 70: GC idle 1244: cap 20: GC idle 1b60: cap 66: GC idle 1ef0: cap 76: GC working 1ef0: cap 76: GC idle 1ef0: cap 76: GC done 1244: cap 20: GC done 1534: cap 81: GC done b98: cap 39: GC done 25f4: cap 7: GC done 221c: cap 65: GC done 1838: cap 41: GC done 1ebc: cap 53: GC done 1a38: cap 71: GC idle 1a38: cap 71: GC done 1be4: cap 85: GC done 2180: cap 64: GC done 58c: cap 34: GC done a04: cap 56: GC done 1be8: cap 80: GC done 2720: cap 14: GC done 2404: cap 73: GC done 24e0: cap 30: GC idle 24e0: cap 30: GC done 140c: cap 57: GC done 1fd0: cap 45: GC done 166c: cap 2: GC done 1aa8: cap 12: GC done 25fc: cap 4: GC done 2340: cap 67: GC idle 2340: cap 67: GC done 94c: cap 29: GC done 229c: cap 23: GC done 25f0: cap 6: GC done 11e8: cap 47: GC done 11bc: cap 35: GC done bd4: cap 37: GC done 2570: cap 32: GC done 1b60: cap 66: GC done 9b8: cap 17: GC idle 9b8: cap 17: GC done 480: cap 42: GC done 1eb4: cap 26: GC done 1d50: cap 69: GC done 454: cap 13: GC done 17b8: cap 11: GC done 1510: cap 21: GC done 6c8: cap 10: GC done 1ac0: cap 43: GC done 18b0: cap 36: GC done 1768: cap 31: GC done 24dc: cap 40: GC done 1860: cap 28: GC done 610: cap 52: GC done 2178: cap 24: GC done 212c: cap 25: GC done 17f8: cap 84: GC done 1a28: cap 77: GC done 8cc: cap 62: GC done 1848: cap 22: GC done 1d40: cap 1: GC done 13a8: cap 19: GC done 2454: cap 70: GC done 2210: cap 8: GC done 2574: cap 33: GC done 1a9c: cap 27: GC done 270: cap 9: GC done 1c2c: cap 79: GC done 1f58: cap 0: GC done 464: cap 18: GC done 8a8: cap 78: GC done 1944: cap 61: GC done 2424: cap 75: GC idle 2424: cap 75: GC done 1fac: cap 46: GC done 1eb8: cap 51: GC done 1254: cap 82: GC done 14b8: cap 60: GC done 2600: cap 3: GC done 12b8: cap 50: GC done 948: cap 83: GC idle 948: cap 83: GC done 418: cap 54: GC done 7e0: cap 72: GC idle 7e0: cap 72: GC done 240c: cap 86: GC done 2428: cap 74: GC done 188c: cap 68: GC done 18e0: cap 44: GC idle 18e0: cap 44: GC done 11b4: cap 87: GC done 85c: cap 16: GC done 1a34: cap 59: GC idle 1a34: cap 59: GC done 15e8: cap 15: GC done 1590: cap 38: GC done 229c: cap 23: GC idle 229c: cap 23: GC done 1ec0: cap 49: GC done 1b30: cap 58: GC done 2108: cap 63: GC done 1564: cap 55: GC done 1908: cap 48: GC done 25f8: cap 5: GC done 229c: cap 23: GC idle 229c: cap 23: GC done 229c: cap 23: all caps stopped for GC 229c: cap 23: finished GC 166c: cap 2: finished GC 166c: giving up capability 2 166c: freeing capability 2 2574: cap 33: finished GC 2574: giving up capability 33 2574: freeing capability 33 1a28: cap 77: finished GC 1ec0: cap 49: finished GC 1ec0: giving up capability 49 1ec0: freeing capability 49 1b60: cap 66: finished GC 11b4: cap 87: finished GC 11b4: cap 87: message: try wakeup thread 3 11b4: cap 87: waking up thread 3 on cap 87 11b4: giving up capability 87 11b4: passing capability 87 to bound task 0x2444 610: cap 52: finished GC 1564: cap 55: finished GC 1564: giving up capability 55 1564: freeing capability 55 1564: woken up on capability 55 1564: resuming capability 55 1564: giving up capability 55 1564: freeing capability 55 229c: giving up capability 23 229c: freeing capability 23 1b30: cap 58: finished GC 1b30: giving up capability 58 1b30: freeing capability 58 1b30: woken up on capability 58 1b30: resuming capability 58 1b30: giving up capability 58 1b30: freeing capability 58 18b0: cap 36: finished GC 18b0: giving up capability 36 18b0: freeing capability 36 18b0: woken up on capability 36 18b0: resuming capability 36 18b0: giving up capability 36 18b0: freeing capability 36 17b8: cap 11: finished GC 17b8: giving up capability 11 17b8: freeing capability 11 18e0: cap 44: finished GC 18e0: giving up capability 44 18e0: freeing capability 44 18e0: woken up on capability 44 18e0: resuming capability 44 18e0: giving up capability 44 18e0: freeing capability 44 15e8: cap 15: finished GC 15e8: giving up capability 15 15e8: freeing capability 15 140c: cap 57: finished GC 140c: giving up capability 57 140c: freeing capability 57 140c: woken up on capability 57 140c: resuming capability 57 140c: giving up capability 57 140c: freeing capability 57 14b8: cap 60: finished GC 14b8: giving up capability 60 14b8: freeing capability 60 14b8: woken up on capability 60 14b8: resuming capability 60 14b8: giving up capability 60 14b8: freeing capability 60 1ef0: cap 76: finished GC 1ef0: giving up capability 76 1ef0: freeing capability 76 1ef0: woken up on capability 76 1ef0: resuming capability 76 1ef0: giving up capability 76 1ef0: freeing capability 76 11e8: cap 47: finished GC 11e8: giving up capability 47 11e8: freeing capability 47 11e8: woken up on capability 47 11e8: resuming capability 47 11e8: giving up capability 47 11e8: freeing capability 47 58c: cap 34: finished GC 58c: giving up capability 34 58c: freeing capability 34 58c: woken up on capability 34 58c: resuming capability 34 58c: giving up capability 34 58c: freeing capability 34 1c2c: cap 79: finished GC 1c2c: giving up capability 79 1c2c: freeing capability 79 1848: cap 22: finished GC 1848: giving up capability 22 1848: freeing capability 22 a04: cap 56: finished GC a04: giving up capability 56 a04: freeing capability 56 a04: woken up on capability 56 a04: resuming capability 56 1aa8: cap 12: finished GC 1aa8: giving up capability 12 1aa8: freeing capability 12 1aa8: woken up on capability 12 1aa8: resuming capability 12 1aa8: giving up capability 12 1aa8: freeing capability 12 13a8: cap 19: finished GC 13a8: giving up capability 19 13a8: freeing capability 19 2180: cap 64: finished GC 2180: giving up capability 64 2180: freeing capability 64 2180: woken up on capability 64 2180: resuming capability 64 2180: giving up capability 64 2180: freeing capability 64 1908: cap 48: finished GC 1908: giving up capability 48 1908: freeing capability 48 1908: woken up on capability 48 1908: resuming capability 48 1908: giving up capability 48 1908: freeing capability 48 1eb8: cap 51: finished GC 1eb8: giving up capability 51 1eb8: freeing capability 51 1eb8: woken up on capability 51 1eb8: resuming capability 51 1eb8: giving up capability 51 1eb8: freeing capability 51 1f58: cap 0: finished GC 1f58: giving up capability 0 1f58: freeing capability 0 2454: cap 70: finished GC 2454: giving up capability 70 2454: freeing capability 70 2454: woken up on capability 70 2454: resuming capability 70 2454: giving up capability 70 2454: freeing capability 70 2178: cap 24: finished GC 2178: giving up capability 24 2178: freeing capability 24 188c: cap 68: finished GC 188c: giving up capability 68 188c: freeing capability 68 188c: woken up on capability 68 188c: resuming capability 68 188c: giving up capability 68 188c: freeing capability 68 1d40: cap 1: finished GC 1d40: cap 1: running thread 4 (ThreadRunGHC) 1d40: cap 1: thread 4 stopped (yielding) 1d40: cap 1: running thread 4 (ThreadRunGHC) 25f8: cap 5: finished GC 25f8: giving up capability 5 25f8: freeing capability 5 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: giving up capability 5 25f8: freeing capability 5 6c8: cap 10: finished GC 6c8: giving up capability 10 6c8: freeing capability 10 1a28: giving up capability 77 1a28: freeing capability 77 1a28: woken up on capability 77 1a28: resuming capability 77 1a28: giving up capability 77 1a28: freeing capability 77 a04: giving up capability 56 a04: freeing capability 56 2444: woken up on capability 87 2444: resuming capability 87 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (yielding) 2444: cap 87: running thread 3 (ThreadRunGHC) 2444: cap 87: thread 3 stopped (blocked on an MVar) thread 1eb4: cap 26: finished GC 1eb4: giving up capability 26 3 1eb4: freeing capability 26 1eb4: woken up on capability 26 1eb4: resuming capability 26 1eb4: giving up capability 26 1eb4: freeing capability 26 @ 1ebc: cap 53: finished GC 0 17f8: cap 84: finished GC 0 12b8: cap 50: finished GC 12b8: 0giving up capability 50 00 12b8: freeing capability 50 948: cap 83: finished GC 00035bfb00 948: giving up capability 83 0 948: freeing capability 83 2600: cap 3: finished GC is 2600: blocked on an MVar @ giving up capability 3 0000000035b08000 2600: freeing capability 3 (TS 2340: cap 67: fiO_DIRTY) nished GC 2340: giving up capability 67 2340: freeing capability 67 2340: woken up on capability 67 2340: resuming capability 67 2340: giving up capability 67 2340: freeing capability 67 1254: cap 82: finished GC 1254: giving up capability 82 1254: freeing capability 82 1254: woken up on capability 82 1254: resuming capability 82 1254: giving up capability 82 1254: freeing capability 82 8cc: cap 62: finished GC 8cc: giving up capability 62 8cc: freeing capability 62 8cc: woken up on capability 62 8cc: resuming capability 62 8cc: giving up capability 62 8cc: freeing capability 62 240c: cap 86: finished GC 240c: giving up capability 86 240c: freeing capability 86 240c: woken up on capability 86 240c: resuming capability 86 240c: giving up capability 86 240c: freeing capability 86 1510: cap 21: finished GC 1510: giving up capability 21 1510: freeing capability 21 1510: woken up on capability 21 1510: resuming capability 21 1510: giving up capability 21 1510: freeing capability 21 610: giving up capability 52 610: freeing capability 52 610: woken up on capability 52 610: resuming capability 52 610: giving up capability 52 610: freeing capability 52 1244: cap 20: finished GC 1244: giving up capability 20 1244: freeing capability 20 9b8: cap 17: finished GC 9b8: giving up capability 17 9b8: freeing capability 17 1ebc: giving up capability 53 1ebc: freeing capability 53 1ebc: woken up on capability 53 1ebc: resuming capability 53 454: cap 13: finished GC 454: giving up capability 13 454: freeing capability 13 454: woken up on capability 13 454: resuming capability 13 454: giving up capability 13 454: freeing capability 13 2720: cap 14: finished GC 2720: giving up capability 14 2720: freeing capability 14 1590: cap 38: finished GC 1590: giving up capability 38 1590: freeing capability 38 1838: cap 41: finished GC 1838: giving up capability 41 1838: freeing capability 41 212c: cap 25: finished GC 212c: giving up capability 25 212c: freeing capability 25 212c: woken up on capability 25 212c: resuming capability 25 212c: giving up capability 25 212c: freeing capability 25 2424: cap 75: finished GC 2424: giving up capability 75 2424: freeing capability 75 2424: woken up on capability 75 2424: resuming capability 75 2424: deadlocked, forcing major GC... 2424: cap 75: requesting parallel GC 2424: 0 idle caps 2424: passing capability 0 to worker 0x1f58 2424: passing capability 2 to worker 0x166c 2424: passing capability 3 to worker 0x2600 2424: passing capability 5 to worker 0x25f8 2424: passing capability 10 to worker 0x6c8 2424: passing capability 11 to worker 0x17b8 2424: passing capability 12 to worker 0x1aa8 2424: passing capability 13 to worker 0x454 2424: passing capability 14 to worker 0x2720 2424: passing capability 15 to worker 0x15e8 2424: passing capability 17 to worker 0x9b8 2424: passing capability 19 to worker 0x13a8 2424: passing capability 20 to worker 0x1244 2424: passing capability 21 to worker 0x1510 2424: passing capability 22 to worker 0x1848 2424: passing capability 23 to worker 0x229c 2424: passing capability 24 to worker 0x2178 2424: passing capability 25 to worker 0x212c 2424: passing capability 26 to worker 0x1eb4 2424: passing capability 33 to worker 0x2574 2424: passing capability 34 to worker 0x58c 2424: passing capability 36 to worker 0x18b0 2424: passing capability 38 to worker 0x1590 2424: passing capability 41 to worker 0x1838 2424: passing capability 44 to worker 0x18e0 2424: passing capability 47 to worker 0x11e8 2424: passing capability 48 to worker 0x1908 2424: passing capability 49 to worker 0x1ec0 2424: passing capability 50 to worker 0x12b8 2424: passing capability 51 to worker 0x1eb8 2424: passing capability 52 to worker 0x610 2424: passing capability 55 to worker 0x1564 2424: passing capability 56 to worker 0xa04 2424: passing capability 57 to worker 0x140c 2424: passing capability 58 to worker 0x1b30 1860: cap 28: finished GC 1860: someone else is trying to sync (2)... 1860: cap 28: starting GC 25f4: cap 7: finished GC 25f4: someone else is trying to sync (2)... 25f4: cap 7: starting GC 1b60: giving up capability 66 1b60: passing capability 66 to worker 0x1b60 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: cap 66: starting GC 166c: woken up on capability 2 166c: resuming capability 2 166c: cap 2: starting GC 221c: cap 65: finished GC 221c: deadlocked, forcing major GC... 221c: someone else is trying to sync (2)... 221c: cap 65: starting GC 2108: cap 63: finished GC 2108: someone else is trying to sync (2)... 2108: cap 63: starting GC 1de4: returning; I want capability 0 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1de4: cap 0: waking up thread 3 on cap 87 1de4: cap 0: message: try wakeup thread 3 on cap 87 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: passing capability 0 to worker 0x1f58 1de4: returning; I want capability 0 1de4: resuming capability 0 1de4: cap 0: running thread 2 (ThreadRunGHC) 1de4: cap 0: thread 2 stopped (suspended while making a foreign call) 1de4: passing capability 0 to worker 0x1f58 17f8: giving up capability 84 17f8: passing capability 84 to worker 0x17f8 17f8: woken up on capability 84 17f8: resuming capability 84 17f8: cap 84: starting GC 1ebc: giving up capability 53 1ebc: passing capability 53 to worker 0x1ebc 1ebc: woken up on capability 53 1ebc: resuming capability 53 1ebc: cap 53: starting GC 2210: cap 8: finished GC 2210: deadlocked, forcing major GC... 2210: someone else is trying to sync (2)... 2210: cap 8: starting GC 2574: woken up on capability 33 2574: resuming capability 33 2574: cap 33: starting GC 8a8: cap 78: finished GC 8a8: someone else is trying to sync (2)... 8a8: cap 78: starting GC 1590: woken up on capability 38 1590: resuming capability 38 1590: cap 38: starting GC 1fac: cap 46: finished GC 1fac: deadlocked, forcing major GC... 1fac: someone else is trying to sync (2)... 1fac: cap 46: starting GC 1a38: cap 71: finished GC 1a38: deadlocked, forcing major GC... 1a38: someone else is trying to sync (2)... 1a38: cap 71: starting GC 25f0: cap 6: finished GC 25f0: deadlocked, forcing major GC... 25f0: someone else is trying to sync (2)... 25f0: cap 6: starting GC 1534: cap 81: finished GC 1534: someone else is trying to sync (2)... 1534: cap 81: starting GC 1d50: cap 69: finished GC 1d50: someone else is trying to sync (2)... 1d50: cap 69: starting GC 7e0: cap 72: finished GC 7e0: someone else is trying to sync (2)... 7e0: cap 72: starting GC 2424: passing capability 60 to worker 0x14b8 2424: passing capability 62 to worker 0x8cc 2424: passing capability 64 to worker 0x2180 2424: passing capability 67 to worker 0x2340 270: cap 9: finished GC 270: deadlocked, forcing major GC... b98: cap 39: finished GC b98: someone else is trying to sync (2)... b98: cap 39: starting GC 24dc: cap 40: finished GC 24dc: someone else is trying to sync (2)... 24dc: cap 40: starting GC 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: cap 5: starting GC 17b8: woken up on capability 11 17b8: resuming capability 11 17b8: cap 11: starting GC 1be4: cap 85: finished GC 2720: woken up on capability 14 2720: resuming capability 14 2720: cap 14: starting GC 1a9c: cap 27: finished GC 1a9c: someone else is trying to sync (2)... 1a9c: cap 27: starting GC 94c: cap 29: finished GC 94c: deadlocked, forcing major GC... 94c: someone else is trying to sync (2)... 94c: cap 29: starting GC 1510: woken up on capability 21 1510: resuming capability 21 1510: cap 21: starting GC 229c: woken up on capability 23 229c: resuming capability 23 229c: cap 23: starting GC 212c: woken up on capability 25 212c: resuming capability 25 212c: cap 25: starting GC 2444: giving up capability 87 2444: passing capability 87 to worker 0x11b4 58c: woken up on capability 34 58c: resuming capability 34 58c: cap 34: starting GC 1ac0: cap 43: finished GC 1ac0: someone else is trying to sync (2)... 1ac0: cap 43: starting GC 2428: cap 74: finished GC 2428: someone else is trying to sync (2)... 2428: cap 74: starting GC 464: cap 18: finished GC 464: someone else is trying to sync (2)... 464: cap 18: starting GC 1eb8: woken up on capability 51 1eb8: resuming capability 51 1eb8: cap 51: starting GC 1564: woken up on capability 55 1564: resuming capability 55 1564: cap 55: starting GC 1d40: cap 1: thread 4 stopped (heap overflow) 1d40: someone else is trying to sync (2)... 1d40: cap 1: starting GC 8cc: woken up on capability 62 8cc: resuming capability 62 8cc: cap 62: starting GC 24e0: cap 30: finished GC 24e0: someone else is trying to sync (2)... 24e0: cap 30: starting GC 418: cap 54: finished GC 270: someone else is trying to sync (2)... 270: cap 9: starting GC 1f58: woken up on capability 0 1f58: resuming capability 0 1f58: cap 0: starting GC 6c8: woken up on capability 10 6c8: resuming capability 10 6c8: cap 10: starting GC 454: woken up on capability 13 454: resuming capability 13 454: cap 13: starting GC 15e8: woken up on capability 15 15e8: resuming capability 15 15e8: cap 15: starting GC 13a8: woken up on capability 19 13a8: resuming capability 19 13a8: cap 19: starting GC 1be8: cap 80: finished GC 1be8: someone else is trying to sync (2)... 1be8: cap 80: starting GC 2178: woken up on capability 24 2178: resuming capability 24 2178: cap 24: starting GC 25fc: cap 4: finished GC 25fc: someone else is trying to sync (2)... 25fc: cap 4: starting GC 1838: woken up on capability 41 1838: resuming capability 41 1838: cap 41: starting GC 1908: woken up on capability 48 1908: resuming capability 48 1908: cap 48: starting GC 1944: cap 61: finished GC 1944: someone else is trying to sync (2)... 1944: cap 61: starting GC 140c: woken up on capability 57 140c: resuming capability 57 140c: cap 57: starting GC 1fd0: cap 45: finished GC 1fd0: someone else is trying to sync (2)... 1fd0: cap 45: starting GC 2424: passing capability 68 to worker 0x188c 2424: passing capability 70 to worker 0x2454 2570: cap 32: finished GC 2424: passing capability 76 to worker 0x1ef0 418: deadlocked, forcing major GC... 188c: woken up on capability 68 188c: resuming capability 68 188c: cap 68: starting GC 14b8: woken up on capability 60 14b8: resuming capability 60 14b8: cap 60: starting GC 1ec0: woken up on capability 49 1ec0: resuming capability 49 1ec0: cap 49: starting GC 18e0: woken up on capability 44 18e0: resuming capability 44 18e0: cap 44: starting GC 480: cap 42: finished GC 480: someone else is trying to sync (2)... 480: cap 42: starting GC 1244: woken up on capability 20 1244: resuming capability 20 1244: cap 20: starting GC 1be4: deadlocked, forcing major GC... 1be4: someone else is trying to sync (2)... 1be4: cap 85: starting GC 1aa8: woken up on capability 12 1aa8: resuming capability 12 1aa8: cap 12: starting GC 2404: cap 73: finished GC 2404: someone else is trying to sync (2)... 2404: cap 73: starting GC 2600: woken up on capability 3 2600: resuming capability 3 2600: cap 3: starting GC 1ef0: woken up on capability 76 1ef0: resuming capability 76 1ef0: cap 76: starting GC 2180: woken up on capability 64 2180: resuming capability 64 2180: cap 64: starting GC 12b8: woken up on capability 50 12b8: resuming capability 50 12b8: cap 50: starting GC 1eb4: woken up on capability 26 1eb4: resuming capability 26 1eb4: cap 26: starting GC 85c: cap 16: finished GC 85c: someone else is trying to sync (2)... 85c: cap 16: starting GC 1768: cap 31: finished GC 1768: someone else is trying to sync (2)... 1768: cap 31: starting GC 1b30: woken up on capability 58 1b30: resuming capability 58 1b30: cap 58: starting GC 2424: passing capability 77 to worker 0x1a28 418: someone else is trying to sync (2)... 418: cap 54: starting GC 610: woken up on capability 52 610: resuming capability 52 610: cap 52: starting GC 18b0: woken up on capability 36 18b0: resuming capability 36 18b0: cap 36: starting GC bd4: cap 37: finished GC 9b8: woken up on capability 17 9b8: resuming capability 17 9b8: cap 17: starting GC 1a34: cap 59: finished GC 1a34: someone else is trying to sync (2)... 1a34: cap 59: starting GC 1a28: woken up on capability 77 1a28: resuming capability 77 1a28: cap 77: starting GC 11e8: woken up on capability 47 11e8: resuming capability 47 11e8: cap 47: starting GC bd4: deadlocked, forcing major GC... 11b4: woken up on capability 87 11b4: resuming capability 87 11b4: cap 87: starting GC 2424: passing capability 79 to worker 0x1c2c 2340: woken up on capability 67 2340: resuming capability 67 2340: cap 67: starting GC 11bc: cap 35: finished GC 11bc: someone else is trying to sync (2)... 11bc: cap 35: starting GC 2570: deadlocked, forcing major GC... 2570: someone else is trying to sync (2)... 2570: cap 32: starting GC a04: woken up on capability 56 a04: resuming capability 56 a04: cap 56: starting GC 2454: woken up on capability 70 2454: resuming capability 70 2454: cap 70: starting GC 1848: woken up on capability 22 1848: resuming capability 22 1848: cap 22: starting GC 1c2c: woken up on capability 79 1c2c: resuming capability 79 1c2c: cap 79: starting GC bd4: someone else is trying to sync (2)... bd4: cap 37: starting GC 2424: passing capability 82 to worker 0x1254 2424: passing capability 83 to worker 0x948 1254: woken up on capability 82 1254: resuming capability 82 1254: cap 82: starting GC 948: woken up on capability 83 948: resuming capability 83 948: cap 83: starting GC 2424: passing capability 86 to worker 0x240c 240c: woken up on capability 86 2424: passing capability 86 to worker 0x240c 240c: resuming capability 86 240c: cap 86: starting GC all threads: threads on capability 0: threads on capability 1: thread 4 @ 0000000035bfa000 is not blocked (TSO_DIRTY) threads on capability 2: threads on capability 3: threads on capability 4: threads on capability 5: threads on capability 6: threads on capability 7: threads on capability 8: threads on capability 9: threads on capability 10: threads on capability 11: threads on capability 12: threads on capability 13: threads on capability 14: threads on capability 15: threads on capability 16: threads on capability 17: threads on capability 18: threads on capability 19: threads on capability 20: threads on capability 21: threads on capability 22: threads on capability 23: threads on capability 24: threads on capability 25: threads on capability 26: threads on capability 27: threads on capability 28: threads on capability 29: threads on capability 30: threads on capability 31: threads on capability 32: threads on capability 33: threads on capability 34: threads on capability 35: threads on capability 36: threads on capability 37: threads on capability 38: threads on capability 39: threads on capability 40: threads on capability 41: threads on capability 42: threads on capability 43: threads on capability 44: threads on capability 45: threads on capability 46: threads on capability 47: threads on capability 48: threads on capability 49: threads on capability 50: threads on capability 51: threads on capability 52: threads on capability 53: threads on capability 54: threads on capability 55: threads on capability 56: threads on capability 57: threads on capability 58: threads on capability 59: threads on capability 60: threads on capability 61: threads on capability 62: threads on capability 63: threads on capability 64: threads on capability 65: threads on capability 66: threads on capability 67: threads on capability 68: threads on capability 69: threads on capability 70: threads on capability 71: threads on capability 72: threads on capability 73: threads on capability 74: threads on capability 75: threads on capability 76: threads on capability 77: threads on capability 78: threads on capability 79: threads on capability 80: threads on capability 81: threads on capability 82: threads on capability 83: threads on capability 84: threads on capability 85: threads on capability 86: threads on capability 87: other threads: thread 12 @ 0000000035bfa188 is blocked on a black hole 0000000035bfa0a0 thread 11 @ 0000000035ba8000 is blocked on a black hole 0000000035bfa0a0 thread 10 @ 0000000035bfaa90 is blocked on a black hole 0000000035bfa0a0 thread 9 @ 0000000035ba8ac0 is blocked on a black hole 0000000035bfa0a0 thread 8 @ 0000000035ba8a18 is blocked on a black hole 0000000035bfa0a0 thread 7 @ 0000000035ba8ee0 is blocked on a black hole 0000000035bfa0a0 thread 6 @ 0000000035bfa200 is blocked on a black hole 0000000035bfa0a0 thread 5 @ 0000000035bfa0f0 is blocked on a black hole 0000000035bfa0a0 thread 3 @ 0000000035bfb000 is blocked on an MVar @ 0000000035b08000 (TSO_DIRTY) thread 2 @ 0000000035bc9000 is blocked on an external call (TSO_DIRTY) 2424: cap 75: starting GC 1d40: cap 1: GC working 25f4: cap 7: GC working 1c2c: cap 79: GC working 18e0: cap 44: GC working 1a34: cap 59: GC working 25f0: cap 6: GC working 464: cap 18: GC working 2424: cap 75: GC working 1838: cap 41: GC working 25f8: cap 5: GC working 1ec0: cap 49: GC working 166c: cap 2: GC working 18b0: cap 36: GC working 1ac0: cap 43: GC working b98: cap 39: GC working 1d50: cap 69: GC working 25fc: cap 4: GC working 2600: cap 3: GC working 2428: cap 74: GC working 8cc: cap 62: GC working 212c: cap 25: GC working 9b8: cap 17: GC working 24e0: cap 30: GC working 1254: cap 82: GC working 1254: cap 82: GC idle 11b4: cap 87: GC working 418: cap 54: GC working 418: cap 54: GC idle bd4: cap 37: GC working bd4: cap 37: GC idle 94c: cap 29: GC working 94c: cap 29: GC idle 1534: cap 81: GC working 12b8: cap 50: GC working 12b8: cap 50: GC idle 480: cap 42: GC working 240c: cap 86: GC working 240c: cap 86: GC idle 229c: cap 23: GC working 229c: cap 23: GC idle 6c8: cap 10: GC working 6c8: cap 10: GC idle 2178: cap 24: GC working 2178: cap 24: GC idle 188c: cap 68: GC working 188c: cap 68: GC idle 1860: cap 28: GC working 1860: cap 28: GC idle 2340: cap 67: GC working 2210: cap 8: GC working 2210: cap 8: GC idle 2180: cap 64: GC working 2180: cap 64: GC idle 948: cap 83: GC working 948: cap 83: GC idle 1f58: cap 0: GC working 1f58: cap 0: GC idle 7e0: cap 72: GC working 7e0: cap 72: GC idle 1a28: cap 77: GC working 1a28: cap 77: GC idle 1eb8: cap 51: GC working 1eb8: cap 51: GC idle 13a8: cap 19: GC working 13a8: cap 19: GC idle 2574: cap 33: GC working 2574: cap 33: GC idle 2404: cap 73: GC working 2404: cap 73: GC idle 58c: cap 34: GC working 58c: cap 34: GC idle 2570: cap 32: GC working 2570: cap 32: GC idle 1564: cap 55: GC working 270: cap 9: GC working 270: cap 9: GC idle 17b8: cap 11: GC working 17b8: cap 11: GC idle 610: cap 52: GC working 610: cap 52: GC idle 1b60: cap 66: GC working 17f8: cap 84: GC working 17f8: cap 84: GC idle 2454: cap 70: GC working 1a38: cap 71: GC working 454: cap 13: GC working 24dc: cap 40: GC working 24dc: cap 40: GC idle 1aa8: cap 12: GC working 1d40: cap 1: GC idle 25f4: cap 7: GC idle 1c2c: cap 79: GC idle 18e0: cap 44: GC idle 1a34: cap 59: GC idle 25f0: cap 6: GC idle 464: cap 18: GC idle 2424: cap 75: GC idle 1838: cap 41: GC idle 25f8: cap 5: GC idle 1ec0: cap 49: GC idle 166c: cap 2: GC idle 18b0: cap 36: GC idle 1ac0: cap 43: GC idle b98: cap 39: GC idle 1d50: cap 69: GC idle 25fc: cap 4: GC idle 2600: cap 3: GC idle 2428: cap 74: GC idle 8cc: cap 62: GC idle 212c: cap 25: GC idle 9b8: cap 17: GC idle 24e0: cap 30: GC idle 1b30: cap 58: GC working 11b4: cap 87: GC idle 1848: cap 22: GC working 221c: cap 65: GC working 1534: cap 81: GC idle a04: cap 56: GC working 480: cap 42: GC idle 85c: cap 16: GC working 85c: cap 16: GC idle 1ef0: cap 76: GC working 1ef0: cap 76: GC idle 1ebc: cap 53: GC working 1fd0: cap 45: GC working 1fd0: cap 45: GC idle 1fac: cap 46: GC working 1be4: cap 85: GC working 1be4: cap 85: GC idle 1a9c: cap 27: GC working 11bc: cap 35: GC working 11e8: cap 47: GC working 15e8: cap 15: GC working 2108: cap 63: GC working 1244: cap 20: GC working 1244: cap 20: GC idle 1768: cap 31: GC working 1eb4: cap 26: GC working 1564: cap 55: GC idle 1590: cap 38: GC working 1510: cap 21: GC working 8a8: cap 78: GC working 8a8: cap 78: GC idle 1be8: cap 80: GC working 1be8: cap 80: GC idle 1a38: cap 71: GC idle 454: cap 13: GC idle 1908: cap 48: GC working 1aa8: cap 12: GC idle 1b30: cap 58: GC idle 1848: cap 22: GC idle 221c: cap 65: GC idle a04: cap 56: GC idle 1944: cap 61: GC working 14b8: cap 60: GC working 1ebc: cap 53: GC idle 2340: cap 67: GC idle 1fac: cap 46: GC idle 2720: cap 14: GC working 2720: cap 14: GC idle 11bc: cap 35: GC idle 11e8: cap 47: GC idle 15e8: cap 15: GC idle 2108: cap 63: GC idle 140c: cap 57: GC working 1768: cap 31: GC idle 1768: cap 31: GC done 2404: cap 73: GC done 14b8: cap 60: GC idle 14b8: cap 60: GC done 58c: cap 34: GC done 1944: cap 61: GC idle 1944: cap 61: GC done 17b8: cap 11: GC done 11bc: cap 35: GC done 18b0: cap 36: GC done 2720: cap 14: GC done 1be8: cap 80: GC done bd4: cap 37: GC done 24dc: cap 40: GC done 1838: cap 41: GC done 2178: cap 24: GC done 1ec0: cap 49: GC done 212c: cap 25: GC done 2600: cap 3: GC done 166c: cap 2: GC done 454: cap 13: GC done 13a8: cap 19: GC done 8cc: cap 62: GC done 25f0: cap 6: GC done 1d40: cap 1: GC done 1be4: cap 85: GC done 1fac: cap 46: GC done 11e8: cap 47: GC done 1aa8: cap 12: GC done 2340: cap 67: GC done 1f58: cap 0: GC done 610: cap 52: GC done 2180: cap 64: GC done 25f4: cap 7: GC done 140c: cap 57: GC idle 140c: cap 57: GC done 8a8: cap 78: GC done 270: cap 9: GC done 15e8: cap 15: GC done 1a9c: cap 27: GC idle 1a9c: cap 27: GC done 1a28: cap 77: GC done 1564: cap 55: GC done 9b8: cap 17: GC done 1244: cap 20: GC done a04: cap 56: GC done 18e0: cap 44: GC done 1ebc: cap 53: GC done 85c: cap 16: GC done 1254: cap 82: GC done 2428: cap 74: GC done b98: cap 39: GC done 1ef0: cap 76: GC done 2574: cap 33: GC done 229c: cap 23: GC done 1848: cap 22: GC done 464: cap 18: GC done 2454: cap 70: GC idle 2454: cap 70: GC done 948: cap 83: GC done 1eb8: cap 51: GC done 25fc: cap 4: GC done 25f8: cap 5: GC done 1590: cap 38: GC idle 1590: cap 38: GC done 94c: cap 29: GC done 1d50: cap 69: GC done 17f8: cap 84: GC done 2570: cap 32: GC done 2108: cap 63: GC done 2424: cap 75: GC done 6c8: cap 10: GC done 480: cap 42: GC done 1fd0: cap 45: GC done 1eb4: cap 26: GC idle 1eb4: cap 26: GC done 24e0: cap 30: GC done 12b8: cap 50: GC done 1b60: cap 66: GC idle 1b60: cap 66: GC done 1a34: cap 59: GC done 1534: cap 81: GC done 221c: cap 65: GC done 240c: cap 86: GC done 11b4: cap 87: GC done 7e0: cap 72: GC done 188c: cap 68: GC done 1510: cap 21: GC idle 1510: cap 21: GC done 2210: cap 8: GC done 418: cap 54: GC done 1860: cap 28: GC done 1ac0: cap 43: GC done 1a38: cap 71: GC done 2424: cap 75: GC idle 2424: cap 75: GC done 1b30: cap 58: GC done 1c2c: cap 79: GC done 1908: cap 48: GC idle 1908: cap 48: GC done 2424: cap 75: GC idle 2424: cap 75: GC done 2424: cap 75: all caps stopped for GC 2424: cap 75: finished GC 25fc: cap 4: finished GC 25fc: giving up capability 4 25fc: freeing capability 4 454: cap 13: finished GC 1a9c: cap 27: finished GC 1a9c: giving up capability 27 1a9c: freeing capability 27 1d40: cap 1: finished GC 2428: cap 74: finished GC 2428: giving up capability 74 2428: freeing capability 74 14b8: cap 60: finished GC 25f8: cap 5: finished GC 25f8: giving up capability 5 25f8: freeing capability 5 1838: cap 41: finished GC 2424: giving up capability 75 2424: freeing capability 75 94c: cap 29: finished GC 94c: giving up capability 29 94c: freeing capability 29 94c: woken up on capability 29 94c: resuming capability 29 94c: giving up capability 29 94c: freeing capability 29 a04: cap 56: finished GC a04: giving up capability 56 a04: freeing capability 56 2180: cap 64: finished GC 2180: giving up capability 64 2180: freeing capability 64 188c: cap 68: finished GC 188c: giving up capability 68 188c: freeing capability 68 480: cap 42: finished GC 480: giving up capability 42 480: freeing capability 42 25f4: cap 7: finished GC 25f4: giving up capability 7 25f4: freeing capability 7 1eb4: cap 26: finished GC 1eb4: giving up capability 26 1eb4: freeing capability 26 418: cap 54: finished GC 418: giving up capability 54 418: freeing capability 54 418: woken up on capability 54 418: resuming capability 54 418: giving up capability 54 418: freeing capability 54 1860: cap 28: finished GC 1860: giving up capability 28 1860: freeing capability 28 2574: cap 33: finished GC 2574: giving up capability 33 2574: freeing capability 33 1b60: cap 66: finished GC 1b60: giving up capability 66 1b60: freeing capability 66 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: giving up capability 66 1b60: freeing capability 66 1ebc: cap 53: finished GC 1ebc: giving up capability 53 1ebc: freeing capability 53 1ebc: woken up on capability 53 1ebc: resuming capability 53 610: cap 52: finished GC 610: giving up capability 52 610: freeing capability 52 17f8: cap 84: finished GC 17f8: giving up capability 84 17f8: freeing capability 84 17f8: woken up on capability 84 17f8: resuming capability 84 17f8: giving up capability 84 17f8: freeing capability 84 12b8: cap 50: finished GC 12b8: giving up capability 50 12b8: freeing capability 50 1564: cap 55: finished GC 1564: giving up capability 55 1564: freeing capability 55 229c: cap 23: finished GC 229c: giving up capability 23 229c: freeing capability 23 2720: cap 14: finished GC 2720: giving up capability 14 2720: freeing capability 14 454: giving up capability 13 454: freeing capability 13 bd4: cap 37: finished GC bd4: giving up capability 37 bd4: freeing capability 37 bd4: woken up on capability 37 bd4: resuming capability 37 bd4: giving up capability 37 bd4: freeing capability 37 1838: giving up capability 41 1838: freeing capability 41 18b0: cap 36: finished GC 18b0: giving up capability 36 18b0: freeing capability 36 1c2c: cap 79: finished GC 1c2c: giving up capability 79 1c2c: freeing capability 79 1f58: cap 0: finished GC 1f58: deadlocked, forcing major GC... 1f58: cap 0: requesting parallel GC 1f58: 0 idle caps 1f58: passing capability 4 to worker 0x25fc 1f58: passing capability 5 to worker 0x25f8 1f58: passing capability 7 to worker 0x25f4 1f58: passing capability 13 to worker 0x454 1f58: passing capability 14 to worker 0x2720 1f58: passing capability 23 to worker 0x229c 1f58: passing capability 26 to worker 0x1eb4 1f58: passing capability 27 to worker 0x1a9c 1f58: passing capability 28 to worker 0x1860 1f58: passing capability 29 to worker 0x94c 1f58: passing capability 33 to worker 0x2574 1f58: passing capability 36 to worker 0x18b0 1f58: passing capability 37 to worker 0xbd4 1f58: passing capability 41 to worker 0x1838 1f58: passing capability 42 to worker 0x480 1f58: passing capability 50 to worker 0x12b8 1f58: passing capability 52 to worker 0x610 1f58: passing capability 54 to worker 0x418 1f58: passing capability 55 to worker 0x1564 1f58: passing capability 56 to worker 0xa04 1f58: passing capability 64 to worker 0x2180 1f58: passing capability 66 to worker 0x1b60 1f58: passing capability 68 to worker 0x188c 1f58: passing capability 74 to worker 0x2428 1f58: passing capability 75 to worker 0x2424 1f58: passing capability 79 to worker 0x1c2c 1f58: passing capability 84 to worker 0x17f8 1f58: passing capability 4 to worker 0x25fc 1f58: passing capability 5 to worker 0x25f8 1f58: passing capability 7 to worker 0x25f4 1f58: passing capability 13 to worker 0x454 1f58: passing capability 14 to worker 0x2720 1f58: passing capability 23 to worker 0x229c 1f58: passing capability 26 to worker 0x1eb4 1f58: passing capability 27 to worker 0x1a9c 1f58: passing capability 28 to worker 0x1860 1f58: passing capability 29 to worker 0x94c 1f58: passing capability 33 to worker 0x2574 1f58: passing capability 36 to worker 0x18b0 2570: cap 32: finished GC 2570: someone else is trying to sync (2)... 2570: cap 32: starting GC 2210: cap 8: finished GC 2210: someone else is trying to sync (2)... 2210: cap 8: starting GC 7e0: cap 72: finished GC 7e0: someone else is trying to sync (2)... 7e0: cap 72: starting GC 2178: cap 24: finished GC 2178: deadlocked, forcing major GC... 2178: someone else is trying to sync (2)... 2178: cap 24: starting GC 18e0: cap 44: finished GC 18e0: deadlocked, forcing major GC... 18e0: someone else is trying to sync (2)... 18e0: cap 44: starting GC 1590: cap 38: finished GC 1de4: returning; I want capability 0 1768: cap 31: finished GC 1768: someone else is trying to sync (2)... 1768: cap 31: starting GC 6c8: cap 10: finished GC 6c8: deadlocked, forcing major GC... 1ac0: cap 43: finished GC 1ac0: someone else is trying to sync (2)... 1ac0: cap 43: starting GC 1ef0: cap 76: finished GC 1ef0: deadlocked, forcing major GC... 1ef0: someone else is trying to sync (2)... 1ef0: cap 76: starting GC 58c: cap 34: finished GC 58c: deadlocked, forcing major GC... 58c: someone else is trying to sync (2)... 58c: cap 34: starting GC 85c: cap 16: finished GC 85c: someone else is trying to sync (2)... 85c: cap 16: starting GC 1a9c: woken up on capability 27 1a9c: resuming capability 27 1a9c: cap 27: starting GC 2108: cap 63: finished GC 2108: someone else is trying to sync (2)... 2108: cap 63: starting GC 15e8: cap 15: finished GC 15e8: deadlocked, forcing major GC... 15e8: someone else is trying to sync (2)... 15e8: cap 15: starting GC bd4: woken up on capability 37 1be4: cap 85: finished GC 1be4: someone else is trying to sync (2)... 1be4: cap 85: starting GC 480: woken up on capability 42 480: resuming capability 42 480: cap 42: starting GC 24dc: cap 40: finished GC 24dc: someone else is trying to sync (2)... 24dc: cap 40: starting GC 418: woken up on capability 54 418: resuming capability 54 418: cap 54: starting GC a04: woken up on capability 56 a04: resuming capability 56 a04: cap 56: starting GC 2180: woken up on capability 64 2180: resuming capability 64 2180: cap 64: starting GC 1a38: cap 71: finished GC 1a38: someone else is trying to sync (2)... 1a38: cap 71: starting GC 8a8: cap 78: finished GC 8a8: someone else is trying to sync (2)... 8a8: cap 78: starting GC 8cc: cap 62: finished GC 8cc: deadlocked, forcing major GC... 17b8: cap 11: finished GC 17f8: woken up on capability 84 17f8: resuming capability 84 17f8: cap 84: starting GC 2454: cap 70: finished GC 2454: deadlocked, forcing major GC... 2454: someone else is trying to sync (2)... 2454: cap 70: starting GC 948: cap 83: finished GC 1fac: cap 46: finished GC 1fac: someone else is trying to sync (2)... 1fac: cap 46: starting GC 1eb8: cap 51: finished GC 1f58: passing capability 37 to worker 0xbd4 1f58: passing capability 41 to worker 0x1838 1f58: passing capability 50 to worker 0x12b8 1f58: passing capability 52 to worker 0x610 1f58: passing capability 55 to worker 0x1564 1f58: passing capability 66 to worker 0x1b60 1f58: passing capability 68 to worker 0x188c 1f58: passing capability 74 to worker 0x2428 1f58: passing capability 75 to worker 0x2424 1f58: passing capability 79 to worker 0x1c2c 1244: cap 20: finished GC 1244: deadlocked, forcing major GC... 1244: someone else is trying to sync (2)... 1244: cap 20: starting GC 24e0: cap 30: finished GC 24e0: someone else is trying to sync (2)... 24e0: cap 30: starting GC 6c8: someone else is trying to sync (2)... 6c8: cap 10: starting GC 212c: cap 25: finished GC 212c: deadlocked, forcing major GC... 454: woken up on capability 13 454: resuming capability 13 454: cap 13: starting GC 1a34: cap 59: finished GC 1a34: someone else is trying to sync (2)... 1a34: cap 59: starting GC 11b4: cap 87: finished GC 11b4: cap 87: message: try wakeup thread 3 11b4: cap 87: waking up thread 3 on cap 87 11b4: cap 87: starting GC 2574: woken up on capability 33 2574: resuming capability 33 2574: cap 33: starting GC 1a28: cap 77: finished GC 1838: woken up on capability 41 1838: resuming capability 41 1838: cap 41: starting GC 140c: cap 57: finished GC 610: woken up on capability 52 610: resuming capability 52 610: cap 52: starting GC 1564: woken up on capability 55 1564: resuming capability 55 1564: cap 55: starting GC 166c: cap 2: finished GC 166c: deadlocked, forcing major GC... 166c: someone else is trying to sync (2)... 166c: cap 2: starting GC 221c: cap 65: finished GC 221c: someone else is trying to sync (2)... 221c: cap 65: starting GC 8cc: someone else is trying to sync (2)... 8cc: cap 62: starting GC 1ebc: giving up capability 53 1ebc: passing capability 53 to worker 0x1ebc 1ebc: woken up on capability 53 1ebc: resuming capability 53 1ebc: cap 53: starting GC 948: deadlocked, forcing major GC... 948: someone else is trying to sync (2)... 948: cap 83: starting GC 1eb8: deadlocked, forcing major GC... 1eb8: someone else is trying to sync (2)... 1eb8: cap 51: starting GC 1ec0: cap 49: finished GC 1be8: cap 80: finished GC 1be8: someone else is trying to sync (2)... 1be8: cap 80: starting GC 2600: cap 3: finished GC 2600: deadlocked, forcing major GC... 240c: cap 86: finished GC 270: cap 9: finished GC 270: someone else is trying to sync (2)... 270: cap 9: starting GC 1944: cap 61: finished GC 1944: someone else is trying to sync (2)... 1944: cap 61: starting GC 25fc: woken up on capability 4 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: cap 5: starting GC 11e8: cap 47: finished GC 2720: woken up on capability 14 2720: resuming capability 14 2720: cap 14: starting GC 1aa8: cap 12: finished GC 1860: woken up on capability 28 1860: resuming capability 28 1860: cap 28: starting GC 1254: cap 82: finished GC 1a28: deadlocked, forcing major GC... 1a28: someone else is trying to sync (2)... 1a28: cap 77: starting GC 140c: deadlocked, forcing major GC... 1908: cap 48: finished GC 1908: deadlocked, forcing major GC... 1908: someone else is trying to sync (2)... 1908: cap 48: starting GC 1b60: woken up on capability 66 1b60: resuming capability 66 1b60: cap 66: starting GC 2424: woken up on capability 75 2424: resuming capability 75 2424: cap 75: starting GC 2404: cap 73: finished GC 2404: someone else is trying to sync (2)... 2404: cap 73: starting GC 11bc: cap 35: finished GC 11bc: someone else is trying to sync (2)... 11bc: cap 35: starting GC 1b30: cap 58: finished GC bd4: resuming capability 37 bd4: cap 37: starting GC 13a8: cap 19: finished GC 1d40: cap 1: running thread 4 (ThreadRunGHC) 14b8: giving up capability 60 14b8: passing capability 60 to worker 0x14b8 240c: deadlocked, forcing major GC... 1f58: passing capability 4 to worker 0x25fc 1f58: passing capability 7 to worker 0x25f4 1f58: passing capability 23 to worker 0x229c 1f58: passing capability 26 to worker 0x1eb4 1f58: passing capability 29 to worker 0x94c 1f58: passing capability 36 to worker 0x18b0 1f58: passing capability 50 to worker 0x12b8 1f58: passing capability 60 to worker 0x14b8 1f58: passing capability 68 to worker 0x188c 1f58: passing capability 74 to worker 0x2428 1f58: passing capability 79 to worker 0x1c2c 18b0: woken up on capability 36 18b0: resuming capability 36 18b0: cap 36: starting GC 12b8: woken up on capability 50 12b8: resuming capability 50 12b8: cap 50: starting GC 2340: cap 67: finished GC 464: cap 18: finished GC 464: someone else is trying to sync (2)... 464: cap 18: starting GC 1c2c: woken up on capability 79 1c2c: resuming capability 79 1c2c: cap 79: starting GC 1534: cap 81: finished GC 1534: someone else is trying to sync (2)... 1534: cap 81: starting GC 1b30: deadlocked, forcing major GC... 1b30: someone else is trying to sync (2)... 1b30: cap 58: starting GC 1d40: cap 1: thread 4 stopped (yielding) 2600: someone else is trying to sync (2)... 2600: cap 3: starting GC 240c: someone else is trying to sync (2)... 240c: cap 86: starting GC b98: cap 39: finished GC b98: someone else is trying to sync (2)... b98: cap 39: starting GC 25f4: woken up on capability 7 212c: someone else is trying to sync (2)... 212c: cap 25: starting GC 229c: woken up on capability 23 229c: resuming capability 23 229c: cap 23: starting GC 94c: woken up on capability 29 94c: resuming capability 29 94c: cap 29: starting GC 1fd0: cap 45: finished GC 1fd0: someone else is trying to sync (2)... 1fd0: cap 45: starting GC 2340: deadlocked, forcing major GC... 2340: someone else is trying to sync (2)... 2340: cap 67: starting GC 17b8: deadlocked, forcing major GC... 1848: cap 22: finished GC 1510: cap 21: finished GC 1510: deadlocked, forcing major GC... 1ec0: deadlocked, forcing major GC... 13a8: deadlocked, forcing major GC... 1d40: cap 1: starting GC 14b8: woken up on capability 60 14b8: resuming capability 60 14b8: cap 60: starting GC 9b8: cap 17: finished GC 11e8: deadlocked, forcing major GC... 11e8: someone else is trying to sync (2)... 11e8: cap 47: starting GC 1f58: passing capability 7 to worker 0x25f4 1254: deadlocked, forcing major GC... 140c: someone else is trying to sync (2)... 140c: cap 57: starting GC 188c: woken up on capability 68 188c: resuming capability 68 188c: cap 68: starting GC 1848: deadlocked, forcing major GC... 1848: someone else is trying to sync (2)... 1848: cap 22: starting GC 1ec0: someone else is trying to sync (2)... 1ec0: cap 49: starting GC 25fc: resuming capability 4 25fc: cap 4: starting GC 9b8: deadlocked, forcing major GC... 1eb4: woken up on capability 26 1aa8: deadlocked, forcing major GC... 25f4: resuming capability 7 25f4: cap 7: starting GC 1254: someone else is trying to sync (2)... 1254: cap 82: starting GC 2428: woken up on capability 74 2428: resuming capability 74 2428: cap 74: starting GC 1510: someone else is trying to sync (2)... 1510: cap 21: starting GC 1590: deadlocked, forcing major GC... 9b8: someone else is trying to sync (2)... 9b8: cap 17: starting GC 1f58: passing capability 26 to worker 0x1eb4 25f0: cap 6: finished GC 25f0: someone else is trying to sync (2)... 25f0: cap 6: starting GC 13a8: someone else is trying to sync (2)... 13a8: cap 19: starting GC 1aa8: someone else is trying to sync (2)... 1aa8: cap 12: starting GC 17b8: someone else is trying to sync (2)... 17b8: cap 11: starting GC 1590: someone else is trying to sync (2)... 1590: cap 38: starting GC 1d50: cap 69: finished GC 1d50: someone else is trying to sync (2)... 1d50: cap 69: starting GC 1eb4: resuming capability 26 1eb4: cap 26: starting GC all threads: threads on capability 0: threads on capability 1: thread 4 @ 0000000035bfc000 is not blocked (TSO_DIRTY) threads on capability 2: threads on capability 3: threads on capability 4: threads on capability 5: threads on capability 6: threads on capability 7: threads on capability 8: threads on capability 9: threads on capability 10: threads on capability 11: threads on capability 12: threads on capability 13: threads on capability 14: threads on capability 15: threads on capability 16: threads on capability 17: threads on capability 18: threads on capability 19: threads on capability 20: threads on capability 21: threads on capability 22: threads on capability 23: threads on capability 24: threads on capability 25: threads on capability 26: threads on capability 27: threads on capability 28: threads on capability 29: threads on capability 30: threads on capability 31: threads on capability 32: threads on capability 33: threads on capability 34: threads on capability 35: threads on capability 36: threads on capability 37: threads on capability 38: threads on capability 39: threads on capability 40: threads on capability 41: threads on capability 42: threads on capability 43: threads on capability 44: threads on capability 45: threads on capability 46: threads on capability 47: threads on capability 48: threads on capability 49: threads on capability 50: threads on capability 51: threads on capability 52: threads on capability 53: threads on capability 54: threads on capability 55: threads on capability 56: threads on capability 57: threads on capability 58: threads on capability 59: threads on capability 60: threads on capability 61: threads on capability 62: threads on capability 63: threads on capability 64: threads on capability 65: threads on capability 66: threads on capability 67: threads on capability 68: threads on capability 69: threads on capability 70: threads on capability 71: threads on capability 72: threads on capability 73: threads on capability 74: threads on capability 75: threads on capability 76: threads on capability 77: threads on capability 78: threads on capability 79: threads on capability 80: threads on capability 81: threads on capability 82: threads on capability 83: threads on capability 84: threads on capability 85: threads on capability 86: threads on capability 87: thread 3 @ 0000000035ba4000 is not blocked (TSO_DIRTY) other threads: thread 2 @ 0000000035ca9178 is blocked on an external call thread 5 @ 0000000035bfc0f0 is blocked on a black hole 0000000035bfc0a0 thread 6 @ 0000000035bfc200 is blocked on a black hole 0000000035bfc0a0 thread 7 @ 0000000035bb0de0 is blocked on a black hole 0000000035bfc0a0 thread 8 @ 0000000035bb0918 is blocked on a black hole 0000000035bfc0a0 thread 9 @ 0000000035bb09c0 is blocked on a black hole 0000000035bfc0a0 thread 10 @ 0000000035bfca90 is blocked on a black hole 0000000035bfc0a0 thread 11 @ 0000000035bb0000 is blocked on a black hole 0000000035bfc0a0 thread 12 @ 0000000035bfc188 is blocked on a black hole 0000000035bfc0a0 1f58: cap 0: starting GC 25f8: cap 5: GC working 11bc: cap 35: GC working 14b8: cap 60: GC working 1944: cap 61: GC working 18b0: cap 36: GC working 6c8: cap 10: GC working 6c8: cap 10: GC idle 2340: cap 67: GC working 18e0: cap 44: GC working 140c: cap 57: GC working 140c: cap 57: GC idle 13a8: cap 19: GC working 17b8: cap 11: GC working 2180: cap 64: GC working 2180: cap 64: GC idle 464: cap 18: GC working 1eb8: cap 51: GC working 1b60: cap 66: GC working 188c: cap 68: GC working 12b8: cap 50: GC working 270: cap 9: GC working 1848: cap 22: GC working 1848: cap 22: GC idle 1534: cap 81: GC working 1534: cap 81: GC idle 7e0: cap 72: GC working 1eb4: cap 26: GC working 1a9c: cap 27: GC working 1a9c: cap 27: GC idle 2424: cap 75: GC working 2424: cap 75: GC idle 1ef0: cap 76: GC working 1ec0: cap 49: GC working 1ec0: cap 49: GC idle 2108: cap 63: GC working 2108: cap 63: GC idle 1254: cap 82: GC working 94c: cap 29: GC working 94c: cap 29: GC idle 166c: cap 2: GC working 166c: cap 2: GC idle 948: cap 83: GC working 948: cap 83: GC idle 212c: cap 25: GC working 212c: cap 25: GC idle 1f58: cap 0: GC working 2600: cap 3: GC working 2600: cap 3: GC idle 240c: cap 86: GC working 240c: cap 86: GC idle 1b30: cap 58: GC working 1aa8: cap 12: GC working 11b4: cap 87: GC working 1d40: cap 1: GC working 1848: cap 22: GC working 166c: cap 2: GC working 2600: cap 3: GC working 2600: cap 3: GC idle 1ec0: cap 49: GC working 948: cap 83: GC working 2180: cap 64: GC working 140c: cap 57: GC working 140c: cap 57: GC idle 2570: cap 32: GC working 1254: cap 82: GC idle 1f58: cap 0: GC idle 1eb4: cap 26: GC idle 1fd0: cap 45: GC working 1ef0: cap 76: GC idle 12b8: cap 50: GC idle 1534: cap 81: GC working 1eb8: cap 51: GC idle 1a28: cap 77: GC working 25f4: cap 7: GC working 25f4: cap 7: GC idle 212c: cap 25: GC working 1be4: cap 85: GC working 1be4: cap 85: GC idle 1b60: cap 66: GC idle 2340: cap 67: GC idle 1aa8: cap 12: GC idle 464: cap 18: GC idle 270: cap 9: GC idle 1b30: cap 58: GC idle 221c: cap 65: GC working 221c: cap 65: GC idle 2428: cap 74: GC working a04: cap 56: GC working 2210: cap 8: GC working 9b8: cap 17: GC working 24dc: cap 40: GC working 24dc: cap 40: GC idle 2178: cap 24: GC working 2178: cap 24: GC idle 2720: cap 14: GC working 1590: cap 38: GC working 1590: cap 38: GC idle 1860: cap 28: GC working 1860: cap 28: GC idle 17b8: cap 11: GC idle 25f0: cap 6: GC working 94c: cap 29: GC working 1ac0: cap 43: GC working 15e8: cap 15: GC working 480: cap 42: GC working 480: cap 42: GC idle 13a8: cap 19: GC idle 188c: cap 68: GC idle 1a34: cap 59: GC working 11bc: cap 35: GC idle 1510: cap 21: GC working b98: cap 39: GC working b98: cap 39: GC idle 454: cap 13: GC working 454: cap 13: GC idle 1944: cap 61: GC idle 1a9c: cap 27: GC working 1a9c: cap 27: GC idle 58c: cap 34: GC working 58c: cap 34: GC idle 2454: cap 70: GC working 1a38: cap 71: GC working 1a38: cap 71: GC idle 1244: cap 20: GC working 1d50: cap 69: GC working 1838: cap 41: GC working 1838: cap 41: GC idle 2108: cap 63: GC working 2108: cap 63: GC idle 1ebc: cap 53: GC working 18e0: cap 44: GC idle 1564: cap 55: GC working 1564: cap 55: GC idle 1be8: cap 80: GC working 1be8: cap 80: GC idle 17f8: cap 84: GC working 1908: cap 48: GC working 1908: cap 48: GC idle 610: cap 52: GC working 14b8: cap 60: GC idle 1d40: cap 1: GC idle 2574: cap 33: GC working 2574: cap 33: GC idle 166c: cap 2: GC idle 11b4: cap 87: GC idle 1ec0: cap 49: GC idle 948: cap 83: GC idle 2180: cap 64: GC idle 240c: cap 86: GC working 2570: cap 32: GC idle 1fd0: cap 45: GC idle 1534: cap 81: GC idle 1a28: cap 77: GC idle 2404: cap 73: GC working 212c: cap 25: GC idle 2424: cap 75: GC working 85c: cap 16: GC working 85c: cap 16: GC idle a04: cap 56: GC idle 2210: cap 8: GC idle 9b8: cap 17: GC idle 25f8: cap 5: GC idle bd4: cap 37: GC working bd4: cap 37: GC idle 1768: cap 31: GC working 6c8: cap 10: GC working 25f0: cap 6: GC idle 94c: cap 29: GC idle 1ac0: cap 43: GC idle 15e8: cap 15: GC idle 229c: cap 23: GC working 1a34: cap 59: GC idle 1510: cap 21: GC idle 18b0: cap 36: GC idle 25fc: cap 4: GC working 25fc: cap 4: GC idle 418: cap 54: GC working 2454: cap 70: GC idle 24e0: cap 30: GC working 1244: cap 20: GC idle 1d50: cap 69: GC idle 8cc: cap 62: GC working 8cc: cap 62: GC idle 1ebc: cap 53: GC idle 11e8: cap 47: GC working 8a8: cap 78: GC working 17f8: cap 84: GC idle 1fac: cap 46: GC working 610: cap 52: GC idle 1848: cap 22: GC idle 240c: cap 86: GC idle 2404: cap 73: GC idle 2424: cap 75: GC idle 2428: cap 74: GC idle 2720: cap 14: GC idle 1768: cap 31: GC idle 6c8: cap 10: GC idle 229c: cap 23: GC idle 7e0: cap 72: GC idle 418: cap 54: GC idle 24e0: cap 30: GC idle 1c2c: cap 79: GC working 1c2c: cap 79: GC idle 1c2c: cap 79: GC done 1ac0: cap 43: GC done 1944: cap 61: GC done 1a38: cap 71: GC done 1eb4: cap 26: GC done 480: cap 42: GC done 1fac: cap 46: GC idle 1fac: cap 46: GC done 11bc: cap 35: GC done 1838: cap 41: GC done 11e8: cap 47: GC idle 11e8: cap 47: GC done 18e0: cap 44: GC done 1908: cap 48: GC done 24dc: cap 40: GC done 24e0: cap 30: GC done 1a28: cap 77: GC done 2428: cap 74: GC done 8a8: cap 78: GC idle 8a8: cap 78: GC done 13a8: cap 19: GC done 229c: cap 23: GC done 2404: cap 73: GC done 2574: cap 33: GC done 140c: cap 57: GC done 1be4: cap 85: GC done 2454: cap 70: GC done 1254: cap 82: GC done 11b4: cap 87: GC done 1b60: cap 66: GC done 270: cap 9: GC done 12b8: cap 50: GC done 2424: cap 75: GC done bd4: cap 37: GC done 18b0: cap 36: GC done 1eb8: cap 51: GC done 85c: cap 16: GC done 14b8: cap 60: GC done 610: cap 52: GC done 1d40: cap 1: GC done 1510: cap 21: GC done 1ef0: cap 76: GC done 2340: cap 67: GC done 1534: cap 81: GC done 1be8: cap 80: GC done 2178: cap 24: GC done 25f0: cap 6: GC done 9b8: cap 17: GC done 1ec0: cap 49: GC done 1768: cap 31: GC done 212c: cap 25: GC done 17f8: cap 84: GC done 1860: cap 28: GC done 1564: cap 55: GC done 58c: cap 34: GC done 418: cap 54: GC done 454: cap 13: GC done 2600: cap 3: GC done 1d50: cap 69: GC done a04: cap 56: GC done 1b30: cap 58: GC done 25fc: cap 4: GC done 1a34: cap 59: GC done 188c: cap 68: GC done 1a9c: cap 27: GC done 2108: cap 63: GC done 94c: cap 29: GC done 1aa8: cap 12: GC done 2180: cap 64: GC done 240c: cap 86: GC done 25f4: cap 7: GC done 7e0: cap 72: GC done 221c: cap 65: GC done b98: cap 39: GC done 15e8: cap 15: GC done 6c8: cap 10: GC done 1ebc: cap 53: GC done 1848: cap 22: GC done 948: cap 83: GC done 8cc: cap 62: GC done 1244: cap 20: GC done 1f58: cap 0: GC done 25f8: cap 5: GC done 166c: cap 2: GC done 2570: cap 32: GC done 1590: cap 38: GC done 2720: cap 14: GC done 1fd0: cap 45: GC done 464: cap 18: GC done 17b8: cap 11: GC done 2210: cap 8: GC done 1f58: cap 0: GC idle 1f58: cap 0: GC done 1f58: cap 0: GC idle 1f58: cap 0: GC done 1f58: cap 0: all caps stopped for GC 1f58: cap 0: finished GC 1d40: cap 1: finished GC 270: cap 9: finished GC 270: giving up capability 9 270: freeing capability 9 270: woken up on capability 9 270: resuming capability 9 1860: cap 28: finished GC 1eb4: cap 26: finished GC 8cc: cap 62: finished GC 8cc: giving up capability 62 8cc: freeing capability 62 9b8: cap 17: finished GC 9b8: giving up capability 17 9b8: freeing capability 17 25f8: cap 5: finished GC 1a34: cap 59: finished GC 1a34: giving up capability 59 1a34: freeing capability 59 1a34: woken up on capability 59 1a34: resuming capability 59 1a34: giving up capability 59 1a34: freeing capability 59 8a8: cap 78: finished GC 8a8: giving up capability 78 8a8: freeing capability 78 8a8: woken up on capability 78 8a8: resuming capability 78 8a8: giving up capability 78 8a8: freeing capability 78 1aa8: cap 12: finished GC 1aa8: giving up capability 12 1aa8: freeing capability 12 1d50: cap 69: finished GC 1d50: giving up capability 69 1d50: freeing capability 69 1d50: woken up on capability 69 1d50: resuming capability 69 1d50: giving up capability 69 1d50: freeing capability 69 1244: cap 20: finished GC 1244: giving up capability 20 1244: freeing capability 20 1c2c: cap 79: finished GC 1c2c: giving up capability 79 1c2c: freeing capability 79 1c2c: woken up on capability 79 1c2c: resuming capability 79 454: cap 13: finished GC 454: giving up capability 13 454: freeing capability 13 454: woken up on capability 13 454: resuming capability 13 454: giving up capability 13 454: freeing capability 13 11bc: cap 35: finished GC 11bc: giving up capability 35 11bc: freeing capability 35 221c: cap 65: finished GC 221c: giving up capability 65 221c: freeing capability 65 221c: woken up on capability 65 221c: resuming capability 65 221c: giving up capability 65 221c: freeing capability 65 1ac0: cap 43: finished GC 1ac0: giving up capability 43 1ac0: freeing capability 43 11e8: cap 47: finished GC 11e8: giving up capability 47 11e8: freeing capability 47 464: cap 18: finished GC 464: giving up capability 18 464: freeing capability 18 2428: cap 74: finished GC 2428: giving up capability 74 2428: freeing capability 74 2428: woken up on capability 74 2428: resuming capability 74 2428: giving up capability 74 2428: freeing capability 74 2720: cap 14: finished GC 2720: giving up capability 14 2720: freeing capability 14 2720: woken up on capability 14 2720: resuming capability 14 2720: giving up capability 14 2720: freeing capability 14 1eb8: cap 51: finished GC 1eb8: giving up capability 51 1eb8: freeing capability 51 12b8: cap 50: finished GC 12b8: giving up capability 50 12b8: freeing capability 50 12b8: woken up on capability 50 12b8: resuming capability 50 12b8: giving up capability 50 12b8: freeing capability 50 14b8: cap 60: finished GC 14b8: giving up capability 60 14b8: passing capability 60 to worker 0x14b8 14b8: woken up on capability 60 14b8: resuming capability 60 14b8: deadlocked, forcing major GC... 14b8: cap 60: requesting parallel GC 14b8: 0 idle caps 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 14b8: passing capability 12 to worker 0x1aa8 14b8: passing capability 13 to worker 0x454 14b8: passing capability 14 to worker 0x2720 14b8: passing capability 17 to worker 0x9b8 14b8: passing capability 18 to worker 0x464 14b8: passing capability 20 to worker 0x1244 14b8: passing capability 35 to worker 0x11bc 14b8: passing capability 43 to worker 0x1ac0 14b8: passing capability 47 to worker 0x11e8 14b8: passing capability 50 to worker 0x12b8 14b8: passing capability 51 to worker 0x1eb8 14b8: passing capability 59 to worker 0x1a34 14b8: passing capability 62 to worker 0x8cc 14b8: passing capability 65 to worker 0x221c 14b8: passing capability 69 to worker 0x1d50 14b8: passing capability 74 to worker 0x2428 14b8: passing capability 78 to worker 0x8a8 140c: cap 57: finished GC 140c: someone else is trying to sync (2)... 140c: cap 57: starting GC 11b4: cap 87: finished GC 11b4: giving up capability 87 11b4: passing capability 87 to bound task 0x2444 11b4: woken up on capability 87 11b4: resuming capability 87 11b4: cap 87: starting GC 1590: cap 38: finished GC 1590: someone else is trying to sync (2)... 1590: cap 38: starting GC 229c: cap 23: finished GC 229c: deadlocked, forcing major GC... 229c: someone else is trying to sync (2)... 229c: cap 23: starting GC 1244: woken up on capability 20 1244: resuming capability 20 1244: cap 20: starting GC 1908: cap 48: finished GC 1908: someone else is trying to sync (2)... 1908: cap 48: starting GC 11e8: woken up on capability 47 11e8: resuming capability 47 11e8: cap 47: starting GC 2108: cap 63: finished GC 2108: someone else is trying to sync (2)... 2108: cap 63: starting GC 2210: cap 8: finished GC 2210: someone else is trying to sync (2)... 2210: cap 8: starting GC 1254: cap 82: finished GC 1254: someone else is trying to sync (2)... 1254: cap 82: starting GC 2454: cap 70: finished GC 2454: someone else is trying to sync (2)... 2454: cap 70: starting GC 2178: cap 24: finished GC 2178: someone else is trying to sync (2)... 2178: cap 24: starting GC 418: cap 54: finished GC 1ec0: cap 49: finished GC 1ec0: someone else is trying to sync (2)... 1ec0: cap 49: starting GC 1534: cap 81: finished GC 1534: someone else is trying to sync (2)... 1534: cap 81: starting GC 24dc: cap 40: finished GC 24dc: someone else is trying to sync (2)... 24dc: cap 40: starting GC 17f8: cap 84: finished GC 1510: cap 21: finished GC 1510: someone else is trying to sync (2)... 1510: cap 21: starting GC 94c: cap 29: finished GC 94c: deadlocked, forcing major GC... 94c: someone else is trying to sync (2)... 94c: cap 29: starting GC 1944: cap 61: finished GC 1944: someone else is trying to sync (2)... 1944: cap 61: starting GC 2600: cap 3: finished GC 2600: someone else is trying to sync (2)... 2600: cap 3: starting GC 1ef0: cap 76: finished GC 1ef0: someone else is trying to sync (2)... 1ef0: cap 76: starting GC 1f58: giving up capability 0 1f58: passing capability 0 to worker 0x1de4 1f58: woken up on capability 0 1f58: capability 0 is owned by another task 1768: cap 31: finished GC 1768: someone else is trying to sync (2)... 1768: cap 31: starting GC 166c: cap 2: finished GC 166c: someone else is trying to sync (2)... 166c: cap 2: starting GC 480: cap 42: finished GC 1fac: cap 46: finished GC 1fac: someone else is trying to sync (2)... 1fac: cap 46: starting GC 1860: giving up capability 28 1860: passing capability 28 to worker 0x1860 1860: woken up on capability 28 1860: resuming capability 28 1860: cap 28: starting GC 25f8: giving up capability 5 25f8: passing capability 5 to worker 0x25f8 25f8: woken up on capability 5 25f8: resuming capability 5 25f8: cap 5: starting GC 1aa8: woken up on capability 12 240c: cap 86: finished GC 240c: someone else is trying to sync (2)... 240c: cap 86: starting GC 13a8: cap 19: finished GC 13a8: someone else is trying to sync (2)... 13a8: cap 19: starting GC bd4: cap 37: finished GC bd4: deadlocked, forcing major GC... bd4: someone else is trying to sync (2)... bd4: cap 37: starting GC 11bc: woken up on capability 35 11bc: resuming capability 35 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler