From ghc-devs at haskell.org Tue Dec 1 03:38:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 03:38:16 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.77eeba9ed1306a431948e6c7314fc178@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * Attachment "tick-everything.patch" added. A variant of scpmw's patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 03:40:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 03:40:23 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.46d7c69109b0dfa88c21a2cabe632078@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | 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 gridaphobe): I've added a slight variant of scpmw's patch that adds ticks everywhere with a new `-ftick-everything` flag. It seems that the HsVar pattern was too restrictive. I'm not sure why.. But I don't see any harm in being more generous with Ticks given that this will be hidden behind a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 04:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 04:38:41 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell In-Reply-To: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> References: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> Message-ID: <062.2c9939f9079a90a3b4e67d55efd2d3c0@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 johnleo): Thanks for the pointer. From what I can tell the term "head" is defined in the original paper //Type classes: an exploration of the design space// for type class instances: Given {{{#!hs instance P => C T_1 ... T_n where ... }}} they define the head to be the part `C T_1 ... T_n` between `=>` and `where`. They also use it without precise definition to refer to the "class head" where again it looks like they are referring to the part between `=>` and `where` of a type class declaration. These seem to be the only two usages of head in sections 7.6 and 7.7 of the GHC user manual. However by analogy it does seem that naming the part between `type family` and `where` as the "head" of a type family declaration would be appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 09:33:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 09:33:02 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.cf08c02989a9aac5108b8ea791bf6655@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 09:35:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 09:35:00 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.71e9b9297fa9f082c07b4614ebbb1b6f@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+----------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Changes (by waern): * Attachment "config.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 11:19:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 11:19:29 -0000 Subject: [GHC] #10839: Consistent pretty-printing of type families In-Reply-To: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> References: <048.28810866bbeb92c031eb9149a92b094c@haskell.org> Message-ID: <063.b5dff1d6ecf80ff1257791ff05f5d58c@haskell.org> #10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 7.11 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:D1441 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 11:43:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 11:43:39 -0000 Subject: [GHC] #11150: New `-fwarn-noncanonical-monoid-instances` warning Message-ID: <042.55096ce3dad11d93367502f540669d4a@haskell.org> #11150: New `-fwarn-noncanonical-monoid-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11128, #11139 Differential Rev(s): | Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 11:48:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 11:48:32 -0000 Subject: [GHC] #11150: New `-fwarn-noncanonical-monoid-instances` warning In-Reply-To: <042.55096ce3dad11d93367502f540669d4a@haskell.org> References: <042.55096ce3dad11d93367502f540669d4a@haskell.org> Message-ID: <057.72c4f3cc8d7398af518861d15785ce7b@haskell.org> #11150: New `-fwarn-noncanonical-monoid-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.0.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: #11128, #11139 | Differential Rev(s): Phab:D1553 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * cc: ekmett, quchen (added) * differential: => Phab:D1553 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 13:15:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 13:15:19 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.707e2d2d9fdd6e4431a5a00669bd978c@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: kosmikus, RyanGlScott (added) Comment: Andres, Ryan: any ideas? This is in the `Generics` area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 13:38:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 13:38:05 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.34cddbec35b522e22cd19c21b643f2cf@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: duplicate => Comment: In `wip/spj-wildcard-refactor` (shortly to land) I get {{{ T11122.hs:18:18: warning: ? Found type wildcard ?_? standing for ?Int? ? In the type signature: parser :: Parser _ ? Relevant bindings include parser :: Parser Int (bound at T11122.hs:20:1) }}} Which looks right. Ben: can you add this as a regression test please when you land that big patch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 13:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 13:38:14 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.527ca024b9f2f4920c3de100ad77d6a0@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 15:33:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 15:33:00 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.329b5c07710c6cba7f25ecd30a71e682@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => bgamari * priority: normal => high * milestone: => 8.0.1 Comment: Works fine with `wip/spj-wildcard-refactor`. Ben please add this as a regression test. We get {{{ $ ghc-stage1 -c T11142.hs -dcore-lint -fforce-recomp -ddump-types TYPE SIGNATURES foo :: forall (k :: BOX) (b :: k). (forall (a :: k). SameKind a b) -> () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 15:39:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 15:39:24 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.4e1d5ad3534a68b085141ef749ba02c5@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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 goldfire): Hmm. On your branch, how is it decided when to abstract over kind variables? Here are two functions with explicit kind variables written: {{{ ex1 :: (forall k (a :: k). Proxy a -> ()) -> () ex2 :: forall k. (forall (a :: k). Proxy a -> ()) -> () }}} These are different, and both are conceivably useful. How are they distinguished on your branch? In HEAD, there is a consistent rule: if a kind variable is first mentioned in a tyvarbinder, then the kind variable is brought into scope in the same list of tyvarbinders. Otherwise, it's at the top level. What's the new rule? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 15:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 15:46:10 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.64031a7b48a181cbd6e3fea929d029ea@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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 simonpj): Always top level; c.f. #4426. Needs documentation I agree Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 15:52:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 15:52:24 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.b4a3b33c26a6232c049d0bdef489b664@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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 simonpj): Also see this Note in `TcHsType`: {{{ Note [Kind generalisation] ~~~~~~~~~~~~~~~~~~~~~~~~~~ We do kind generalisation only at the outer level of a type signature. For example, consider T :: forall k. k -> * f :: (forall a. T a -> Int) -> Int When kind-checking f's type signature we generalise the kind at the outermost level, thus: f1 :: forall k. (forall (a:k). T k a -> Int) -> Int -- YES! and *not* at the inner forall: f2 :: (forall k. forall (a:k). T k a -> Int) -> Int -- NO! Reason: same as for HM inference on value level declarations, we want to infer the most general type. The f2 type signature would be *less applicable* than f1, because it requires a more polymorphic argument. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 15:56:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 15:56:52 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.13186e2845e3775f1e0fdec49c6c6217@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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 goldfire): That's true -- but we're not talking about kind generalization here, because the user is asking for it (albeit a bit indirectly). So: all kind variables that GHC invents are always quantified at the top level, but previously, users could specify kind variables to be quantified below top level. If that ability has been removed, this is a real loss of expressiveness that will bite. However, it's all easily recovered with the capabilities of my branch, where you can write kind quantification directly. So perhaps it all works out. But there's a bad migration story, because there will be no way to write higher-rank kind quantification that works in both GHC 7.10 and GHC 8.0. In any case, we need to clearly document the new behavior in the release notes. Is it worth trying to resurrect the old behavior on your branch, just to ease migration? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 16:46:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 16:46:29 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.5c6a582c57b472187755d4edc059789d@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not immediately sure what's wrong, but it doesn't seem specific to `Generic1`. In fact, you can get the same error if you change `Generic1` to `Functor`, `Foldable`, or `Traversable`. It seems that something about typeclasses with kind `(* -> *) -> Constraint` triggers this, since I can derive `Eq`, `Ord`, `Read`, `Show`, `Data`, and `Lift` for `G Int b Float d` without any issue. Another clue is that `data instance F A a = AData a deriving Generic1` works fine, but `data instance F b a = AData a deriving Generic1` triggers this error, so you need at least one type variable in a data instance for this to happen. Perhaps the type variable in the data family declaration and the type variable in the data family instance have conflicting `Unique`s when reversed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:35:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:35:16 -0000 Subject: [GHC] #11151: T3064 regresses with wildcard refactor Message-ID: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> #11151: T3064 regresses with wildcard refactor -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: T3064 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is to track a regression in the allocations of the T3064 compiler performance testcase as a result of Simon's wildcard refactoring, ``` =====> T3064(normal) 1 of 1 [0, 0, 0] cd ./perf/compiler && "/mnt/work/ghc/ghc-testing/inplace/test spaces /ghc-stage2" -c T3064.hs -fforce-recomp -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history +RTS -G1 -RTS +RTS -V0 -tT3064.comp.stats --machine-readable -RTS > T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected T3064(normal) bytes allocated: 243670824 +/-5% Lower bound T3064(normal) bytes allocated: 231487282 Upper bound T3064(normal) bytes allocated: 255854366 Actual T3064(normal) bytes allocated: 264952256 Deviation T3064(normal) bytes allocated: 8.7 % ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:35:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:35:30 -0000 Subject: [GHC] #11151: T3064 regresses with wildcard refactor In-Reply-To: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> References: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> Message-ID: <061.5136ff2264f47fcecbe4d374fc179d32@haskell.org> #11151: T3064 regresses with wildcard refactor -------------------------------------+------------------------------------- Reporter: bgamari | 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 performance bug | Test Case: T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > This is to track a regression in the allocations of the T3064 compiler > performance testcase as a result of Simon's wildcard refactoring, > ``` > =====> T3064(normal) 1 of 1 [0, 0, 0] > cd ./perf/compiler && "/mnt/work/ghc/ghc-testing/inplace/test spaces > /ghc-stage2" -c T3064.hs -fforce-recomp -dno-debug-output -no-user- > package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- > ghci-history +RTS -G1 -RTS +RTS -V0 -tT3064.comp.stats --machine- > readable -RTS > T3064.comp.stderr 2>&1 > bytes allocated value is too high: > Expected T3064(normal) bytes allocated: 243670824 +/-5% > Lower bound T3064(normal) bytes allocated: 231487282 > Upper bound T3064(normal) bytes allocated: 255854366 > Actual T3064(normal) bytes allocated: 264952256 > Deviation T3064(normal) bytes allocated: 8.7 % > ``` New description: This is to track a regression in the allocations of the T3064 compiler performance testcase as a result of Simon's wildcard refactoring, {{{ =====> T3064(normal) 1 of 1 [0, 0, 0] cd ./perf/compiler && "/mnt/work/ghc/ghc-testing/inplace/test spaces /ghc-stage2" -c T3064.hs -fforce-recomp -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history +RTS -G1 -RTS +RTS -V0 -tT3064.comp.stats --machine-readable -RTS > T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected T3064(normal) bytes allocated: 243670824 +/-5% Lower bound T3064(normal) bytes allocated: 231487282 Upper bound T3064(normal) bytes allocated: 255854366 Actual T3064(normal) bytes allocated: 264952256 Deviation T3064(normal) bytes allocated: 8.7 % }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:38:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:38:25 -0000 Subject: [GHC] #11151: T3064 regresses with wildcard refactor In-Reply-To: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> References: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> Message-ID: <061.5840b2feac90ccf97ef6c9daa86487e8@haskell.org> #11151: T3064 regresses with wildcard refactor -------------------------------------+------------------------------------- Reporter: bgamari | 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 performance bug | Test Case: T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Perhaps add the before-and-after commit ids, so it's easy to compare when investigating? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:45:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:45:03 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.f1367c0eb704beb6333b8023e397d467@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/BadSock Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1260 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1e041b7382b6aa329e4ad9625439f811e0f27232/ghc" 1e041b73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e041b7382b6aa329e4ad9625439f811e0f27232" Refactor treatment of wildcards This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export Updates haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:45:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:45:40 -0000 Subject: [GHC] #11151: T3064 regresses with wildcard refactor In-Reply-To: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> References: <046.4829873e9d1dad10ccda56e715cd41d5@haskell.org> Message-ID: <061.81fa9af393c5c5334cd76f8c8eb62eb8@haskell.org> #11151: T3064 regresses with wildcard refactor -------------------------------------+------------------------------------- Reporter: bgamari | 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 performance bug | Test Case: T3064 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > This is to track a regression in the allocations of the T3064 compiler > performance testcase as a result of Simon's wildcard refactoring, > > {{{ > =====> T3064(normal) 1 of 1 [0, 0, 0] > cd ./perf/compiler && "/mnt/work/ghc/ghc-testing/inplace/test spaces > /ghc-stage2" -c T3064.hs -fforce-recomp -dno-debug-output -no-user- > package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- > ghci-history +RTS -G1 -RTS +RTS -V0 -tT3064.comp.stats --machine- > readable -RTS > T3064.comp.stderr 2>&1 > bytes allocated value is too high: > Expected T3064(normal) bytes allocated: 243670824 +/-5% > Lower bound T3064(normal) bytes allocated: 231487282 > Upper bound T3064(normal) bytes allocated: 255854366 > Actual T3064(normal) bytes allocated: 264952256 > Deviation T3064(normal) bytes allocated: 8.7 % > }}} New description: This is to track a regression in the allocations of the T3064 compiler performance testcase as a result of Simon's wildcard refactoring (1e041b7382b6aa329e4ad9625439f811e0f27232), {{{ =====> T3064(normal) 1 of 1 [0, 0, 0] cd ./perf/compiler && "/mnt/work/ghc/ghc-testing/inplace/test spaces /ghc-stage2" -c T3064.hs -fforce-recomp -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history +RTS -G1 -RTS +RTS -V0 -tT3064.comp.stats --machine-readable -RTS > T3064.comp.stderr 2>&1 bytes allocated value is too high: Expected T3064(normal) bytes allocated: 243670824 +/-5% Lower bound T3064(normal) bytes allocated: 231487282 Upper bound T3064(normal) bytes allocated: 255854366 Actual T3064(normal) bytes allocated: 264952256 Deviation T3064(normal) bytes allocated: 8.7 % }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 17:49:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 17:49:46 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.65b2ebc075234e43242a6ae69c4efd59@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett (added) Comment: I don't think I even knew that! The old behaviour is terribly inconsistent; type variables are quantified at top level, while kind variables are quantified locally. It is not at all easy to resurrect the old behaviour: the new data type for `HsType` simply can't express it, by design. All the implicit binders are in `HsImplicitBinders` which are at the top. This is only going to be notice by people who using higher-rank functions where the nested higher-rank type is itself kind-polymorphic. I don't think there are many such people. I'm strongly inclined not to worry. I'm copying Edward who is the person on the planet most likely to have explored this particular corner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 18:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 18:20:16 -0000 Subject: [GHC] #11127: Update cabal submodule to 1.22.5 In-Reply-To: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> References: <045.b86ccf3972e67654868d36d88f8530d9@haskell.org> Message-ID: <060.58d88994290922cc4c32b0b7f344a267@haskell.org> #11127: Update cabal submodule to 1.22.5 -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: task | Status: closed Priority: high | Milestone: 7.10.3 Component: libraries | Version: (other) | 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: Indeed, I managed to pull in the updated submodule before tagging the release. Looks like 7.10.3 will have a functional cabal afterall. Thanks for your patience everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 18:29:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 18:29:12 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck Message-ID: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- I wanted to see what error message might result from adding `join` to `Monad` and trying to derive it via `GeneralizedNewtypeDeriving`, so I used this code to simulate it: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module CoerceJoin where import qualified Control.Monad (join) import Data.Coerce (coerce) class MyMonad m where join :: m (m a) -> m a instance MyMonad Maybe where join = Control.Monad.join newtype MyMaybe a = MyMaybe (Maybe a) deriving MyMonad }}} To my surprise, this actually compiles: {{{ ==================== Derived instances ==================== Derived instances: instance CoerceJoin.MyMonad CoerceJoin.MyMaybe where CoerceJoin.join = GHC.Prim.coerce (CoerceJoin.join :: GHC.Base.Maybe (GHC.Base.Maybe a_axs) -> GHC.Base.Maybe a_axs) :: forall (a_axs :: *). CoerceJoin.MyMaybe (CoerceJoin.MyMaybe a_axs) -> CoerceJoin.MyMaybe a_axs Generic representation: Generated datatypes for meta-information: Representation types: }}} That seemed really odd, given my understanding of roles, so I tried to implement this instance manually: {{{#!hs newtype MyMaybe a = MyMaybe (Maybe a) instance MyMonad MyMaybe where join = coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a }}} And now GHC will reject it: {{{ CoerceJoin.hs:18:10: Couldn't match representation of type `a0' with that of `a1' `a1' is a rigid type variable bound by an expression type signature: MyMaybe (MyMaybe a1) -> MyMaybe a1 at CoerceJoin.hs:18:10 arising from trying to show that the representations of `Maybe (Maybe a0) -> Maybe a0' and `MyMaybe (MyMaybe a1) -> MyMaybe a1' are the same Relevant role signatures: type role Maybe representational type role MyMaybe representational In the expression: coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a In an equation for `join': join = coerce (join :: Maybe (Maybe a) -> Maybe a) :: MyMaybe (MyMaybe a) -> MyMaybe a In the instance declaration for `MyMonad MyMaybe' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 18:37:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 18:37:04 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.b23794a2ea3bab81649485595a548ec8@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 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 rwbarton): Don't think there is a bug here. The GND is okay because `MyMaybe` is known to have a type parameter of representational role. The problem arises with types involving a variable monad, since we cannot or do not want to require all monads be representational. Your manual implementation is wrong because `a` does not refer to the type you want it to (compare `myid :: a -> a; myid x = x :: a`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 18:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 18:50:09 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.e3ffa945477ff8c156f084d356edfd85@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 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 rwbarton): Well, I suppose there is still a bug in that the derived instance is not valid Haskell source as displayed, but there are other issues with it already (like the use of the qualified name `CoerceJoin.join`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 19:39:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 19:39:38 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.6ac3f5f49262a7d27436f7751d8c4715@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #9123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #9123 Comment: Oops, I overlooked the `forall (a_axs :: *)` part. It turns out that (and some language extensions) are needed to make the generated code compile when typed out manually: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} module CoerceJoin where import qualified Control.Monad (join) import Data.Coerce (coerce) class MyMonad m where join :: m (m a) -> m a instance MyMonad Maybe where join = Control.Monad.join newtype MyMaybe a = MyMaybe (Maybe a) instance MyMonad MyMaybe where join = coerce (join :: Maybe (Maybe a) -> Maybe a) :: forall (a :: *). MyMaybe (MyMaybe a) -> MyMaybe a }}} Also, I think the issue I was trying to reproduce is #9123, so I'll add that to the related tickets as evidence that adding `join` to `Monad` ''would'' cause some trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 20:06:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 20:06:59 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.0d4ae9b34531548671ae223114dea7e6@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new 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:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1558 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 22:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 22:42:27 -0000 Subject: [GHC] #10846: PartialTypeSignatures change implicit CallStack behavior In-Reply-To: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> References: <053.4274e891f1314fe985c1165bde8fc4e5@haskell.org> Message-ID: <068.fa116b8ee2d3ff4e34efe5ee629e7316@haskell.org> #10846: PartialTypeSignatures change implicit CallStack behavior -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | 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:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1422 Comment: This seems to be fixed by 1e041b7, but I've added a test-case in my patch for the slightly related #10845. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 22:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 22:42:52 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.cf2881f89e83b5f8b84b53149e4afc14@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 22:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 22:52:18 -0000 Subject: [GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error In-Reply-To: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> References: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> Message-ID: <064.5e3616fc2f6f4b873751a0d2c98457e6@haskell.org> #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I see that commit 1e041b7 addresses this issue and fixes the 'unbound implicit parameter' error (thanks!!), but ghc still refuses to compile `f2`. {{{ % ./inplace/bin/ghc-stage2 Bad.hs [1 of 1] Compiling Bad ( Bad.hs, Bad.o ) Bad.hs:9:1: error: ? Could not deduce: ?loc::t from the context: ?loc::Int bound by the inferred type for ?f2?: (?loc::Int) => t at Bad.hs:9:1-9 ? When checking that the inferred type f2 :: forall t. (?loc::t) => t is as general as its (partial) signature f2 :: forall t. (?loc::Int) => t }}} I think this error is still bogus, because ghc should not have inferred {{{ f2 :: forall t. (?loc::t) => t }}} in the first place. It should have inferred {{{ f2 :: (?loc::Int) => Int }}} which is a valid instantiation of the partial signature, and so should be OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 1 23:41:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Dec 2015 23:41:48 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.e37129d59df784c78a62cc0b395f1758@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * cc: george.karachalias@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 01:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 01:18:43 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.0ff08bbdf1043f4ef0abf5178679c7c5@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): Phab:D1561 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1561 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 08:56:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 08:56:48 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.05eecbeb565c8a2e3ebeb231e37ce8ba@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by niteria): @nomeata asked me to post an update, so here it goes. > What remains to be done, are the remaining problems solved (and just need doing)? So far I've only seen a recurring theme of non-deterministic uniques affecting the order of constructs in the code, like abstracted variables in a lambda. I believe the other problems have been solved before I started to work on this. This core of the problem is the `Ord` instance for `Unique`. It's used for: unique maps, computing SCCs, computing free variables, normalizing by sorting and type comparison. There are many instances of that, I'm sure I haven't discovered all of them yet, but conceptually the problem is rather simple and it's just a matter of putting the work. There's progress here, right now (I have some local patches) all 60 of the packages that I picked from stackage and still build with GHC HEAD rebuild deterministically. What I mean by that is that if you remove just the .o files, leaving existing .hi files, and start the build again you end up with the same result. I've recently shifted my focus from external packages, to GHC's tests since they offer nice small pieces of code. Here my method is a bit different, I run the tests with unique allocation reversed and compare the interface files. I've recently gone from 156 differing .hi files down to 26. All of these metrics are flawed in their own way and can fluctuate, so take them with a grain of salt. > Are there issues without a known solution so far? * Performance - so far I've spent a lot of time ensuring the performance is within the same ranges as before, forcing me to improve the free variable computation for example. In principle I could replace all the unique maps with deterministic unique maps and get a big chunk of non- determinism eliminated. The problem is that deterministic unique maps have a slower union operation and have to have extra memory to keep order. I've tried that and the cost was about 10% slower compilation times on `text` and `aeson`. So a lot of work is in just not creating regressions. * Ensuring that it stays fixed - so far this relies on tests which might be brittle + comments on places that I had to fix. It's a bit unsatisfying, I'd prefer a solution enforced by the compiler, like `Unique` not having an `Ord` instance. > The focus is now on reproducible interface files, what would it take to have reproducible binaries? I haven't looked much into that, but my gut feeling is that it's exactly the same problem, but you need to care about the passes after the core as well. I suspect you can get determinism today, if you don't do incremental builds and your build system builds single threaded. The external factor that affects the allocation of uniques is presence/absence of interface files. > Are there areas of work where you could need some extra help? So far my bottleneck has been making my patches mergeable in the sense of clean code and performance. Since the fixes stack on top of each other, because many files are a manifestation of more than one bug I think the easiest way to collaborate would be if I shared my unfinished patches and someone else ensured it's still performant enough and well documented. I've recently created #11148, which I believe is a bit more than a determinism bug, I've tried to look into it, but it was over my head, so that might be a more exciting way to pitch in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 09:18:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 09:18:40 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.fa2dd39129ac2977c11c31edf44af790@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` > is moving into `Prelude` with future GHCs. > > Throughout GHC's source there are related pretty-printing operators with > subtly different `infixr/infixl`-declarations. > > It would be desirable to unify those and possibly use `Semigroup((<>))` > instead (where `<>` represents a semigroup/monoid operation anyway) > > Otoh, existing code using `<>` assumes a different fixity, so it may make > sense to start by renaming the unconventional `<>`s into something else. > > Modules affected: > > - `Outputable` (ghc) > - `Pretty` (ghc) > - `Language.Haskell.TH.PprLib` (template-haskell) New description: This ticket is motivated by GHC's new `-fwarn-semigroup`, and that `<>` is moving into `Prelude` with future GHCs. Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) Otoh, existing code using `<>` assumes a different fixity (Monoid/Semigroup have `infixr 6 <>`), so it may make sense to start by renaming the unconventional `<>`s into something else. Modules affected: - `Outputable`: default fixity, i.e. `infixl 9` (ghc) - `Pretty`: `infixl 6` (ghc) - `Language.Haskell.TH.PprLib`: `infixl 6` (template-haskell) Related discussion: https://github.com/haskell/pretty/issues/30 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 10:11:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 10:11:52 -0000 Subject: [GHC] #8098: Faulty Word64 arithmetic if optimized In-Reply-To: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> References: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> Message-ID: <058.88e3294721a6896117d576d47c079802@haskell.org> #8098: Faulty Word64 arithmetic if optimized ---------------------------------+------------------------------ Reporter: achp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed Comment: I am also unable to reproduce this. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 10:12:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 10:12:00 -0000 Subject: [GHC] #8098: Faulty Word64 arithmetic if optimized In-Reply-To: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> References: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> Message-ID: <058.13a1ffdcc59e7b93bab9a4ad89f09129@haskell.org> #8098: Faulty Word64 arithmetic if optimized ---------------------------------+----------------------------- Reporter: achp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | 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 bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 10:12:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 10:12:10 -0000 Subject: [GHC] #8098: Faulty Word64 arithmetic if optimized In-Reply-To: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> References: <043.d067264d1cf6ef50f1513538a18a9ad6@haskell.org> Message-ID: <058.cd3f653b7a8a0141148e1b46ae1c2810@haskell.org> #8098: Faulty Word64 arithmetic if optimized ---------------------------------+------------------------------ Reporter: achp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: worksforme | 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 bgamari): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 11:34:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 11:34:50 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.e43511d45602d8f14ff8ee464f1a57d3@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #9123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, #9123 is a serious, open issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 12:54:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 12:54:59 -0000 Subject: [GHC] #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy Message-ID: <045.b8eb2c07dd94bd4b761d87f0dd3ec4bc@haskell.org> #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy -----------------------------------------+--------------------------------- Reporter: blippy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I issued the command: stack install lens hoping to upgrade to lens-4.13 and I received the following error log: GHC runtime linker: fatal error: I found a duplicate definition for symbol _hsprimitive_memcpy whilst processing object file C:\apps\HaskellPlatform\7.10.2-a\lib\extralibs\primitive-0.6\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-mingw32): loadObj "C:\\apps\\HaskellPlatform\\7.10.2-a\\lib\\extralibs\\primitive-0.6\\HSprimitive-0.6-3d4UsQu7pJCEtlsxN3gLjk.o": failed 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 Wed Dec 2 13:18:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 13:18:24 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.cbf776a9f00f1ba03941785f567dffa8@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"218fdf92370021b900af1e78323764cceb7ac609/ghc" 218fdf9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="218fdf92370021b900af1e78323764cceb7ac609" Make the order of fixities in the iface file deterministic This normalizes the order of written fixities by sorting by `OccName` making it independent of `Unique` order. Test Plan: I've added a new testcase Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1557 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 13:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 13:22:21 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.4756a781bf88851f3551610fc906271a@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: jlengyel Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was closed (a bit unintentionally) with 72e362076e7ce823678797a162d0645e088cd594. Regardless, I think the patch is in pretty good shape. Unfortunately it is attributed to me, whereas it is largely jlengyel's work. Thanks jlengyel and sorry about the lack of credit! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 14:09:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 14:09:44 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.e825901341dc05d5802b9e151d2b30a7@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"741f837d652fd00671614d52a6cb16fbc3758480/ghc" 741f837d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="741f837d652fd00671614d52a6cb16fbc3758480" Implement more deterministic operations and document them I will need them for the future determinism fixes. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin, hvr, simonmar Reviewed By: simonpj, simonmar Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1537 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 14:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 14:16:15 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X Message-ID: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- I followed the instructions on the Haskell wiki "GHC/As a library" to compile a Haskell file: '''Main.hs''' {{{#!hs import GHC import GHC.Paths ( libdir ) import DynFlags main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "test.hs" Nothing setTargets [target] load LoadAllTargets }}} '''test.hs''' {{{#!hs main = putStrLn "hello" }}} I compile with ghc -package ghc -package ghc-paths --make Main.hs. When I execute ./Main, I get the following linking error: {{{ ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _szZ_info from test.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie final section layout: __TEXT/__text addr=0x100000D40, size=0x00000206, fileOffset=0x00000D40, type=1 __TEXT/__stubs addr=0x100000F46, size=0x0000001E, fileOffset=0x00000F46, type=28 __TEXT/__stub_helper addr=0x100000F64, size=0x00000042, fileOffset=0x00000F64, type=32 __TEXT/__const addr=0x100000FA8, size=0x0000000C, fileOffset=0x00000FA8, type=0 __TEXT/__eh_frame addr=0x100000FB8, size=0x00000040, fileOffset=0x00000FB8, type=19 __DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=30 __DATA/__got addr=0x100001028, size=0x00000010, fileOffset=0x00001028, type=29 __DATA/__nl_symbol_ptr addr=0x100001038, size=0x00000010, fileOffset=0x00001038, type=29 __DATA/__la_symbol_ptr addr=0x100001048, size=0x00000028, fileOffset=0x00001048, type=27 __DATA/__const addr=0x100001070, size=0x00000028, fileOffset=0x00001070, type=0 __DATA/__data addr=0x100001098, size=0x00000060, fileOffset=0x00001098, type=0 __DATA/__common addr=0x1000010F8, size=0x00000020, fileOffset=0x00000000, type=25 ld: 32-bit RIP relative reference out of range (-4294970840 max is +/-4GB): from _szZ_info (0x100000D98) to _ghczmprim_GHCziCString_unpackCStringzh_closure at 0x0004A460 (0x00000000) in '_szZ_info' from test.o for architecture x86_64 clang-3.6: error: linker command failed with exit code 1 (use -v to see invocation) }}} I'm running the Nix package manager on MacOS X. Here are the compiler and linker commands for the GHC-API case. {{{ *** Assembler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s -o test.o Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_3.c Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_1.s link: linkables are ... LinkableM (2015-12-02 09:23:41 UTC) Main [DotO test.o] Linking test ... *** C Compiler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__ *** Linker: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store /vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -Wl,-rpath -Wl,/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -Wl,-rpath -Wl,/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94627_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw-ghc7.10.2 -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2 -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2 -lHSrts-ghc7.10.2 -lffi -liconv -lgmp -lm -ldl }}} And here is the compilation command for vanilla GHC: {{{ *** Assembler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s -o test.o Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_3.c Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_1.s link: linkables are ... LinkableM (2015-12-02 09:21:48 UTC) Main [DotO test.o] Linking test ... *** C Compiler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__ *** Linker: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store /vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc94206_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -liconv -lgmp -lm -ldl }}} I noticed the following differences: Some of the linked libraries in the API case contain a -ghc7.10.2 suffix, e.g. -lHSrts-ghc7.10.2. When I execute the linking command without the suffix everything works fine. So I looked into the directories of the referenced libraries. The rts directory contains the following content: {{{ libCffi.a libCffi_debug.a libCffi_l.a libCffi_p.a libCffi_thr.a libCffi_thr_debug.a libCffi_thr_l.a libCffi_thr_p.a libHSrts-ghc7.10.2.dylib libHSrts.a libHSrts_debug-ghc7.10.2.dylib libHSrts_debug.a libHSrts_l-ghc7.10.2.dylib libHSrts_l.a libHSrts_p.a libHSrts_thr-ghc7.10.2.dylib libHSrts_thr.a libHSrts_thr_debug-ghc7.10.2.dylib libHSrts_thr_debug.a libHSrts_thr_l-ghc7.10.2.dylib libHSrts_thr_l.a libHSrts_thr_p.a libffi.dylib }}} It seams that only the library with the .dylib extension also have the `-ghc7.10.2` suffix in the file name. So, is this an issue with ghc, MacOS X or Nix? Best, Sven -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 14:48:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 14:48:17 -0000 Subject: [GHC] #5850: Greater customization of GHCi prompt In-Reply-To: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> References: <050.bf03c3e2cbefdd0fabbaa545b275f2dc@haskell.org> Message-ID: <065.3590d3abac26570cebd39454a88a5fe3@haskell.org> #5850: Greater customization of GHCi prompt -------------------------------------+------------------------------------- Reporter: JamesFisher | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9994 | Differential Rev(s): Phab:D623 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: jlengyel => * status: closed => new * resolution: fixed => Comment: Unfortunately the patch that was previously merged intermittently hung for me. I've reverted it in d00cdf237f28d72df74157bfdf30e623786b68c3 and may return to this eventually. This shouldn't stop others from having a look, of course! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 17:28:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 17:28:55 -0000 Subject: [GHC] #11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info" Message-ID: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> #11155: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 error popped up when Alan was coding the solution for #11028. The error is utterly unrelated to what Alan was working on. Here's a reproducer {{{ {-# OPTIONS_GHC -O -fno-full-laziness #-} module Main where foo :: Bool {-# NOINLINE foo #-} foo = error "rk" bar x = let t :: Char t = case foo of { True -> 'v'; False -> 'y' } in [t] main = print (bar ()) }}} Just compile that and you get {{{ Foo.o: In function `c1Sm_info': (.text+0x29a): undefined reference to `stg_ap_0_upd_info' }}} Why do we get that unresolved symbol? The STG code for `bar` looks like {{{ Main.bar :: forall t_aup. t_aup -> [GHC.Types.Char] [GblId, Arity=1, Str=DmdType m2, Unf=OtherCon []] = \r srt:SRT:[rf :-> Main.foo] [x_s1RR] let { sat_s1RT [Occ=Once] :: GHC.Types.Char [LclId, Str=DmdType] = \u srt:SRT:[rf :-> Main.foo] [] Main.foo; } in : [sat_s1RT GHC.Types.[]]; }}} Look at that: an updatable thunk saying `sat_s1RT = Main.foo`! The error message is terrible, but the problem is a thunk whose only payload is a single variable. Why does that happen? The Core is {{{ bar = \ (@ t_aup) _ -> let t::Char = case foo of wild_00 { } in : @ Char t ([] @ Char) }}} The `case` is needed to change `foo`'s type from `Bool` to `Char`. The Core-to-STG pass drops the empty case alternatives as useless (rightly), but leaves a bare variable as the RHS, which confuses the code generator. We should clearly substitute `Main.foo` for `t`, either in Core-to-STG, or during code generation. Why hasn't this happened before now? It is quite hard to provoke, because floating the thunk for `t` to top level stops it happening. So it only happens if you switch off full laziness (as my test case here does), or if some very delicate inlining happens after the last float-out. The latter is very rare, but it's what happened to Alan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 17:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 17:29:44 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" (was: Trivial error thunk gives "undefined reference to stg_ap_0_upd_info") In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.2ea8ddcf15d8ccaa1c124066999d3726@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 19:39:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 19:39:27 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.f27063d81efb7f818a7b0da76cc6508f@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.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:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 20:38:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 20:38:30 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.8c3d91a324a7fbc9a577ffc2e896e0ea@haskell.org> #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) -------------------------------------+------------------------------------- Reporter: woehr | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a12e47bed74e305b37e68014c52feba3dd075514/ghc" a12e47be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a12e47bed74e305b37e68014c52feba3dd075514" Avoid panic due to partial ieName HsImpExp.ieName is partial and fails when given e.g. `module X` solution: use ieNames instead which returns a list of names instead of a single name. Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D1551 GHC Trac Issues: #11077 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 20:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 20:40:27 -0000 Subject: [GHC] #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) In-Reply-To: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> References: <044.b5e110944e8e8d0263744f093ade93e9@haskell.org> Message-ID: <059.f75540418fcfbc16083a58a2708bdfe1@haskell.org> #11077: ghc panic: ieName failed pattern match (-fwarn-missing-exported-sigs) -------------------------------------+------------------------------------- Reporter: woehr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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): Phab:D1551 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * differential: => Phab:D1551 * resolution: => fixed * milestone: => 8.0.1 Comment: Merged, thanks for the patch Eric! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 20:55:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 20:55:59 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.2df36696f3ef80bc25cae18b459ed695@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8cba907ad404ba4005558b5a8966390159938172/ghc" 8cba907a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8cba907ad404ba4005558b5a8966390159938172" Create empty dump files when there was nothing to dump This patch creates empty dump file when GHC was run with `-ddump-rule-firings` (or `-ddump-rule-rewrites`) and `-ddump-to-file` specified, and there were no rules applied. If dump already exists it will be overwritten by empty one. Test Plan: ./validate Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1514 GHC Trac Issues: #10320 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 21:04:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 21:04:28 -0000 Subject: [GHC] #11156: Type-changing record update catch-all in sum type doesn't typecheck Message-ID: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> #11156: Type-changing record update catch-all in sum type doesn't typecheck -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- Apologies for the confusing title/summary, but that is about as succinct as I could be. Rather than try to describe this in english, here is the smallest example I could repro with. I want to write this: {{{ import Data.Char data R a = Foo { x :: a, y :: a } | Bar { x :: a } | Baz { x :: a } ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify r = r { x = ord (x r) } }}} But that fails to typecheck: {{{ $ ghci Test.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:10:21: Couldn't match type ?Char? with ?Int? Expected type: R Int Actual type: R Char In the expression: r In the expression: r {x = ord (x r)} Failed, modules loaded: none. }}} Instead, I have to resort to enumerating all the remaining constructors: {{{ import Data.Char data R a = Foo { x :: a, y :: a } | Bar { x :: a } | Baz { x :: a } ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify (Bar x) = Bar (ord x) ordify (Baz x) = Baz (ord x) }}} The sum type has the property that every constructor has the field x, and some constructors have fields which are also parameterized over x's type 'a'. I would expect my first example, with the catch-all record-update to typecheck, but it doesn't. I suspect GHC thinks the catch-all case of ordify might be passed a Foo constructor, in which case the record update would be ill-typed, even though that is impossible due to the first case matching Foo explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 21:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 21:30:54 -0000 Subject: [GHC] #11156: Type-changing record update catch-all in sum type doesn't typecheck In-Reply-To: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> References: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> Message-ID: <061.d013454732b337a1ef5cea9240797529@haskell.org> #11156: Type-changing record update catch-all in sum type doesn't typecheck -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 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: GHC typechecks this {{{ ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify r = r { x = ord (x r) } }}} as if you had written this: {{{ ordify :: R Char -> R Int ordify r@(Foo {}) = r { x = ord (x r), y = ord (y r) } ordify r = case r of Foo x y -> Foo (ord x) y -- Eeek! Bar x -> Bar (ord x) Baz x -> Bar (ord x) }}} The `Eeek!` line elicits the complaint. You may say that the `Foo` case is already dealt with, so this branch of the case is dead code, but in general that require sophisticated reasoning, certainly more than the type checker can do. So I don't see a way to fix this; sorry. I'll close as "invalid" because GHC is behaving as advertised; but the goal is not invalid of course! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 21:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 21:44:41 -0000 Subject: [GHC] #11156: Type-changing record update catch-all in sum type doesn't typecheck In-Reply-To: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> References: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> Message-ID: <061.db31c11b0b6ebb74ba2536411ef0d529@haskell.org> #11156: Type-changing record update catch-all in sum type doesn't typecheck -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is analogous to wanting this function to typecheck: {{{ plusOne :: Int -> Int plusOne n = if True then n + 1 else 'A' -- unreachable }}} But the Haskell 98/Haskell 2010 standard says it should not typecheck: "The type of e1 must be Bool; e2 and e3 must have the same type, which is also the type of the entire conditional expression." The same for the original program, though the typing rules for record update are more complicated. But they similarly do not depend on knowledge about the value of the record-to-be-updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 21:44:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 21:44:54 -0000 Subject: [GHC] #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) Message-ID: <046.f3343909017e4c8a715a7e1591804072@haskell.org> #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: jachymb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- I try to compile the example from https://wiki.haskell.org/Prime_numbers#Using_ST_Array {{{#!hs {-# OPTIONS_GHC -O2 #-} import Control.Monad import Control.Monad.ST import Data.Array.ST import Data.Array.Unboxed sieveUA :: Int -> UArray Int Bool sieveUA top = runSTUArray $ do let m = (top-1) `div` 2 r = floor . sqrt $ fromIntegral top + 1 sieve <- newArray (1,m) True -- :: ST s (STUArray s Int Bool) forM_ [1..r `div` 2] $ \i -> do isPrime <- readArray sieve i when isPrime $ do -- ((2*i+1)^2-1)`div`2 == 2*i*(i+1) forM_ [2*i*(i+1), 2*i*(i+2)+1..m] $ \j -> do writeArray sieve j False return sieve }}} I get the following error: {{{ [1 of 1] Compiling Main ( p111.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): floatExpr tick break<29>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The error does not happen if I remove the OPTIONS_GHC -O2 directive. I use ArchLinux and the GHC compiled package from it's standard repositories. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 22:25:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 22:25:39 -0000 Subject: [GHC] #11156: Type-changing record update catch-all in sum type doesn't typecheck In-Reply-To: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> References: <046.06ab1cb2745d78c6efdeeebac275f7f0@haskell.org> Message-ID: <061.23c7e8490cd9adf4b9ea1b3ac20a3e26@haskell.org> #11156: Type-changing record update catch-all in sum type doesn't typecheck -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Comment (by afarmer): Yeah, I figured it wouldn't be easy to fix, and the workaround isn't too onerous. However, it does seem like a bit of a wart. I had to stare at it for many minutes before I realized what was probably going on... the error seems really non-obvious unless you understand how record updates desugar, so I just wanted to document it. I wondered if the new overlapping/missing patterns algorithm could be adapted to spot the impossible case, but I'm sure the effort-to-payoff ratio is much too high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 2 22:45:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Dec 2015 22:45:51 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.1d7d962acaae1d7c0de27c0daa0df2d1@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This patch breaks things; try `-ddump-to-file -ddump-simpl`, it's failing with: {{{ Main.dump-simpl: hPutStr: illegal operation (handle is closed) }}} I had to comment out `bracket_`s first argument that closes handles. It seems like it's closing handles too soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 09:04:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 09:04:31 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.90ae4efed91084bab58cfc866a7f17a0@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high Comment: Fyi, I'm seeing this during GHC building as well (which makes the current Ubuntu PPA nightlies fail): {{{ ... AR compiler/stage2/build/libHSghc-7.11.20151202.a HC [stage 1] compiler/stage2/build/libHSghc-7.11.20151202-ghc7.11.20151202.so /usr/bin/ar: creating compiler/stage2/build/libHSghc-7.11.20151202.a Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. "rm" -f compiler/stage2/build/libHSghc-7.11.20151202.a.contents HC [stage 1] ghc/stage2/build/GhciTags.dyn_o HC [stage 1] ghc/stage2/build/InteractiveUI.dyn_o HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. /?PKGBUILDDIR?/compiler/stage2/build/libHSghc-7.11.20151202-ghc7.11.20151202.so: undefined reference to `stg_ap_0_upd_info' collect2: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) make[3]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make[2]: *** [all] Error 2 make[2]: Leaving directory `/?PKGBUILDDIR?' make[1]: *** [override_dh_auto_build] Error 2 make[1]: Leaving directory `/?PKGBUILDDIR?' make: *** [build] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 09:35:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 09:35:01 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.73e28babeea0fc891cfc3a42dda01341@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tvv): It happens because I forgot to clear map in `closeDumpFiles`. And yes, looks like I picked the wrong place to close handles. This patch should help to avoid the error: {{{ diff --git a/compiler/main/ErrUtils.hs b/compiler/main/ErrUtils.hs index 5e585da..2d29452 100644 --- a/compiler/main/ErrUtils.hs +++ b/compiler/main/ErrUtils.hs @@ -333,8 +333,11 @@ openDumpFiles dflags -- closeDumpFiles :: DynFlags -> IO () closeDumpFiles dflags - = do gd <- readIORef $ generatedDumps dflags + = do + let gdref = generatedDumps dflags + gd <- readIORef gdref mapM_ hClose $ Map.elems gd + writeIORef gdref Map.empty -- | Write out a dump. -- If --dump-to-file is set then this goes to a file. }}} but the compiler will produce incomplete dumps in some cases. Let me check it again and I will re-submit the patch. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 10:34:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 10:34:08 -0000 Subject: [GHC] #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) In-Reply-To: <046.f3343909017e4c8a715a7e1591804072@haskell.org> References: <046.f3343909017e4c8a715a7e1591804072@haskell.org> Message-ID: <061.8d4728ce7568f2105bfc6e27676c3857@haskell.org> #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: jachymb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): Perhaps a dup of #10549, #10948? Try with 7.10.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 10:58:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 10:58:38 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial Message-ID: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Look at `CoreUtils.exprIsTrivial` and `CorePrep.cpe_ExprIsTrivial`. They are identical! The latter has a comment saying {{{ cpe_ExprIsTrivial :: CoreExpr -> Bool -- Version that doesn't consider an scc annotation to be trivial. }}} but the code does not treat ticks any differently. So the question is: '''are they supposed to be different'''? And if not, can we just combine them? Peter W, Simon M: this is your territory. I don't understand tick stuff well enough. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:00:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:00: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.1c0527dbb61d1a7ff7a68c9645ce39d8@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => scpmw * priority: normal => high * milestone: => 8.0.1 Comment: I'll put it as high priority because it should be quick and easy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #322: fromInteger-related pattern match overlap warnings In-Reply-To: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> References: <047.ace5220e5df89abf8e6e92924cc2e86b@haskell.org> Message-ID: <062.0ee7d03a8ec723075bf3d469b455c056@haskell.org> #322: fromInteger-related pattern match overlap warnings -------------------------------------+--------------------------------- Reporter: ashley-y | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4 Resolution: duplicate | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: ds060 Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies In-Reply-To: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> References: <046.dc47e7f5e7f289f268ba58d8b6a0f95e@haskell.org> Message-ID: <061.7d6b81fe465f223afb561b37064e8982@haskell.org> #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies -------------------------------------------------+------------------------- Reporter: tensor5 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect warning at | Unknown/Multiple compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3927 #6124 | -------------------------------------------------+------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #3078: Erroneous warnings for -XPatternGuards In-Reply-To: <044.c8833b905baf8d82852a2d8c84929df0@haskell.org> References: <044.c8833b905baf8d82852a2d8c84929df0@haskell.org> Message-ID: <059.7faee959344672f3bb35566f1178911e@haskell.org> #3078: Erroneous warnings for -XPatternGuards ------------------------------+------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Test Case: | ------------------------------+------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> References: <047.57470c7515f5d78414f8813f455c57a5@haskell.org> Message-ID: <062.b4616a6deb1df49250e1196e07ed0375@haskell.org> #2204: Improve 'patterns not matched' warnings -------------------------------------+------------------------------------- Reporter: Deewiant | Owner: Type: feature request | Status: closed Priority: low | Milestone: ? Component: Compiler | Version: 6.8.2 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): -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #4139: Spurious non-exhaustive pattern match warnings are given using GADTs In-Reply-To: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> References: <046.a84202da85a5f9cbf5e28e3e31df006a@haskell.org> Message-ID: <061.880c22ad5e4106997bbde0a2d71cb994@haskell.org> #4139: Spurious non-exhaustive pattern match warnings are given using GADTs -------------------------------------+------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: GADTs, warnings, | pattern matching Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: #3927 | -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.9485d7500e6fe3e3ebb81a45c676ecb9@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4139 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.99be60885d1ec5c497ec0fd49fd0b023@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #9951: OverloadedLists breaks exhaustiveness check In-Reply-To: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> References: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> Message-ID: <063.5bbc4215a5ac5da29e1d3064746b054d@haskell.org> #9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 11:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 11:58:00 -0000 Subject: [GHC] #5724: Confusing warning message for incomplete patterns In-Reply-To: <052.c4247f3fcd6acd7f8e305482ba8dc328@haskell.org> References: <052.c4247f3fcd6acd7f8e305482ba8dc328@haskell.org> Message-ID: <067.328a0efb8ce4442cade58e413756ab75@haskell.org> #5724: Confusing warning message for incomplete patterns -------------------------------------+--------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by George Karachalias ): In [changeset:"8a506104d5b5b71d5640afc69c992e0af40f2213/ghc" 8a506104/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a506104d5b5b71d5640afc69c992e0af40f2213" Major Overhaul of Pattern Match Checking (Fixes #595) This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 13:09:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 13:09:47 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.22fa8677bf7ea05af7627f0415833efb@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I tried to add a test for this, unfortunately as far as I can see this only happens when GHC panics(CoreLint errors may also trigger this, but I couldn't try this yet). Does anyone know a good way to add a test for this? In the meantime, can we revert this patch until someone comes up with a proper solution that works even when GHC panics? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 13:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 13:42:11 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.c61762220b7d481b5e1f76e3265b6a41@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: tvv Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tvv): How about to switch back to Phab:D1514:5330? It fixes the ticket's issue and does not introduce any side-effects like described. We can leave the dump optimization task as feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 15:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 15:17:06 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload Message-ID: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Hi, I would like to use a custom print function. I tried all possible ways for setting it: (1) running ghci -interactive-print myPrint; (2) adding ':set -interactive-print myPrint' to ~/.ghci; (3) typing ':set -interactive- print myPrint' interactively. It works, but only before :load or :reload. After that,it's forgotten (standard print used again) and I have to type ':set -interactive-print myPrint' again. Is there a way to make this setting persistent, i. e. survive after :load or :reload? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 15:18:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 15:18:58 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.748b2510f43b32ed0c26a49e7960560d@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by hukarere): * version: 7.10.2 => 7.6.3 Comment: I forgot to mention my version of ghc: 7.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 15:41:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 15:41:52 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.2f37591b2ced18728da7f94449754346@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 15:51:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 15:51:04 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.ca2bdcc1861f22fb7f21eab2243ff1ff@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * related: => #11155 Comment: The haddock linker failure in Phab:D1558 is due to #11155 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 16:24:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 16:24:59 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.5269ea6a64b3f1e726b1d07b902f04a3@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Matt): * status: new => patch * differential: => D1564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 16:30:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 16:30:25 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.967f874c8ed93c8a5019647fe38ebfee@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D1564 => Phab:D1564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 19:04:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 19:04:53 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.d0768def32f010886b0e981493fc0b3f@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Sorry, haven't had much time lately to look at GHC the past weeks. I should have free time again next week and I'll try to get as much as my tickets done!. I think I have a proper solution for this for `8.0.1` that doesn't require me to change the code for all platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 20:10:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 20:10:16 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.7cb791c478e984202dd404c2a13223e8@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | 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): Phab:D1565 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1565 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 20:58:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 20:58:13 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.8f0923324405e997f5adfcc5765928a3@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 21:11:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 21:11:43 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.3ace8a975f6c9da56ef5cf493ece7a08@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 Sergei Trofimovich ): In [changeset:"a034031a102bc08c76a6cdb104b72922ae22c96b/ghc" a034031/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a034031a102bc08c76a6cdb104b72922ae22c96b" extending_ghc.rst: fix broken link (Trac #10950) The error exibits as build failures of two types: 1. extending_ghc.rst:: ERROR: Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs. 2. reading sources... [ 33%] glasgow_exts Exception occurred: pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL) RecursionError: maximum recursion depth exceeded while pickling an object Broken link created circular reference and failed to serialize the result. Fixed the problem by pointing to relevant section. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 21:29:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 21:29:07 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.36d48055749c6d8eaa5f2e561aa2d831@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 slyfox): * status: new => closed * resolution: => fixed Comment: I think empty link in form of {{{ `foo <>`__ }}} was able to make sphinx try to serialize bad parse state. Should be good now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 22:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 22:25:27 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.287279ef37bbc5e85569b89d20339a6d@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Old description: > The following program, extracted from the test exceptionsrun001, should > exit with exitcode 100. Instead, when compiled with `-O1`, it never gets > past the ioTest and somehow manages to exit with exitcode 0. > > {{{ > {-# LANGUAGE ScopedTypeVariables #-} > module Main where > > import Control.Exception > import System.IO.Error > import System.Exit > > main = do > ioTest > exitWith (ExitFailure 100) > > ioTest :: IO () > ioTest = (catch (ioError (userError "wibble")) > (\(e::IOException) -> return ()) > }}} > > I think this will require a git bisect: > * last known good commit: 34bb4605d4ec5b131df57ca4c91d6840b7539194 > * first known bad commit: f83aab95f59ae9b29f22fc7924e050512229cb9c. New description: The following program, extracted from the test exceptionsrun001, should exit with exitcode 100. Instead, when compiled with `-O1`, it never gets past the ioTest and somehow manages to exit with exitcode 0. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Main where import Control.Exception import System.IO.Error import System.Exit main = do ioTest exitWith (ExitFailure 100) ioTest :: IO () ioTest = (catch (ioError (userError "wibble")) (\(e::IOException) -> return ()) }}} I think this will require a git bisect: * last known good commit: 34bb4605d4ec5b131df57ca4c91d6840b7539194 * first known bad commit: f83aab95f59ae9b29f22fc7924e050512229cb9c. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 22:52:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 22:52:45 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 Message-ID: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The new exhaustiveness checker has broken `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one removes all but a few hundred of `foo`'s equations in the test things return to sanity. It appears that the compile time is scaling non-linearly with the number of equations, ||= no. equations =||= compile wall time =|| || 150 || 0.4 s || || 250 || 0.89 s || || 300 || 1.22 s || || 350 || 1.85 s || || 400 || 2.65 s || || 500 || 4.86 s || || 550 || 6.60 s || || 600 || 8.65 s || || 650 || 10.27 s || || 700 || 12.84 s || || 1000 || 38.51 s || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 22:55:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 22:55:10 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.d54a9cc0cb0cd6acb41468e302079bd6@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 bgamari): * cc: gkarachalias (added) * milestone: => 8.0.1 Old description: > The new exhaustiveness checker has broken > `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one > removes all but a few hundred of `foo`'s equations in the test things > return to sanity. It appears that the compile time is scaling non- > linearly with the number of equations, > > ||= no. equations =||= compile wall time =|| > || 150 || 0.4 s || > || 250 || 0.89 s || > || 300 || 1.22 s || > || 350 || 1.85 s || > || 400 || 2.65 s || > || 500 || 4.86 s || > || 550 || 6.60 s || > || 600 || 8.65 s || > || 650 || 10.27 s || > || 700 || 12.84 s || > || 1000 || 38.51 s || New description: The new exhaustiveness checker (8a506104d5b5b71d5640afc69c992e0af40f2213) has broken `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one removes all but a few hundred of `foo`'s equations in the test things return to sanity. It appears that the compile time is scaling non-linearly with the number of equations, ||= no. equations =||= compile wall time =|| || 150 || 0.4 s || || 250 || 0.89 s || || 300 || 1.22 s || || 350 || 1.85 s || || 400 || 2.65 s || || 500 || 4.86 s || || 550 || 6.60 s || || 600 || 8.65 s || || 650 || 10.27 s || || 700 || 12.84 s || || 1000 || 38.51 s || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 23:35:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 23:35:21 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.f472a38a5f09e68007710a9e330052b5@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 cost here comes from `pruneVSABound`, in particular the `Singleton` case in `go`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 3 23:58:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Dec 2015 23:58:15 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.608a22ea106c5b01627b94544f5d4931@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): More specifically it seems to be `TmOracle.tmOracle` which is the culprit. Perhaps this is one of these terrible worst-cases which the paper refers to? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 00:46:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 00:46:17 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.e67ad0ed9c4abb3fabf4a2f95bc178c9@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: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This pretty obviously won't make 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 00:53:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 00:53:32 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.458863421e62c36dafb2fb80b6f84b78@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: siddhanathan Type: task | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: This doesn't appear to be critical for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 00:58:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 00:58:19 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.d9264c1a497e691a7360ba2060339bcc@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: This won't be happening in 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:12:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:12:02 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.3d6721b0c5834c91692cea7d36ec4f65@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1152 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Record pattern synonym support has been merged. Moreover, a specification for the implemented syntax can be found on [[PatternSynonyms/RecordPatternSynonyms]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:12:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:12:31 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.df441b8890f6389f36ad9f5a61c5cb6f@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1152 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit 2a74a64e8329ab9e0c74bec47198cb492d25affb: {{{ Author: Matthew Pickering Date: Mon Oct 19 21:17:29 2015 +0100 Record pattern synonyms This patch implements an extension to pattern synonyms which allows user to specify pattern synonyms using record syntax. Doing so generates appropriate selectors and update functions. === Interaction with Duplicate Record Fields === The implementation given here isn't quite as general as it could be with respect to the recently-introduced `DuplicateRecordFields` extension. Consider the following module: {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE PatternSynonyms #-} module Main where pattern S{a, b} = (a, b) pattern T{a} = Just a main = do print S{ a = "fst", b = "snd" } print T{ a = "a" } In principle, this ought to work, because there is no ambiguity. But at the moment it leads to a "multiple declarations of a" error. The problem is that pattern synonym record selectors don't do the same name mangling as normal datatypes when DuplicateRecordFields is enabled. They could, but this would require some work to track the field label and selector name separately. In particular, we currently represent datatype selectors in the third component of AvailTC, but pattern synonym selectors are just represented as Avails (because they don't have a corresponding type constructor). Moreover, the GlobalRdrElt for a selector currently requires it to have a parent tycon. (example due to Adam Gundry) === Updating Explicitly Bidirectional Pattern Synonyms === Consider the following ``` pattern Silly{a} <- [a] where Silly a = [a, a] f1 = a [5] -- 5 f2 = [5] {a = 6} -- currently [6,6] ``` === Fixing Polymorphic Updates === They were fixed by adding these two lines in `dsExpr`. This might break record updates but will be easy to fix. ``` + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) - , pat_wrap = idHsWrapper } +, pat_wrap = req_wrap } ``` === Mixed selectors error === Note [Mixed Record Field Updates] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following pattern synonym. data MyRec = MyRec { foo :: Int, qux :: String } pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} This allows updates such as the following updater :: MyRec -> MyRec updater a = a {f1 = 1 } It would also make sense to allow the following update (which we reject). updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" This leads to confusing behaviour when the selectors in fact refer the same field. updater a = a {f1 = 1, foo = 2} ==? ??? For this reason, we reject a mixture of pattern synonym and normal record selectors in the same update block. Although of course we still allow the following. updater a = (a {f1 = 1}) {foo = 2} > updater (MyRec 0 "str") MyRec 2 "str" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:15:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:15:50 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.69492cd1fdbaa392cc78bcf3ea26463a@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 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: ekmett (added) Old description: > When asked to create a sufficiently large array ghci > coredumps. > > {{{ > \begin{code} > import Data.Array.ST > import Control.Monad.ST > import GHC.Base > > example = runST (do arr <- newArray (minInt,maxInt) > False > go arr) > where go :: STArray s Int Bool -> ST s Bool > go arr = readArray arr 3 > \end{code} > }}} > > Load this into ghci and type 'example'. New description: When asked to create a sufficiently large array ghci coredumps. {{{#!hs import Data.Array.ST import Control.Monad.ST import GHC.Base example = runST (do arr <- newArray (minInt,maxInt) False go arr) where go :: STArray s Int Bool -> ST s Bool go arr = readArray arr 3 }}} Load this into ghci and type 'example'. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:29:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:29:36 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.9885f88c44ac0f407cee93dceabe1852@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 gkaracha): * cc: gkarachalias (removed) * cc: gkaracha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:31:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:31:01 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 Message-ID: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: concurrent/prog001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #10711) leads me to believe that this patch is to blame. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:40:34 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.9e7b27fcc4a30912d78dbbcc5b59240c@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: thoughtpolice, do you have a patch for this? If not I'd say this won't happen for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:41:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:41:54 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.6d73224724b4c2bed116e58db4d5f3f6@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): * cc: gkarachalias (removed) * cc: gkaracha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:44:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:44:01 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 In-Reply-To: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> References: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> Message-ID: <061.b024c0f1e60d0cffdfd3efb37985592a@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gkaracha (added) * owner: => gkaracha Old description: > The new exhaustiveness checker appears to allocate until the machine runs > out of memory while compiling the `concurrent/prog001` testcase. In > particular it stalls while desugaring the `Thread` module. The fact that > this module contains non-trivial pattern matching, coupled with the > compiler gets stuck in `Desugar`, and the fact that I've noted other > performance issues with the new exhaustiveness checker (see #10711) leads > me to believe that this patch is to blame. New description: The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #11160) leads me to believe that this patch is to blame. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:44:32 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.43fd9812107b6ad8d588307ee189b6fc@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 bgamari): * owner: => gkaracha Comment: George thinks he has this one figured out and will work out a fix shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 01:44:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 01:44:54 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.6ffb26d90d4b61039706673214ae3dc1@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.9 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: | -------------------------------------+------------------------------------- Old description: > When asked to create a sufficiently large array ghci > coredumps. > > {{{#!hs > import Data.Array.ST > import Control.Monad.ST > import GHC.Base > > example = runST (do arr <- newArray (minInt,maxInt) False > go arr) > where go :: STArray s Int Bool -> ST s Bool > go arr = readArray arr 3 > }}} > > Load this into ghci and type 'example'. New description: When asked to create a sufficiently large array ghci coredumps. Edit: new example {{{#!hs import Data.Array.MArray import Data.Array.IO import Data.Word main = do m <- newArray_ (0,2^62-1) :: IO (IOUArray Int Word32) -- allocates 0 bytes writeArray m 17 12345 -- write wherever you like mapM (\x -> writeArray m x 0) [1..10000] -- core dump }}} Load this into ghci and type 'main'. -- Comment (by thomie): Update description with example from comment:15. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 02:01:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 02:01:27 -0000 Subject: [GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) In-Reply-To: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> References: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> Message-ID: <060.312a60cee92cf626a7a4be8acfa7267b@haskell.org> #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) -------------------------------------+------------------------------------- Reporter: carter | 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8287 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: This won't be happening for 8.0 I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 02:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 02:05:07 -0000 Subject: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure In-Reply-To: <052.f68490df51931cf0218e339e7abda5be@haskell.org> References: <052.f68490df51931cf0218e339e7abda5be@haskell.org> Message-ID: <067.29b132cf42610d18507e459a21c3358f@haskell.org> #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.6.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: ekmett (added) * milestone: 8.0.1 => 8.2.1 Old description: > When trying to use the custom handle infrastructure, hGetContents fails > like so: > > *** Exception: ToDo: hGetBuf > > This exception occurs twice in GHC.IO.Handle.Text > > The handle implementation I'm using is attached. > > It would be neat if I could pass along some witness that my device > implements RawDevice, then we could just run the same code that we use > for file-descriptors. But I'd be happy enough with a general solution, as > I just plan to use this for testing. New description: When trying to use the custom handle infrastructure, `hGetContents` fails like so: {{{ *** Exception: ToDo: hGetBuf }}} This exception occurs twice in `GHC.IO.Handle.Text` The handle implementation I'm using is attached. It would be neat if I could pass along some witness that my device implements `RawDevice`, then we could just run the same code that we use for file-descriptors. But I'd be happy enough with a general solution, as I just plan to use this for testing. -- Comment: This won't be happening for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 02:06:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 02:06:50 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.9dd7d141068ae5427a5490bb82745813@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't happen for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 02:10:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 02:10:21 -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.46f443076d68bfee091cf881fca1d27a@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 bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: This can wait. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 03:50:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 03:50:29 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.954400ce8a724060708a413dcd4ab81f@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #9123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): So, is there a bug here? I'm tempted to close, but I wanted to double- check. (And, yes, #9123 is a serious, open issue. I think there's a viable approach written up in the ticket, but it would need a fair bit of work -- and quite possibly a research paper -- to sort out.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 03:52:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 03:52:29 -0000 Subject: [GHC] #11152: GND accepts ill-roled coercion when manually defining it won't typecheck In-Reply-To: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> References: <050.c76b383ee7b6903f770ffb9fe38d643f@haskell.org> Message-ID: <065.0c5762053e5fc270506da2e65fb5489e@haskell.org> #11152: GND accepts ill-roled coercion when manually defining it won't typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #9123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't believe there's a new bug, no (and I think I closed this issue earlier). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 06:51:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 06:51:55 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.8f57d20397044b9cddcc90e0720100cf@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 George Karachalias ): In [changeset:"ae4398d64655b43606386dddb01637bbfcf0171e/ghc" ae4398d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae4398d64655b43606386dddb01637bbfcf0171e" Improve performance for PM check on literals (Fixes #11160 and #11161) Two changes: 1. Instead of generating constraints of the form (x ~ e) (as we do in the paper), generate constraints of the form (e ~ e). The term oracle (`tmOracle` in deSugar/TmOracle.hs) is not really efficient and in the presence of many (x ~ e) constraints behaves quadratically. For literals, constraints of the form (False ~ (x ~ lit)) are pretty common, so if we start with { y ~ False, y ~ (x ~ lit) } we end up givng to the solver (a) twice as many constraints as we need and (b) half of them trigger the solver's weakness. This fixes #11160. 2. Treat two overloaded literals that look different as different. This is not entirely correct but it is what both the previous and the current check did. I had the ambitious plan to do the *right thing* (equality between overloaded literals is undecidable in the general case) and just use this assumption when issuing the warnings. It seems to generate much more constraints than I expected (breaks #11161) so I just do it immediately now instead of generating everything and filtering afterwards. Even if it is not (strictly speaking) correct, we have the following: * Gives the "expected" warnings (the ones Ocaml or the previous algorithm would give) and, * Most importantly, it is safe. Unless a catch-all clause exists, a match against literals is always non-exhaustive. So, effectively this affects only what is shown to the user (and, evidently, performance!). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 06:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 06:51:56 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 In-Reply-To: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> References: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> Message-ID: <061.3c0198a546cee33577711637fabc6302@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George Karachalias ): In [changeset:"ae4398d64655b43606386dddb01637bbfcf0171e/ghc" ae4398d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae4398d64655b43606386dddb01637bbfcf0171e" Improve performance for PM check on literals (Fixes #11160 and #11161) Two changes: 1. Instead of generating constraints of the form (x ~ e) (as we do in the paper), generate constraints of the form (e ~ e). The term oracle (`tmOracle` in deSugar/TmOracle.hs) is not really efficient and in the presence of many (x ~ e) constraints behaves quadratically. For literals, constraints of the form (False ~ (x ~ lit)) are pretty common, so if we start with { y ~ False, y ~ (x ~ lit) } we end up givng to the solver (a) twice as many constraints as we need and (b) half of them trigger the solver's weakness. This fixes #11160. 2. Treat two overloaded literals that look different as different. This is not entirely correct but it is what both the previous and the current check did. I had the ambitious plan to do the *right thing* (equality between overloaded literals is undecidable in the general case) and just use this assumption when issuing the warnings. It seems to generate much more constraints than I expected (breaks #11161) so I just do it immediately now instead of generating everything and filtering afterwards. Even if it is not (strictly speaking) correct, we have the following: * Gives the "expected" warnings (the ones Ocaml or the previous algorithm would give) and, * Most importantly, it is safe. Unless a catch-all clause exists, a match against literals is always non-exhaustive. So, effectively this affects only what is shown to the user (and, evidently, performance!). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 09:34:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 09:34:09 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.2d20470d60b801e626e753537141c7d6@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): Very fast response thank you. Your commit message is very informative. Did you include the same information in a `Note` in the code, so that we don't lose the information here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 10:25:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 10:25:48 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.f98735344d04cd4d5988fcd4ad4d987f@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed Old description: > The new exhaustiveness checker (8a506104d5b5b71d5640afc69c992e0af40f2213) > has broken `tests/ghci/should_run/ghcirun004`, which now hangs in > desugaring. If one removes all but a few hundred of `foo`'s equations in > the test things return to sanity. It appears that the compile time is > scaling non-linearly with the number of equations, > > ||= no. equations =||= compile wall time =|| > || 150 || 0.4 s || > || 250 || 0.89 s || > || 300 || 1.22 s || > || 350 || 1.85 s || > || 400 || 2.65 s || > || 500 || 4.86 s || > || 550 || 6.60 s || > || 600 || 8.65 s || > || 650 || 10.27 s || > || 700 || 12.84 s || > || 1000 || 38.51 s || New description: The new exhaustiveness checker (8a506104d5b5b71d5640afc69c992e0af40f2213, Phab:D1535) has broken `tests/ghci/should_run/ghcirun004`, which now hangs in desugaring. If one removes all but a few hundred of `foo`'s equations in the test things return to sanity. It appears that the compile time is scaling non-linearly with the number of equations, ||= no. equations =||= compile wall time =|| || 150 || 0.4 s || || 250 || 0.89 s || || 300 || 1.22 s || || 350 || 1.85 s || || 400 || 2.65 s || || 500 || 4.86 s || || 550 || 6.60 s || || 600 || 8.65 s || || 650 || 10.27 s || || 700 || 12.84 s || || 1000 || 38.51 s || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 10:26:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 10:26:10 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 In-Reply-To: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> References: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> Message-ID: <061.c995f4b7f0dfc9ac1c7bbe0ea87cc06a@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 10:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 10:29:35 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker Message-ID: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: T783 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new pattern match checker (Phab:D1535) allocates 115% more than the previous checker on the T783 testcase, {{{ bytes allocated value is too high: Expected T783(normal) bytes allocated: 526230456 +/-10% Lower bound T783(normal) bytes allocated: 473607410 Upper bound T783(normal) bytes allocated: 578853502 Actual T783(normal) bytes allocated: 1134085384 Deviation T783(normal) bytes allocated: 115.5 % *** unexpected stat test failure for T783(normal) }}} I suspect this isn't avoidable as this testcase consists of nothing more than 500 guarded equations, so exercises the checker quite thoroughly. That being said, perhaps it's worth a closer look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 10:32:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 10:32:52 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.13ae82b39ec1631783c72836a95b8837@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by scpmw): From a quick scan through the Git history, that particular comment has been out of date for quite some time, starting with Simon M's tick overhaul in `7bb0447`, where {{{ Note [SCCs are trivial] ~~~~~~~~~~~~~~~~~~~~~~~ We used not to treat (_scc_ "foo" x) as trivial, because it really generates code, (and a heap object when it's a function arg) to capture the cost centre. However, the profiling system discounts the allocation costs for such "boxing thunks" whereas the extra costs of *not* inlining otherwise-trivial bindings can be high, and are hard to discount. }}} got replaced by {{{ Note [Tick trivial] ~~~~~~~~~~~~~~~~~~~ Ticks are not trivial. If we treat "tick x" as trivial, it will be inlined inside lambdas and the entry count will be skewed, for example. Furthermore "scc x" will turn into just "x" in mkTick. }}} Since then, `exprIsTrivial` has in fact been slightly more restrictive than `cpe_exprIsTrivial` concerning HPC ticks. When adding the exception for `SourceNote`s, I considered that an inconsistency. My vote would be to combine them - would have done it myself if I had spotted it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 10:51:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 10:51:06 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.b2224f619a9645fd1bb95f7728d648a5@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | 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 performance bug | Test Case: T783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): George, feel free to close this if you believe that there is no easy fix here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 11:48:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 11:48:48 -0000 Subject: [GHC] #11096: Builtin encoder/decoder should be used for Latin-1 In-Reply-To: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> References: <046.190f1bb041a581e8ef2d2a11405c3f20@haskell.org> Message-ID: <061.3cd1332321a334a04887ac8916c65486@haskell.org> #11096: Builtin encoder/decoder should be used for Latin-1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"36a208f44df4b3c1480e4b873efca75f6adae3b4/ghc" 36a208f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="36a208f44df4b3c1480e4b873efca75f6adae3b4" Use builtin ISO 8859-1 decoder in mkTextEncoding We already do this for UTF8/16/32, so it seems obvious do the same for the closely related popular ISO 8859-1 encoding, and avoid iconv issues on some platforms (such as AIX which which bundles a broken `libiconv` by default) This fixes #11096 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 12:55:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 12:55:23 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 Message-ID: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The new exhaustiveness checker drastically increases compile time of the `T5642` testcase. From the profile it appears that a great deal of time is being spent evaluating `Check.mkPmId.occname`, {{{ COST CENTRE MODULE %time %alloc mkPmId.occname Check 73.7 16.9 mkOneConFull Check 3.4 10.2 deSugar HscMain 2.8 14.8 mkOneConFull.arguments Check 2.5 5.5 pmTraverse Check 1.6 0.8 mkOneConFull.subst1 Check 1.5 5.9 wrapK.go Check 1.5 5.9 cMatcher Check 1.2 2.7 canEvVar TcCanonical 1.0 3.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 12:55:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 12:55:30 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.36b1d003f79cb030d726f7d9b4ffa546@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 bgamari): * owner: => gkaracha -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 12:57:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 12:57:51 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.8c282bcd5878b4195d215c0278f4e17a@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | 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 performance bug | Test Case: T783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e9220daf7dbbd1ee084296a0d486a62aca7f1dcf/ghc" e9220daf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9220daf7dbbd1ee084296a0d486a62aca7f1dcf" Bump allocations for T783 The new pattern match checker increased allocations by over 100%. Tracking in #11162. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 12:57:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 12:57:51 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.683bf5056a879ae8755416085780194c@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 Ben Gamari ): In [changeset:"dc33e4c65dc1587c265c698473f35f9843673cba/ghc" dc33e4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc33e4c65dc1587c265c698473f35f9843673cba" T5642 is broken This appears to be due to the new exhaustiveness checker. See #11163. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:06:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:06:11 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.6db4dc53d697869f6856c8882282ea54@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"5b2b7e338c822c34f86e8bd3ff442a979711d1fe/ghc" 5b2b7e33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b2b7e338c822c34f86e8bd3ff442a979711d1fe" Make callToPats deterministic in SpecConstr This fixes a non-determinism bug where where depending on the order of uniques allocated, the specialized workers would have different order of arguments. Compare: ``` $s$wgo_s1CN :: Int# -> Int -> Int# [LclId, Arity=2, Str=DmdType ] $s$wgo_s1CN = \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) -> case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] { False -> $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ); True -> 0# } ``` vs ``` $s$wgo_s18mTj :: Int -> Int# -> Int# [LclId, Arity=2, Str=DmdType ] $s$wgo_s18mTj = \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) -> case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] { False -> $wgo_s18mUc (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn); True -> 0# } ``` Test Plan: I've added a new testcase ./validate Reviewers: simonmar, simonpj, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1508 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:21:05 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.a956ed78a0b0c710589569f9da6a390c@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1c9fd3f1c5522372fcaf250c805b959e8090a62c/ghc" 1c9fd3f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c9fd3f1c5522372fcaf250c805b959e8090a62c" Case-of-empty-alts is trivial (Trac #11155) As you'll see from Trac #11155, the code generator was confused by a binding let x = y in .... Why did that happen? Because of a (case y of {}) expression on the RHS. The right thing is just to expand what a "trivial" expression is. See Note [Empty case is trivial] in CoreUtils. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:21:05 -0000 Subject: [GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error In-Reply-To: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> References: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> Message-ID: <064.726b89c75b11e556602d308c8ce2d8c1@haskell.org> #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"28035c0900f8d535e0b03d4c2aa0c79ba728436d/ghc" 28035c09/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28035c0900f8d535e0b03d4c2aa0c79ba728436d" Add derived constraints for wildcard signatures This fixes Trac #11016 See Note [Add deriveds for signature contexts] in TcSimplify] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:21:05 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.576f5e44057a08b3811020b3fc6cad4c@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1160dc516f8b27249d819665883409ee270a743f/ghc" 1160dc5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1160dc516f8b27249d819665883409ee270a743f" Fix egregious error in eta-reduction of data families This terrible and long-standing bug was shown up by Trac #11148. We are trying to eta-reduce a data family instance, so that we can then derive Functor or Generic. But we were assuming, for absolutely not reason whatsoever, that the type variables were lined up in a convenient order. The fact that it ever worked was a fluke. This patch fixes it properly. Main change is in eta_reduce in TcInstDcls.tcDataFamInstDecl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:21:05 -0000 Subject: [GHC] #11144: Custom type errors need tidying In-Reply-To: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> References: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> Message-ID: <062.7b2784371770106682aa0d95b5e4bbdf@haskell.org> #11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1547 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"67565a72f5bcd2edcb5775dc3879708f9d302fa8/ghc" 67565a72/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67565a72f5bcd2edcb5775dc3879708f9d302fa8" Tidy user type errors in checkValidType Trac #11144 showed that we need to tidy the type in the error message generated in TcValidity.checkUserTypeError. This is still unsatisfactory. checkValidType was originally supposed to be called only on types gotten directly from user-written HsTypes. So its error messages do no tidying. But TcBinds calls it checkValidType on an /inferred/ type, which may need tidying. Still this at least fixes the bad error message in CustomTypeErrors02, which was the original ticket. Some other small refactorings: * Remove unused Kind result of getUserTypeErrorMsg * Rename isUserErrorTy --> userTypeError_maybe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:29:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:29:26 -0000 Subject: [GHC] #11164: No way to import a data instance Message-ID: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs import Foreign.R.Type as R (SComplex) }}} results in {{{ In module ?Foreign.R.Type?: ?SComplex? is a data constructor of ?Sing? To import it use ?import? Foreign.R.Type( Sing( SComplex ) ) or ?import? Foreign.R.Type( Sing(..) ) }}} But if I try the suggested {{{#!hs import Foreign.R.Type as R (Sing(SComplex)) }}} I get {{{ Module ?Foreign.R.Type? does not export ?Sing(SComplex)? }}} So, when a module defines a data instance but does not export the family, there appears to be no way to bring that instance in scope (short of importing the whole module). Here's the module itself http://haddock.stackage.org/nightly-2015-10-19/inline-r-0.7.1.2/Foreign-R-Type.html. It doesn't have an explicit export list; that's how it manages to export instances without the family itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:37:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:37:18 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.38f4e92c5b2eb5783ae02c158808640c@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Does {{{#!hs import Foreign.R.Type as R ( pattern SComplex ) }}} work? If it doesn't, it should. The `pattern` keyword in import/export lists has been extended to apply to ordinary data constructors. These should include data family instance constructors, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:44:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:44:50 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.0779410e2b706bdf97a510b9b4f6d95f@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Turns out it does, but that's hardly a proper solution: 1. It is very confusing for someone reading the code and not obvious for the one writing it 2. It requires -XPatternSynonyms 3. That's not what ghc suggests -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:50:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:50:18 -0000 Subject: [GHC] #11165: Testsuite framework failures are too easy to ignore and too hard to find Message-ID: <046.b1d93186c62e1a3de1b9e3c053f1008e@haskell.org> #11165: Testsuite framework failures are too easy to ignore and too hard to find -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.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: -------------------------------------+------------------------------------- The testsuite driver really should do a better job of drawing the user's attention to framework failures. The only evidence in the testsuite summary that something went wrong is a non-zero "framework failures" count. If you notice that this count is non-zero then you need to sift manually through the initial log output produced by the driver and find the culprit. It's just generally terrible. Testsuite failures are failures, we should at least treat them as such and include them in the `TEST=...` message in the testsuite summary so they can be easily reproduced. Ideally we would also save the exception that caused the failure and show it in the summary as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:50:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:50:40 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.f9ca52e0b17ec7b86f3688add0920174@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed on all fronts. Would it be better to have this rule? * Whenever a module omits an export list, if that module declares and data instances, the data family is also (re-)exported. That would seem to fix your problem. Note that there is no difficulty if the exporting module specifies an export list, as it has to either export the data family itself, or use `pattern` to export the data instance constructor. In the latter case, we assume the module author has a reason not to export the data family (and, the exact same scenario happens with ordinary datatypes, requiring importers with import lists to also use `pattern`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 14:56:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 14:56:39 -0000 Subject: [GHC] #11144: Custom type errors need tidying In-Reply-To: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> References: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> Message-ID: <062.a57cad55af7261fb85747b944f5b35d8@haskell.org> #11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1547 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): `checkValidType` also sometimes see GHC-generated kinds. I've threaded a `TidyEnv` all throughout !TcValidity on my branch. So no need for you to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 15:02:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 15:02:58 -0000 Subject: [GHC] #11144: Custom type errors need tidying In-Reply-To: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> References: <047.a70ace9deaae48e87a4a0b7813d45f8c@haskell.org> Message-ID: <062.f79e91232ad2f31e196f9eb3d8ef1e35@haskell.org> #11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1547 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Aha. Good. I'll just close this ticket then. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 15:03:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 15:03:57 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.77ca95ed46a197ba4a100507d276e9aa@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T11148 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T11148 * resolution: => fixed Comment: Fixed, with a test case (using Functor) added. Thank you for identifying this bug! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 15:05:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 15:05:15 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.08f23b7a76c0bdc929797c68c922bc7b@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11155 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T11155 * resolution: => fixed Comment: I claim this is fixed. Alan, Herbert, does this fix the manifestations you see? I'll close it meanwhile. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 15:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 15:05:59 -0000 Subject: [GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error In-Reply-To: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> References: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> Message-ID: <064.d4c76840a569b8b7ed0334c24a31d4b3@haskell.org> #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: partial- valid program | sigs/should_compile/T11016 Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => partial-sigs/should_compile/T11016 * status: new => closed * resolution: => fixed Comment: Excellent point, thank you! Fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 15:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 15:08:48 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.630660a2f9830eb7fc959f42b7af63d0@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Would it be better to have this rule? > * Whenever a module omits an export list, if that module declares and data instances, the data family is also (re-)exported. Yes I agree with this. Would someone like to execute? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 17:21:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 17:21:17 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.33dec3306feea477ffd4e5e67514a45b@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 17:37:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 17:37:08 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell In-Reply-To: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> References: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> Message-ID: <062.0d008b8b418c488204e1538757d8a520@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 18:02:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 18:02:10 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.52389601e5bda9a443810da8a39efead@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Matt Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * owner: Phyx- => Matt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 18:51:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 18:51:37 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.fd4f08877f7c51f54fa12ff9475fc5b7@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11155 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Yes, the linker error is gone for haddock in D1558. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 20:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 20:41:50 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) Message-ID: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: | Version: 7.10.2 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: | prime:Libraries/Proposals/ExpandFloating -------------------------------------+------------------------------------- See details in prime:Libraries/Proposals/ExpandFloating -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 23:25:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 23:25:14 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect Message-ID: <042.83659aad46ca11303d89f1536bb73368@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The example below {{{#!hs module Foo where data SomeException newtype ContT r m a = ContT {runContT :: (a -> m r) -> m r} runContT' :: ContT r m a -> (a -> m r) -> m r runContT' = runContT catch_ :: IO a -> (SomeException -> IO a) -> IO a catch_ = undefined -- has type error foo :: IO () foo = (undefined :: ContT () IO a) `runContT` (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) -- typechecks foo' :: IO () foo' = (undefined :: ContT () IO a) `runContT'` (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) }}} works with GHC 7.10 but breaks with GHC HEAD currently with: {{{ foo.hs:15:47: error: ? Couldn't match expected type ?a0 -> IO ()? with actual type ?IO ()? ? In the second argument of ?runContT?, namely ?(undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ())? In the expression: runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) In an equation for ?foo?: foo = runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) foo.hs:15:48: error: ? Couldn't match expected type ?IO ()? with actual type ?a1 -> IO ()? ? In the first argument of ?catch_?, namely ?(undefined :: a -> IO ())? In the second argument of ?runContT?, namely ?(undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ())? In the expression: runContT (undefined :: ContT () IO a) (undefined :: a -> IO ()) `catch_` (undefined :: SomeException -> IO ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 4 23:25:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Dec 2015 23:25:24 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.4bbb908c1cb3a2bc4095969f0ed190da@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * version: 7.10.2 => 7.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 02:23:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 02:23:10 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.476cf977a409439e323f0aef5207cbda@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 gkaracha): > Your commit message is very informative. Did you include the same information in a `Note` in the code, so that we don't lose the information here? Done. I have added two separate notes: * About the representation of term equalities: 81cf200902628a6539572774ecc66678e133daaf * About the treatment of equality for overloaded literals: 406444b5f4173c20567abc3a3577a58a8ade10d4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 06:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 06:06:56 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.44bacc8387184c4a89762e42316cd05d@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch * differential: => phab:D1573 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 10:35:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 10:35:03 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.3b8f5f0e9d4fc7e4d90c963a43589281@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 11:06:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 11:06:21 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.95273295092cebe2d22b38a02f376575@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Small note: this test has slightly weird output: {{{ --- ./ghci/scripts/T5417.stdout.normalised 2015-12-05 12:03:09.099962730 +0100 +++ ./ghci/scripts/T5417.run.stdout.normalised 2015-12-05 12:03:09.099962730 +0100 @@ -3,5 +3,7 @@ data family D a class C.C1 a where data family C.F a +class C.C1 a where + data family C.F a -- Defined at T5417a.hs:5:5 data instance C.F (B1 a) = B2 a -- Defined at T5417.hs:8:10 }}} but looking at what the individual script command outputs I actually like the output more: {{{ *T5417> :browse data B1 a = B1 a data instance C.F (B1 a) = B2 a data family D a class C.C1 a where data family C.F a *T5417> :info C.F class C.C1 a where data family C.F a -- Defined at T5417a.hs:5:5 data instance C.F (B1 a) = B2 a -- Defined at T5417.hs:8:10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 15:05:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 15:05:04 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.ca97ce8b42f0763afc3de1c574a15ff5@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * Attachment "old-condecl.png" added. CmmNode documents for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 15:05:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 15:05:36 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.51ba2990be5cdc559928397ce36d32d7@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * Attachment "new-condecl.png" added. CmmNode with #11028 patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 15:12:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 15:12:58 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.e104b26d40da9b88d5013a150a1b2735@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I am finishing off the haddock changes for this. The original documentation generated for `CmmNode` was [[Image(https://ghc.haskell.org/trac/ghc/attachment/ticket/11028/old- condecl.png)]] With the update from the patch this becomes [[Image(https://ghc.haskell.org/trac/ghc/attachment/ticket/11028/new- condecl.png)]] See in particular `CmmCondBranch`. In the original it gives the (supposed) prefix constructor version, followed by the fields. But because `cml_true` and `cml_false` are part of the same field declaration, only one instance of `!Label` appears. In the new one, only the record fields are listed at the moment. Question: Should a prefix type signature be given at all, for a record GADT ConDecl? Or should it be left as per the new image? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 17:43:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 17:43:02 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.8a3feed5adc83b167e765afd0d0fc3d8@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 msosn): I'm looking into how the NamedWildCards extension causes programs to be rejected. I noticed that with the extension enabled, using named wildcards as types outside the type signatures (where they behave as documented in Partial Type Signatures section of the user's guide) causes errors. The code below is accepted when the extension is disabled, because the identifiers starting with _ are parsed as ordinary type variables. From what I read on the ghc mailing list, the type families should also be accepted with the NamedWildCards on. If so, shouldn't the wildcards be treated as type variables in the other cases as well? {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE NamedWildCards #-} module FailsWithNWCsEnabled where type Synonym _a = _a -> _a -- "Unexpected type '_a' In the type declaration for 'Synonym'" data A a _b = ACon a a -- "Unexpected type '_b' In the data declaration for 'A'" data B _a b = BCon _a _a -- "Unexpected type '_a' In the data declaration for 'B'" type family C a b where C a _b = a -> a -- "Wildcard '_b' not allowed in a type pattern of family instance for 'C'" type family D a b where D _a b = _a -> _a -- "Wildcard '_a' not allowed in a type pattern of family instance for 'D'" -- "Wildcard '_a' not allowed in the declaration for type synonym 'D'" (twice) data family E a b data instance E a _b = ECon a a -- "Wildcard '_b' not allowed in a type pattern of family instance for 'E'" data family F a b data instance F _a b = FCon _a _a -- "Wildcard '_a' not allowed in a type pattern of family instance for 'F'" -- "Wildcard '_a' not allowed in the definition of data constructor 'FCon'" (twice) }}} I also wonder if the warnings in type families should be enabled with the -fwarn-unused-matches option or should I make a new flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 18:12:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 18:12:29 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.ce5ba10807b2a75c1dd67f86e3f75bc0@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Duplicate record fields (phab:D761, git:b1884b0e62f62e3c0859515c4137124ab0c9560e) broke this. Currently trying to find what exactly broke it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 18:15:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 18:15:38 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.a4b5987bd0aa27f1ead8b7e2fd386ca5@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: gcampax Type: task | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.8.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:D524 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"5f1e42f22cf29bc1b7150e06b2711fa7c43c6e5b/ghc" 5f1e42f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f1e42f22cf29bc1b7150e06b2711fa7c43c6e5b" Allow to compile OSMem.c when MEM_NORESERVE is not available On some OSes such as AIX `MEM_NORESERVE` is not available. Since this feature is only needed when the new two-step allocator (see #9706) is enabled we can simply turn this into a runtime error to avoid a larger refactoring of this already quite platform-sensitive code. Reviewed By: bgamari, ezyang Differential Revision: https://phabricator.haskell.org/D1568 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 19:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 19:23:17 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.5f34823bfc173f787f08c34dd76d64da@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: adamgundry (added) Comment: cc'ing Adam as his patch seems to have caused this regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 20:24:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 20:24:13 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.62d97b88ea2ae7808a53220ab66e82b5@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Ok, so the source of the problem lies in RnExpr.hs:`rnExpr (OpApp ...)`, there's a missing case for when we have a record field. But now we've got a problem. We're running this during renaming, so we don't have the corresponding `Id` yet, only a `Name`. If the record field is `Unambiguous`, that's not a problem -- `PostRn Name Name = Name`. But if it's `Ambiguous`, `PostTc Name Name = PlaceHolder`, i.e. we have no way of getting the name. The `Unambiguous` case is easy, and that'd solve this ticket. But we need to deal with the `Ambiguous` case, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 20:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 20:31:52 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.09a270fbf75b3513511fe4a4fdb550a4@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 20:44:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 20:44:34 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.c05bdcf0dc4f67c2ffcb2aff408c0f2a@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): I see a few possible solutions for the ambig. case: * Warn and default fixity to `defaultFixity = infixl 9` * Disallow infix usage of ambiguous record fields completely (abort with an error). * As long the fixity of each overloaded record is identical, use it. Otherwise do one of the above. I don't like any of these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 22:17:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 22:17:04 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.d35b9369e08ecdc3e2353e6127ab72c7@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Another possibility is if the fixity is ambiguous, allow a user to locally override the fixity (and thus disambiguating), adding some sort of "local fixity" declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 5 23:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Dec 2015 23:07:19 -0000 Subject: [GHC] #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" In-Reply-To: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> References: <046.d8196c999608fededc5ef9d4e2e29843@haskell.org> Message-ID: <061.8ae37b132f363b5503327c42fa649bf8@haskell.org> #11155: Trivial thunk gives "undefined reference to stg_ap_0_upd_info" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11155 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I don't see the manifestation either anymore (i.e. the PPA builds work again now) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 02:39:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 02:39:09 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d Message-ID: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Keywords: cross-compile | 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 have been buildng a x86_64/linux to armhf/linux cross-compiler using: {{{ ./configure --target=arm-linux-gnueabihf -with-gcc=arm-linux-gnueabihf- gcc-5 make -j3 }}} for some time. However, after commit 7af29da05d, that results in: {{{ "inplace/bin/ghc-cabal" check libraries/base "inplace/bin/ghc-cabal" configure libraries/base dist-install "" --with-ghc="/md-new/home/erikd/Git/ghc-upstream/inplace/bin/ghc-stage1" --with-ghc-pkg="/md-new/home/erikd/Git/ghc-upstream/inplace/bin/ghc-pkg" --flags=integer-simple --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS="-Wall -marm -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -marm -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --configure-option=--host=arm-unknown-linux-gnueabihf --with-gcc="arm-linux-gnueabihf-gcc-5" --with-ld="/usr/bin/arm-linux-gnueabihf-ld.gold" --configure-option=--with-cc="arm-linux-gnueabihf-gcc-5" --with-ar="/usr/bin/arm-linux-gnueabihf-ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring base-4.9.0.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for arm-unknown-linux-gnueabihf-gcc... no checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/md-new/home/erikd/Git/ghc-upstream/libraries/base': configure: error: C compiler cannot create executables See `config.log' for more details libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/package-data.mk' failed make[1]: *** [libraries/base/dist-install/package-data.mk] Error 77 Makefile:121: recipe for target 'all' failed }}} It seems that the required GCC version doesn't get passed to configuration for Base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 03:34:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 03:34:02 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.a2dfcfd657b25a15f65debe0059a12de@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): There hasn't been any movement on this in a while, and I'd really like to see it changed. Are there people who disagree with the idea, or is it just a matter of getting it done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 03:52:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 03:52:37 -0000 Subject: [GHC] #11169: Remove the word "skolem" from user error messages Message-ID: <045.5b94ce81fe35377ff5af0392dcafee0f@haskell.org> #11169: Remove the word "skolem" from user error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Skolem variables are not, as best I can tell, part of the type system; they are part of the implementation of the type checking algorithm. As such, it seems inappropriate to mention them in error messages. Instead, the error messages should explain things at the Haskell level. {{{ Couldn't match expected type ?t? with actual type ?a? because type variable ?a? would escape its scope This (rigid, skolem) type variable is bound by... }}} I'd much rather see an explanation using words like "existentially quantified" and "right-hand side of a pattern match". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 04:21:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 04:21:31 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.8447b0a4c1d9cce07c0729e40d7ddf9f@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not aware of anyone disagreeing, so I don't think that's an obstacle. I attempted to fix this at one point, but I wasn't experienced enough in GHC to come up with a solution. One huge obstacle (for me, anyway) is that GHC co-opts the tilde symbol for [http://git.haskell.org/ghc.git/blob/1e041b7382b6aa329e4ad9625439f811e0f27232:/compiler/parser/Parser.y#l1779 laziness annotations], which means that all occurrences of `~` as type equalities are converted via a [http://git.haskell.org/ghc.git/blob/5f1e42f22cf29bc1b7150e06b2711fa7c43c6e5b:/compiler/parser/RdrHsSyn.hs#l1066 special parser function]. This makes it much harder to remove `~` as a special parser case, and when I tried removing it, it ended up introducing an enormous number of shift-reduce conflicts. I would also like to see this fixed at some point, but I don't think I'm going to be the one to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 04:30:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 04:30:46 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.93fcbd4b3e59137b94373187eb5642c4@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Oh, I really wasn't talking about removing it as a special case; I was talking about giving it (effectively) a negative precedence. Its current behavior in that regard is very annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 04:43:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 04:43:55 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.f38c7170d8058ad7833710aca55e9edd@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I few comments as I'm catching up on this thread: * We don't need to conform to any standards here. We're talking about type-level operators, so we're already beyond the Haskell reports. Thinking about standards is a Good Thing, but I just want to note that we're already quite off the map. * I think that, given the laziness annotation wrinkle, `~` will have to stay somewhat magical in the parser. (That may not have been true when this ticket started, as I think allowing laziness annotations in types came about only with `-XStrictData`.) * However, I think we ''can'' eliminate `HsEqTy` from `HsType`. Instead, just use `HsOpTy` with `eqTyCon_RDR` as the operator. Once we get rid of `HsEqTy`, I think we'll be well on our way to solving this ticket. Indeed, that's probably a good approach: get rid of `HsEqTy` and get everything to work again. * Parsing `->` is magical. And it has to be: we can write `forall a. a -> forall b. b -> (a,b)`, for example. `forall` can't appear to the right of other operators. And `->` has various other special things about it (like being able to appear in record GADT syntax). So we have to keep this in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 04:46:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 04:46:39 -0000 Subject: [GHC] #11169: Remove the word "skolem" from user error messages In-Reply-To: <045.5b94ce81fe35377ff5af0392dcafee0f@haskell.org> References: <045.5b94ce81fe35377ff5af0392dcafee0f@haskell.org> Message-ID: <060.9d4221a119be6a452f5c71e0255c932a@haskell.org> #11169: Remove the word "skolem" from user error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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 goldfire): I would say that skolems are a part of the type system. (For example, see the "Practical Type Inference" paper, JFP'07.) But the word is utterly opaque to users, and I fully support its removal. Or, if it is absolutely essential somewhere, the error message should include a link to a page explaining what it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 04:53:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 04:53:16 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.38cb13ba0edfa81ea0cff551a4f72a48@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sibi): * owner: => sibi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 05:52:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 05:52:45 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.aa97d6ca8d4f4c0ddaf57158ccbc5c3a@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: 7.6.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 maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 07:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 07:53:15 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.82b4a34070bcfd95078d06997dbb3a45@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 hvr): Is there anything interesting logged to `config.log` telling us what Autoconf does exactly? Does it help if you comment out the `AC_USE_SYSTEM_EXTENSIONS` line in `libraries/base/configure.ac`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 08:39:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 08:39:04 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.ec2549db80242d983522127b27847073@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 hvr): Fwiw, I can't reproduce this trying to build a x86_64-unknown-linux to aix-ibm-aix crosscompiler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 09:18:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 09:18:22 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.24ff8922aaa9b70159810aa869cb7b7c@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 erikd): How do you configure for powerpc-ibm-aix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 09:23:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 09:23:28 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.d50abe3de075fff41999848a2c1dd413@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 erikd): Ok, I think the cause of the problem is that I'm configuring with: {{{ ./configure --target=arm-linux-gnueabihf -with-gcc=arm-linux-gnueabihf- gcc-5 }}} The `-with-gcc` argument is necessary because there is no compiler named `arm-linux-gnueabihf-gcc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 09:37:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 09:37:56 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.b486abd26fe770ae42e123f69bd419e2@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: patch Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D1575 -------------------------------------+------------------------------------- Changes (by sibi): * status: new => patch * differential: => https://phabricator.haskell.org/D1575 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 12:36:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 12:36:31 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.fd8793238f911ce722459aaaa84f2793@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 hvr): Can you try if http://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/T11168 changes anything? That patch moves the AC_USE_SYSTEM_EXTENSIONS macro to a later point at which the CC setting should be already locked (rather than triggering a premature CC detection) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 15:38:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 15:38:42 -0000 Subject: [GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning In-Reply-To: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> References: <042.e02ab93445edf67c384ef57b5dac6baf@haskell.org> Message-ID: <057.aa111bbd286cc9d9bf4020a8fed8c289@haskell.org> #11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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): Phab:D1516 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"986ceb1679b501414b996c520b08ce929a40f94c/ghc" 986ceb16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="986ceb1679b501414b996c520b08ce929a40f94c" Implement new `-fwarn-noncanonical-monoid-instances` This is similiar to the `-fwarn-noncanonical-monad-instances` warning implemented via #11128, but applies to `Semigroup`/`Monoid` instead and the `(<>)`/`mappend` methods (of which `mappend` is planned to move out of `Monoid` at some point in the future being redundant and thus error-prone). This warning is contained in `-Wcompat` but not in `-Wall`. This addresses #11150 Reviewed By: quchen Differential Revision: https://phabricator.haskell.org/D1553 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 15:38:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 15:38:42 -0000 Subject: [GHC] #11150: New `-fwarn-noncanonical-monoid-instances` warning In-Reply-To: <042.55096ce3dad11d93367502f540669d4a@haskell.org> References: <042.55096ce3dad11d93367502f540669d4a@haskell.org> Message-ID: <057.c613f4a133c3a3f5acb75a0cc9d5df0f@haskell.org> #11150: New `-fwarn-noncanonical-monoid-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.0.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: #11128, #11139 | Differential Rev(s): Phab:D1553 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"986ceb1679b501414b996c520b08ce929a40f94c/ghc" 986ceb16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="986ceb1679b501414b996c520b08ce929a40f94c" Implement new `-fwarn-noncanonical-monoid-instances` This is similiar to the `-fwarn-noncanonical-monad-instances` warning implemented via #11128, but applies to `Semigroup`/`Monoid` instead and the `(<>)`/`mappend` methods (of which `mappend` is planned to move out of `Monoid` at some point in the future being redundant and thus error-prone). This warning is contained in `-Wcompat` but not in `-Wall`. This addresses #11150 Reviewed By: quchen Differential Revision: https://phabricator.haskell.org/D1553 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 16:26:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 16:26:06 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.033f6c73cd814ea83ee81424eb7301f9@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 jstolarek): Replying to [comment:2 msosn]: > The code below is accepted when the extension is disabled, because the identifiers starting with _ are parsed as ordinary type variables. From what I read on the ghc mailing list, the type families should also be accepted with the NamedWildCards on. If so, shouldn't the wildcards be treated as type variables in the other cases as well? I think you're right. I mean if this code is valid when `NamedWildCards` are turned off, then it certainly should be valid when we enable `NamedWildCards`. After all named wild cards can't possibly appear in any of these declarations, so whenever a name that looks like a wildcard appears we can safely assume that it must be a type variable. Note however, that we only want to generate warnings for unused pattern variables in type families. > I also wonder if the warnings in type families should be enabled with the -fwarn-unused-matches option or should I make a new flag? I say we use the existing flag. If anyone complains that they want a separate flag for unused type-level patterns then we can add it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 18:09:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 18:09:41 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] In-Reply-To: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> References: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> Message-ID: <059.dae83deeb457626603b2c451a987a2d3@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: dolio Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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:D1572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dolio): * cc: ekmett (added) * differential: => Phab:D1572 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 18:18:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 18:18:09 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse Message-ID: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.2 Keywords: Read | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For most languages ".9" is a floating point number equal to 0.9, but in GHC this is unparsable. I don't know if it is by design, but it was unexpected by me. I think that it is good this to be valid parsable to Double string. What do you think of? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 18:25:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 18:25:23 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.c92646374f54eb466a8f85dfc6b985d3@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 7.10.2 Resolution: invalid | Keywords: Read Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: It actually is parseable, if you put parens around it: {{{#!hs > :t (.4) (.4) :: Num (a -> b) => (b -> c) -> a -> c }}} The problem here is that `.` is an operator, so it parses it as `\x -> (.) x 4` (which would type check if you have have an instance `Num (a -> b)`). This is the correct behaviour according to the language specification, and definitely nothing a compiler should do different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 20:11:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 20:11:13 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.1bdd4d6182acde204f063a61096aa535@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross-compile 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 Herbert Valerio Riedel ): In [changeset:"8b422142421c751d2c7fa7840afa61f923afdbe1/ghc" 8b42214/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b422142421c751d2c7fa7840afa61f923afdbe1" Tweak use of AC_USE_SYSTEM_EXTENSIONS This makes sure that `AC_USE_SYSTEM_EXTENSIONS` (which implies `AC_PROG_CC`) is called after the `AC_ARG_WITH([cc],,)` invocation, so that the proper CC setting is in scope. Otherwise this can break cross-compilation. This also needs to pull in a submodule update for `unix` This is a follow-up commit to 7af29da05d2e5a5e311a5f73f20d0f232035973b which hopefully fixes #11168 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 20:12:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 20:12:46 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.568acdc28234c6a5f0890795d3a4e137@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross-compile 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 hvr): * status: new => closed * resolution: => fixed Comment: I expect this to be fixed now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 22:09:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 22:09:19 -0000 Subject: [GHC] #11171: the 'impossible' happened when messing with existenial quantification and typed holes Message-ID: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> #11171: the 'impossible' happened when messing with existenial quantification and typed holes -------------------------------------+------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- First of all, I am quite honored that I was able to do something that GHC considered impossible. (Funny too. Just the other day, I was trying to break GHC and failed. Today, I was doing something I thought was rather mundane (although it was acting somewhat funky anyway)). Anyway, here is my error message: {{{ *Main> :r [1 of 1] Compiling Main ( pad.lhs, interpreted ) pad.lhs:12:25: Couldn't match type ?f1? with ?f? ?f1? is a rigid type variable bound by the type signature for wrap :: Functor f1 => f1 (CoInd f1) -> CoInd f1 at pad.lhs:11:11ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: f_abyA[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And here is the code {{{#!hs > {-# LANGUAGE DeriveFunctor, Rank2Types, ExistentialQuantification #-} > newtype Ind f = Ind {flipinduct :: forall r. (f r -> r) -> r} > induction = flip flipinduct > data CoInd f = forall r. Coinduction (r -> f r) r > coinduction = Coinduction > data StringF rec = Nil | Cons Char rec deriving Functor > wrap :: (Functor f) => f (CoInd f) -> CoInd f > wrap fc = coinduction igo Nothing where > igo :: Maybe (CoInd f) -> _ > igo Nothing = fmap Just fc > igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed > convert :: (Functor f) => Ind f -> CoInd f > convert = induction wrap > cowrap :: (Functor f) => Ind f -> f (Ind f) > cowrap = induction igo where > igo :: f (f (Ind f)) -> f (Ind f) > igo = fmap (\fInd -> Ind $ \fold -> fold $ fmap (`flipinduct` fold) fInd) > convert' :: (Functor f) => Ind f -> CoInd f > convert' = coinduction cowrap }}} I think the important parts are only "CoInd", "wrap", and "igo", but I included it all just to be sure (and I'm lazy). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 22:10:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 22:10:50 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.54a0121c054ead902446a04724e8851b@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * differential: => Phab:D1576 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 22:12:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 22:12:23 -0000 Subject: [GHC] #11168: Cross build broken in commit 7af29da05d In-Reply-To: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> References: <044.a6ec4511917519c6a9e9c8aae26cd0e4@haskell.org> Message-ID: <059.c9b75cd5cab3649de8d78105aba32347@haskell.org> #11168: Cross build broken in commit 7af29da05d -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: cross-compile 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 erikd): Confirmed as fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 6 22:17:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Dec 2015 22:17:28 -0000 Subject: [GHC] #11171: the 'impossible' happened when messing with existenial quantification and typed holes In-Reply-To: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> References: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> Message-ID: <063.d4a5ee0ba83252d66c17f8113ba439fe@haskell.org> #11171: the 'impossible' happened when messing with existenial quantification and typed holes -------------------------------------+------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #10615 Comment: I can reproduce this on 7.10.2 but not on HEAD. I've pasted the actual errors I get on HEAD below, I think the panic was due to the wildcard. {{{ [1 of 1] Compiling Main ( test.lhs, interpreted ) test.lhs:13:31: error: ? Found type wildcard ?_? standing for ?f (Maybe (CoInd f))? Where: ?f? is a rigid type variable bound by the type signature for: wrap :: Functor f => f (CoInd f) -> CoInd f at test.lhs:11:11 To use the inferred type, enable PartialTypeSignatures ? In the type signature for: igo :: Maybe (CoInd f) -> _ In an equation for ?wrap?: wrap fc = coinduction igo Nothing where igo :: Maybe (CoInd f) -> _ igo Nothing = fmap Just fc igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed ? Relevant bindings include fc :: f (CoInd f) (bound at test.lhs:12:8) wrap :: f (CoInd f) -> CoInd f (bound at test.lhs:12:3) test.lhs:14:5: error: ? No instance for (Functor f) ? When checking that ?igo? has the inferred type igo :: forall (f :: * -> *). Maybe (CoInd f) -> f1 (Maybe (CoInd f1)) Probable cause: the inferred type is ambiguous In an equation for ?wrap?: wrap fc = coinduction igo Nothing where igo :: Maybe (CoInd f) -> _ igo Nothing = fmap Just fc igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed test.lhs:15:42: error: ? Couldn't match type ?f1? with ?f? ?f1? is untouchable inside the constraints: () bound by a pattern with constructor: Coinduction :: forall (f :: * -> *) r. (r -> f r) -> r -> CoInd f, in an equation for ?igo? at test.lhs:15:16-36 ?f1? is a rigid type variable bound by the inferred type of igo :: Functor f1 => Maybe (CoInd f1) -> f (Maybe (CoInd f)) at test.lhs:13:12 ?f? is a rigid type variable bound by the type signature for: wrap :: Functor f => f (CoInd f) -> CoInd f at test.lhs:11:11 Possible fix: add a type signature for ?igo? Expected type: f (Maybe (CoInd f)) Actual type: f1 (Maybe (CoInd f1)) ? In the expression: fmap (Just . Coinduction step) $ step seed In an equation for ?igo?: igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed In an equation for ?wrap?: wrap fc = coinduction igo Nothing where igo :: Maybe (CoInd f) -> _ igo Nothing = fmap Just fc igo (Just (Coinduction step seed)) = fmap (Just . Coinduction step) $ step seed ? Relevant bindings include step :: r -> f1 r (bound at test.lhs:15:28) igo :: Maybe (CoInd f1) -> f (Maybe (CoInd f)) (bound at test.lhs:14:5) fc :: f (CoInd f) (bound at test.lhs:12:8) wrap :: f (CoInd f) -> CoInd f (bound at test.lhs:12:3) test.lhs:23:12: error: ? Could not deduce (Functor f1) arising from a use of ?fmap? from the context: Functor f bound by the type signature for: cowrap :: Functor f => Ind f -> f (Ind f) at test.lhs:20:13-45 Possible fix: add (Functor f1) to the context of the type signature for: igo :: f1 (f1 (Ind f1)) -> f1 (Ind f1) ? In the expression: fmap (\ fInd -> Ind $ \ fold -> fold $ fmap (( \ x_ -> flipinduct x_ fold)) fInd) In an equation for ?igo?: igo = fmap (\ fInd -> Ind $ \ fold -> fold $ fmap (( \ x_ -> flipinduct x_ fold)) fInd) In an equation for ?cowrap?: cowrap = induction igo where igo :: f (f (Ind f)) -> f (Ind f) igo = fmap (\ fInd -> Ind $ \ fold -> ...) test.lhs:23:49: error: ? Could not deduce (Functor f1) arising from a use of ?fmap? from the context: Functor f bound by the type signature for: cowrap :: Functor f => Ind f -> f (Ind f) at test.lhs:20:13-45 Possible fix: add (Functor f1) to the context of a type expected by the context: (f1 r -> r) -> r or the type signature for: igo :: f1 (f1 (Ind f1)) -> f1 (Ind f1) ? In the second argument of ?($)?, namely ?fmap (( \ x_ -> flipinduct x_ fold)) fInd? In the expression: fold $ fmap (( \ x_ -> flipinduct x_ fold)) fInd In the second argument of ?($)?, namely ?\ fold -> fold $ fmap (( \ x_ -> flipinduct x_ fold)) fInd? Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 00:17:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 00:17:48 -0000 Subject: [GHC] #11171: the 'impossible' happened when messing with existenial quantification and typed holes In-Reply-To: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> References: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> Message-ID: <063.1a65f2c8917c9227185f6867bb953149@haskell.org> #11171: the 'impossible' happened when messing with existenial quantification and typed holes -------------------------------------+------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by TheKing42): It seems like a lot of funky stuff bug like stuff is going on in that code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 06:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 06:33:44 -0000 Subject: [GHC] #7169: Warning for incomplete record field label used as function In-Reply-To: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> References: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> Message-ID: <062.7bff454d5d3639b9256670076fc6eb56@haskell.org> #7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | 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: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 07:10:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 07:10:25 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.87a440e2f84e37b8b080d6afc2a81bad@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"be92c288839e0bfcf0b15e3bb4136d60f8ef2575/ghc" be92c288/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be92c288839e0bfcf0b15e3bb4136d60f8ef2575" Update hoopl submodule Hoopl changes required to implement #10982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 09:07:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 09:07:19 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.5786f879fb508b075f9581827a03db91@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The old one is clearly wrong when we have {{{ cml_true, cml_false :: !Label }}} We could fix it to provide ''both'' a prefix signature ''and'' list the fields; and that is presumably what the old version was supposed to do. And the new form which looks like {{{ CmmCondBranch :: -> CmmNode O C cml_true, cml_false :: !Label ...etc... }}} does look very weird. `CmmCondBranch :: -> CmmNode O C` just isn't Haskell. Why not just print it out in the source syntax form: {{{ CmmCondBranch :: { cml_true, cml_false :: ! Label , ...etc... } -> CmmNode O C }}} Admittedly that's more work, because it's not what Haddock does right now. But it would make more sense to users wouldn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 09:08:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 09:08:32 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] In-Reply-To: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> References: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> Message-ID: <059.285a08e7375ff91e36fd2f682cf055fb@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: dolio Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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:D1572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Discussed in this thread: https://mail.haskell.org/pipermail/libraries/2015-May/025741.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 09:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 09:19:03 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.e5775c75122bf3d81184d5465fe20e20@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Argh, this is awkward. Thanks for tracking this down. Given the proximity of the RC, I'm inclined not to add a new declaration form for the time being. Rather, my vote would be to use the common fixity if there is one, or fail with an error if there isn't. After all, it isn't possible to declare iduplicate selectors with different fixities in a single module, and for imported ones the user can always disambiguate using the module system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 09:43:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 09:43:48 -0000 Subject: [GHC] #11171: the 'impossible' happened when messing with existenial quantification and typed holes In-Reply-To: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> References: <048.c50e7a7e15f0f6cea9574f782e75695a@haskell.org> Message-ID: <063.7c2f12fe34baa0ce0fc96f1610aec067@haskell.org> #11171: the 'impossible' happened when messing with existenial quantification and typed holes -------------------------------------+------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I fixed a bunch of wildcard-related stuff recently. So can you try with HEAD (or 8.0 when it comes) and say if you still think there's a problem? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 10:11:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 10:11:45 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.7ed1f206895bc992a9a70b16de8e0a78@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: adamgundry Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: kanetw => adamgundry Comment: I'm puzzled. We only use `Ambiguous` to defer to the type checker if the occurrence is, well, ambiguous. But here it isn't: there is only one `runContT` in scope. Ah: it's because, as kanetw points out, there's a missing case in the `OpApp` case of `rnExpr`. So we could fix that at least, and then this example would work. Let's do that anyway. That will fix the regression. Now we'd only have a problem if (a) we have `-XOverloadedRecordFields` and (b) the selector occurrence really was ambiguous. And then I suppose that the right thing to do is to fail (at least if the fixities differ) saying "Ambiguous fixity for runContT" or something like that. Stuff needs to be fixed in the user manual too, to explain this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:14:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:14:34 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.5388cf1b46350a2b6d4ad9a026081ee2@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: patch Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D1575 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3d55e41e72dc32281744c52afea380c1db577ee1/ghc" 3d55e41e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3d55e41e72dc32281744c52afea380c1db577ee1" ghc-pkg: Restore old behavior in colored version; fixes 6119 The behavior is changed to this: ``` ghc-pkg list blahblah /home/sibi/ghc/inplace/lib/package.conf.d (no packages) ``` instead of: ``` ghc-pkg list blahblah /home/sibi/ghc/inplace/lib/package.conf.d ``` Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1575 GHC Trac Issues: #6119 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:14:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:14:34 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.c9520aecd3bf990b4f492df7bd97693e@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8cef8af3286f3c98f2a02e65371b875d8791b687/ghc" 8cef8af3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8cef8af3286f3c98f2a02e65371b875d8791b687" Re-export data family when exporting a data instance without an export list Whenever a data instance is exported, the corresponding data family is exported, too. This allows one to write ``` -- Foo.hs module Foo where data family T a -- Bar.hs module Bar where import Foo data instance T Int = MkT -- Baz.hs module Baz where import Bar (T(MkT)) ``` In previous versions of GHC, this required a workaround explicit export list in `Bar`. Reviewers: bgamari, goldfire, austin Reviewed By: bgamari, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1573 GHC Trac Issues: #11164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:14:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:14:34 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.4785379ddec263b89b15a8d7d0d48fe6@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHC API | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: ghc-api/T9015 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1518 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2110037e270c5ea36de63e4d95a3175751338571/ghc" 2110037e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2110037e270c5ea36de63e4d95a3175751338571" Add isImport, isDecl, and isStmt functions to GHC API Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1518 GHC Trac Issues: #9015 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:24:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:24:47 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.2cfd9779fee6551d4c3a865e37c9cf14@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | 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): phab:D1573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:26:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:26:06 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.85ffe9e023e1bd15ad61b16dabcb4580@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: sibi Type: feature request | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D1575 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:26:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:26:15 -0000 Subject: [GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc. In-Reply-To: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> References: <054.7f6a461675f798415503e3e2ad38cdb0@haskell.org> Message-ID: <069.d7f55e47e53e6c7ac123ae3afd1dd363@haskell.org> #9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: roshats Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHC API | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: ghc-api/T9015 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1518 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:50:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:50:04 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.8c6519cda9ddce9f1fae8d7d90f1da2a@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): After a brief chat on IRC we changed it in the current patch to {{{#!hs CmmCondBranch :: {..} -> CmmNode O C }}} followed by the field definition. The other option is to surround the field definition with braces and put the return type at the and, as per the original source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 11:51:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 11:51:11 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.630c5f6a2bf6a01f0b2da197f11023d9@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Clarification: the chat took place shortly after the issue was identified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:10:08 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.369f95b66bff56d20bc62cb117c9d43d@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: kosmikus Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9043 Related Tickets: #9043 | Differential Rev(s): Phab:D493 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"700c42b5e0ffd27884e6bdfa9a940e55449cff6f/ghc" 700c42b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="700c42b5e0ffd27884e6bdfa9a940e55449cff6f" Use TypeLits in the meta-data encoding of GHC.Generics Test Plan: Validate. Reviewers: simonpj, goldfire, hvr, dreixel, kosmikus, austin, bgamari Reviewed By: kosmikus, austin, bgamari Subscribers: RyanGlScott, Fuuzetsu, bgamari, thomie, carter, dreixel Differential Revision: https://phabricator.haskell.org/D493 GHC Trac Issues: #9766 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:10:08 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.1d2e678ad7c0ef0a6d103b59b66695e3@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"51a5e68db887adb3565ff2f077267e2b513be562/ghc" 51a5e68d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="51a5e68db887adb3565ff2f077267e2b513be562" Refactor ConDecl The ConDecl type in HsDecls is an uneasy compromise. For the most part, HsSyn directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's API annotations. But ConDecl doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type ```lang=hs data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ?::? , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_qvars :: Maybe (LHsQTyVars name) -- User-written forall (if any), and its implicit -- kind variables -- Non-Nothing needs -XExistentialQuantification , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) ``` Note that For GADTs, just keep a type. That's what the user writes. NB:HsType can represent records on the LHS of an arrow: { x:Int,y:Bool} -> T con_qvars and con_cxt are both Maybe because they are both optional (the forall and the context of an existential data type For ConDeclGADT the type variables of the data type do not scope over the con_type; whereas for ConDeclH98 they do scope over con_cxt and con_details. Updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, erikd, hvr, goldfire, austin, bgamari Subscribers: erikd, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1558 GHC Trac Issues: #11028 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:10:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:10:08 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.633538316649c713e7d6652b1ef8545f@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): Phab:D1561 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1bd40c860eb0e8da55b8eff536766a6c802347cc/ghc" 1bd40c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1bd40c860eb0e8da55b8eff536766a6c802347cc" Move checking for missing signatures to RnNames.reportUnusedNames Checking for missing signatures before renaming the export list is prone to errors, so we now perform the check in `reportUnusedNames` at which point everything has been renamed. Test Plan: validate, new test case is T10908 Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1561 GHC Trac Issues: #10908 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:12:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:12:23 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.3e3370f4548cce1b07478dd444d69915@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: adamgundry Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Adam, are you going to handle this or should I finish? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:14:06 -0000 Subject: [GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics In-Reply-To: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> References: <046.ac6e9deb0e3faceb7991565f7ad6b80b@haskell.org> Message-ID: <061.e5e109f24eda8dc5a1bfc72aaaa5a6df@haskell.org> #9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: kosmikus Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9043 Related Tickets: #9043 | Differential Rev(s): Phab:D493 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:15:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:15:30 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.78e79cd912e3a2a0afca9ba8b176babe@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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: #11155 | Differential Rev(s): Phab:D1558 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: The commit above performed the refactoring described here. There are still a few open questions regarding Haddock's handling of this. These will be addressed in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:16:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:16:37 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.57385ec7411ef3684b777846ebb997b3@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | warnings/should_compile/T10908 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1561 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => warnings/should_compile/T10908 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:16:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:16:52 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.1fa6cce6f303153b2b16546769054238@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | warnings/should_compile/T10908 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1561 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:25:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:25:06 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.f90772cb0c841aeb2f3efdd671e144e4@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: adamgundry Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): @kanetw since you've made a start, if you're happy to finish this off I'd greatly appreciate it! I'm happy to review, update the user manual or otherwise help out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:26:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:26:15 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.e882d0689708fa77305c1c36107060f1@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: adamgundry => kanetw Comment: Ok, I'll handle it then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 12:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 12:41:46 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.a8fdfb9cfc93b73477450bf0269db825@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: kanetw => * status: closed => new * resolution: fixed => Comment: Wait a sec. [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/type- families.html#data-family-import-export Section 7.7.4 of the user manual] describes how the rules for exports are modified for families; so it definitely needs a new bullet! And the adjustment in `exports_from_avail` is delicate. It actually only fires on data families, because only with data families can we have a ''locally-defined'' subordinate thing (data constructor, class op) whose parent type constructor is ''imported''. Worth spelling this out. All this only applies for modules with no export list. The comment says "Generally, whenever we export a part of a declaration, export the declaration, too." That seems a bit misleading, doesn't it? It really only applies to data families. So I'm ok with the code but I do think the documentation needs a little work (comments, user manual). Many thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:00:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:00:50 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.cff9387e57b7a0ea9f3f179f20bc3c1e@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | Status: new 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw Comment: The export list syntax itself stays unmodified and I adjusted the example 'That (annoyingly) means that you cannot selectively import Y selectively, thus "import Y( D(D1,D2) )", because Y does not export D.' already. See the `docs/users_guide/glasgow_exts.rst` diff in Phab. I'll edit the comment. I was trying to phrase what I was doing in a general way but I got a bit too general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:01:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:01:14 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.f3a967a8c887a7d8349c3f0aba557810@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.2 Resolution: | Keywords: Read Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by varosi): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:02:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:02:34 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.a802a47823f60938a6ee92b7cb665ddd@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.2 Resolution: | Keywords: Read Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): As I mention in the title and in the "Component" field, the problem is not in the GHC itself, but in Prelude: (read ".9") :: Double -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:07:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:07:26 -0000 Subject: [GHC] #8245: ghc-pkg list --simple-output prints packages in non-alphabetical order In-Reply-To: <042.fba834862c4e1c766cdb741526344201@haskell.org> References: <042.fba834862c4e1c766cdb741526344201@haskell.org> Message-ID: <057.bf73d133248028a6d3a54367483379cf@haskell.org> #8245: ghc-pkg list --simple-output prints packages in non-alphabetical order -------------------------------------+--------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 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: | -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"151c4b0b6caff2e1af764699c54302933c628861/ghc" 151c4b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="151c4b0b6caff2e1af764699c54302933c628861" ghc-pkg: don't sort packages unnecessarily The packages in the package database are already sorted alphabetically by this point (see db_stack_sorted). This is a better fix for #8245, commit 021b1f8. Test Plan: look at output of './inplace/bin/ghc-pkg list [--simple-output]' Reviewers: austin, bgamari, psibi Reviewed By: psibi Differential Revision: https://phabricator.haskell.org/D1579 GHC Trac Issues: #8245 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:09:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:09:53 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.0e3e29a4c97a322132daddcf3f0cfc56@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is a bit fiddly. Here are some facts about the current implementation: * Named wildcards are part of the abstract syntax of types; see the `HsWildCardTy` constructor of `HsType` and the data type `HsTypes.WildCardInfo`. * If `-XNamedWildCards` is on, we make a `NamedWildCard` for any `_v` in a type; see `Parser.y` and the call to `mkNamedWildCardTy`. That puts a `NamedWildCard` in many places that it does not "belong", which is what gives rise to the fallout in comment:2 The Right Thing is probably not to put `HsWildCardTy` into types where they aren't allowed. Really they should only show up in `LHsSigWcType`. So I suppose that one simple thing would be to parse wildcards as `HsTyVar`, and then either * Make `mkLHsSigWcType` traverse the type and replace appropriate `HsTyVars` with `HsWildCardTy`, or * Make the renamer do this job. Probably the latter is best. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:12:06 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.5d89957d576cfe93a5332750dfc94b2c@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | Status: new 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:D1573 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know that the syntax remains unchanged. But the semantics does not. And the opening section of 7.7.4 is all about semantics. There are four bullets at the moment and we need a fifth. An example illustrates, but this is the specification! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:16:36 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.8f6591f889c35c7983496adda174767f@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: ekmett (added) * component: Prelude => Core Libraries Comment: Ah, I see. Sorry for not reading your request carefully. The report simply states > Reads an unsigned RealFrac value, expressed in decimal scientific notation. which allows for certain variations in interpretation. Also, I don?t see a problem with `read` being more liberal than necessary, as long as no ambiguities or similar are introduced. Reassigning the component to get it onto the radar of the Core Library Committee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 13:32:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 13:32:31 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.aab999c6615610b59291ecc39219210a@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11098 | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #11098 Comment: This looks like a manifestation of #11098. I tried fixing it by "making renamer do its job" but got stuck because I didn't know how to tell whether a type variable was introduced using a forall or not - see [ticket:11098#comment:3]. But this was before wildcard refactor patch (Phab:D1428). Now, looking at Note [HsType binders] in HsTypes, I think it is easy to tell whether a type variable was quantified explicitly or not. Micha?, does this allow you to make progress? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:16:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:16:21 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.f09901895ce63603e63ac64ef8e8544b@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just possibly related #7411 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:29:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:29:21 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.54195f03965387f180a47e4388f57c24@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): In the past we've avoided in the past making GHC-specific changes in what `read` will accept to avoid hard to track down differences across compilers. We've rejected at least one similar generalization request (binary literals) on those grounds. #10092 That said, there is already a chink in that armor as I believe we've let in a patch in that generalized `lex` to allow a bit more unicode. #10444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:34:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:34:47 -0000 Subject: [GHC] #10444: Text.Read.Lex.lex broken In-Reply-To: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> References: <048.7d303af6bd6af366785c1d3e315fce90@haskell.org> Message-ID: <063.a832628aad644610da6e1ab38aa369a0@haskell.org> #10444: Text.Read.Lex.lex broken -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: report-impact 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:D1122, Wiki Page: | Phab:D1480. -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:35:20 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.6f3269c4ed66f7a5ddfe492a0768ca24@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: Read => Read, report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:37:05 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.32298f79e4846ce51a7b595c67ee9aaf@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 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: #7880 | Differential Rev(s): Phab:D211 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this ticket is now done (as part of the "wildcard refactor" patch (1e041b7382b6aa329e4ad9625439f811e0f27232), except that we should remove `-fwarn-context-quantification` altogether (according to comment:20), or deprecate it. It already does nothing. Ben: could you do this, and close? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:37:23 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.70a52b9a80dee086a5381a7962d54507@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 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: #7880 | Differential Rev(s): Phab:D211 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: simonpj => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:40:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:40:37 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.343b32aad6e1137d1d6f7819e073980c@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.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: Related Tickets: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:44:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:44:12 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 7.12.1 RC In-Reply-To: <042.27be62378f24cc29ae2d842288972a74@haskell.org> References: <042.27be62378f24cc29ae2d842288972a74@haskell.org> Message-ID: <057.b39a5349b24c44734fc34cd2fa1f7cde@haskell.org> #10238: Update libffi shortly before first GHC 7.12.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: libffi 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 hvr): libffi-3.2.1 is still -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 15:45:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 15:45:41 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.b8cf9c517579cd16cacd73ec00529223@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: scpmw => bgamari Comment: I'll grab this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 16:10:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 16:10:23 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative Message-ID: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- I believe I've found a bug that makes GHC generate the "Impossible case alternative" run-time crash with optimisations turned on (`-O`), which does not happen in ghci or without optimisations (`-O0`). Please see https://github.com/fpco/impossible-case-alternative-repro for a reproduction with GHC 7.10 and 7.8. What seems to happen here is that when `fun2` is inlined, the simplifier (or whatever component) decides that some `case` (I haven't figured out yet which one) is impossible; you can clearly see how it gets fixed in the Core when adding a `NOINLINE fun2` and compiling with `-ddump-simpl`. I believe this difference in inlining is also why `-O` makes a difference vs `-O0`. What certainly surprised me is that when replacing {{{ (do p <- earlyExit <* error "bad" return p) }}} with {{{ (earlyExit <* error "bad") }}} the error goes away as well. Note that I'm using some TemplateHaskell around that block; I'm wondering whether that somehow leads to an unfortunate interaction with the simpilifier. First thing I'd appreciate is somebody to tell me: Is this a real bug or something GHC allows itself to do? Since for most other run-time errors, GHC asks me to report a bug, but it doesn't do so for `Impossible case alternative`. I would have liked to make a smaller reproduction (currently it needs 2 files and aeson as an external depencency), but if I shrink it any further the error goes away. So for now I hope that a 150 line repro in 2 files will do. We have reproduced this on Linux and Mac, but I'm quite confident that it's platform-independent. I'm setting the milestone for this to 8.0.1 because this is a problem that makes some real-world trouble for us, feel free to change back if that's inappropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 16:46:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 16:46:22 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.190939e652a50e0147600ca1340a7268@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): While writing tests I've noticed that infix declarations for record fields are broken (another regression to 7.10.2). I'll make a new ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 16:51:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 16:51:40 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken Message-ID: <045.445187b93a05b360f24646d0112109cc@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 program compiles fine {{{#!hs module Good where newtype A = A { foo :: Int } infixl 5 `foo` }}} but this one doesn't {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} module Bad where newtype A = A { foo :: Int } infixl 5 `foo` }}} giving an error {{{ The fixity signature for ?foo? lacks an accompanying binding (The fixity signature must be given where ?foo? is declared) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:02:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:02:13 -0000 Subject: [GHC] #11170: (read ".9") :: Double unable to parse In-Reply-To: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> References: <045.52c44f40c7167f9f5a151c2ef3097f2e@haskell.org> Message-ID: <060.77e572f5ca5b2a854f002e7885e0a14e@haskell.org> #11170: (read ".9") :: Double unable to parse -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Read, report- | impact Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW, my understanding of #10444 was that it brought GHC in line with the Report. I don't remember the details, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:11:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:11:36 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.624af9ae6ac73377de0edad9147a3ef1@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): phab:D1585 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * differential: => phab:D1585 Comment: Made a diff. I'll update the user manual later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:13:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:13:37 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.294965a4baaa1ed984a9bdf26c793cf8@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 rwbarton): > First thing I'd appreciate is somebody to tell me: Is this a real bug or something GHC allows itself to do? Since for most other run-time errors, GHC asks me to report a bug, but it doesn't do so for `Impossible case alternative`. It is a GHC bug. Are you sure you have seen GHC ask you to report a bug when running a program compiled by GHC (other than GHC itself)? I don't think that ever happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:19:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:19:23 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.ea7516f4941e3ca5d928243ee9fb9e4d@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): #9766, which had been blocking this for a while, has been fixed, so there's nothing holding this back at the moment. ocharles, would you be willing to rebase your work on top of `master`? You'll need to make some changes to work with the latest GHC: * `Typeable` instances are now derived automatically for everything, so you can remove those. * `Arity` has been removed from `GHC.Generics` * `GHC.Generics` has added some new datatypes: * `FixityI` was added as a type-level counterpart to `Fixity` (this probably doesn't need any instances) * A new data family (`URec`) was added to support `Generic(1)` instances for unboxed types. The data instances could probably use `Functor`, `Foldable`, and `Traversable` instances (I ''think'' those would be well- kinded, but I'd have to check.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:26:29 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.123d8882b80a21766b2baf3b44343514@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): Replying to [comment:1 rwbarton]: > Are you sure you have seen GHC ask you to report a bug when running a program compiled by GHC (other than GHC itself)? I don't think that ever happens. I think you are right, I got confused it with ghci (where I both compiled and ran something, as in #1130). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:44:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:44:15 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.d943b7410c31a5c1173868807b5f6657@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: regression 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 hvr): * cc: adamgundry (added) * priority: normal => highest * keywords: => regression * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:45:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:45:09 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.93fa2af25e75fcd93b8cfe16db892c4f@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 hvr): * priority: highest => high * keywords: regression => Comment: nevermind, not a regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:45:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:45:22 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.00fa08f206ede73163f36b913df65403@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: patch Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): phab:D1585 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:49:12 -0000 Subject: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? In-Reply-To: <042.7aea578c33e94085f5776f18cba04998@haskell.org> References: <042.7aea578c33e94085f5776f18cba04998@haskell.org> Message-ID: <057.0e80cd6c2b027abc82f2d5bf934af3a1@haskell.org> #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 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): The changes Pedro was alluding to involving `DataKinds` have now been implemented (#9766), so that's no longer holding this back. It would be interesting to talk about the pros and cons of changing `Rec1 f` to `f :.: Par1` The obvious pro is that is removes a redundant representation type, making `(:.:)` the sole way to talk about type constructors being applied to the type parameter. I also suspect that this change would make #8516 easier, but that's a different story. There are two cons that I can see: 1. All code that declares instances for `Rec1` would eventually have to be changed. We have a much better story for deprecation than we used to, though, so this isn't a dealbreaker. 2. `Generic1` instances involving `Rec1` have different instance heads than instances involving `(:.:)`. To be more specific, consider this data type: {{{#!hs newtype T1 a = T1 (T2 a) deriving Generic1 }}} Right now, this would be derived `Generic1` instance: {{{#!hs instance Generic1 T1 where type Rep1 T1 = D1 ('MetaData "T1" "Module" "package" 'True) (C1 ('MetaCons "T1" 'PrefixI 'False) (S1 'NoSelector (Rec1 T2))) from1 (T1 a) = M1 (M1 (M1 (Rec1 a))) to1 (M1 (M1 (M1 a))) = T1 (unRec1 a) }}} But with this proposal, it would be this: {{{#!hs instance Generic1 T1 where type Rep1 T1 = D1 ('MetaData "T1" "Module" "package" 'True) (C1 ('MetaCons "T1" 'PrefixI 'False) (S1 'NoSelector (T2 :.: Par1))) from1 (T1 a) = M1 (M1 (M1 (Comp1 (fmap Par1 a)))) to1 (M1 (M1 (M1 a))) = T1 (fmap unPar1 (unComp1 a)) }}} There's one very important difference here. The latter instance requires that `T2` is a `Functor` instance, whereas the former instance does not! It would be interesting to know if this would prevent some datatypes in the wild from being `Generic1` instances. For example, suppose `newtype T2 a = T2 (a -> Int)`. Then we couldn't make `T2` a `Functor`, and thus we couldn't make `T1` `Generic1`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:50:15 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) In-Reply-To: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> References: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> Message-ID: <057.275aec871b20666f867cf1164e21237f@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dolio Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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): Wiki Page: | prime:Libraries/Proposals/ExpandFloating| -------------------------------------+------------------------------------- Changes (by hvr): * owner: => dolio -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:52:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:52:16 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell In-Reply-To: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> References: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> Message-ID: <064.a41a7dc6f93648329136670e91af2f7d@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D1586 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * differential: => Phab:D1586 Comment: I've proposed a simple change to how `reify` works for duplicate record fields, which will mean that normal uses of TH continue to work, but that re-`reify`ing the name of a field will fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:52:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:52:36 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell In-Reply-To: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> References: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> Message-ID: <064.d1adcbf3698cb73fc9c79d569bf323cf@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D1586 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:57:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:57:13 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.50ce428ddb4ed3af6b54d42816ea3433@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: adamgundry Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11167 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry * related: => #11167 Comment: I'll take a look at this. I think a similar issue applies to `DEPRECATED` pragmas and possibly other things that are keyed by `OccName`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:57:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:57:55 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.5e2913ea1018181230dad431fd2391b8@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: records 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 adamgundry): * owner: adamgundry => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 17:58:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 17:58:20 -0000 Subject: [GHC] #10512: Generic instances missing for Int32, Word64 etc. In-Reply-To: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> References: <051.eb2fd15ce978c34ac9303293c51292d1@haskell.org> Message-ID: <066.f1f4ca84f51d3b7f4798e99576bd1348@haskell.org> #10512: Generic instances missing for Int32, Word64 etc. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ekmett (added) Comment: > All I know is that when I tried to generate the Binary instances for my data types, I got the complaint about missing Generic instances for Int32 and Word64. Really? I'm not sure why this would be the case, since in all of the examples I've seen, `Generic` instances don't require that a datatype's arguments also be `Generic`. For example, if you have this: {{{#!hs {-# LANGUAGE DeriveAnyClass, DeriveGeneric #-} data T = T Int32 Word64 deriving (Binary, Generic) }}} Then the generic machinery in `binary` only requires that `Int32` and `Word64` be `Binary` instances. Might I ask what your use case is? It seems ''very'' unlikely that we're going to be adding `Generic` instances for base types like these going forwards. In fact, we're going to [http://git.haskell.org/ghc.git/blobdiff/d4bcd05d7df3138429abdf43d3e3eb8f6da2dcdf..700c42b5e0ffd27884e6bdfa9a940e55449cff6f:/libraries/base/GHC/Generics.hs remove] the `Generic` instances for `Char`, `Double`, `Float`, and `Int` in GHC 8.0 for the reasons that Pedro and Ed described. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 18:15:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 18:15:56 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.70da35fabe92ee7f6d8fd782959a95f0@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | 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:D1573, Wiki Page: | phab:D1587 -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch * differential: phab:D1573 => phab:D1573, phab:D1587 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 18:59:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 18:59:54 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments Message-ID: <050.8afc974fb1620698fac2f086504cf230@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Unlike `Functor` and `Foldable`, `Traversable` cannot be derived for datatypes that contain arguments with unboxed types. A simple example: {{{#!hs {-# LANGUAGE DeriveTraversable, MagicHash #-} import GHC.Prim (Int#) data IntHash a = IntHash Int# deriving (Functor, Foldable, Traversable) }}} The generated `Traversable` instance reveals the issue: {{{#!hs instance Traversable IntHash where traverse f (IntHash a1) = fmap IntHash (pure a1) }}} {{{ Couldn't match kind `*' with `#' When matching types a0 :: * Int# :: # Expected type: a0 -> IntHash b Actual type: Int# -> IntHash b In the first argument of `fmap', namely `IntHash' In the expression: fmap IntHash (pure a1) When typechecking the code for `traverse' in a derived instance for `Traversable IntHash': To see the code I am typechecking, use -ddump-deriv }}} We have to avoid calling `pure` on `a1`, since `pure` expects an argument with a `*`-kinded type, not a `#`-kinded one. One way to fix this would be restructuring the derived `traverse` implementation such that unboxed arguments are moved to the function initially lifted with `pure`, and doing nothing with them later. To better articulate what I mean, envision something like this: {{{#!hs data IntHash2 a = IntHash2 Int# a (IntHash2 a) Int# deriving (Functor, Foldable) }}} Then a derived `Traversable` instance that would typecheck would be: {{{#!hs instance Traversable IntHash2 where traverse f (IntHash2 a1 a2 a3 a4) = pure (\x2 x3 -> IntHash2 a1 x2 x3 a4) <*> f a2 <*> traverse f a3 }}} Conceptually, this doesn't sound hard to implement. The tricky part is figuring out how much of the existing `Functor`/`Foldable`/`Traversable` deriving machinery would need to be tweaked to make this work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 19:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 19:01:09 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.f294a8d0bdd7e97a0fed45d9a6818b69@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I checked, and it turns out that derived `Traversable` instances for `URec` won't kind-check at the moment. This isn't a fundamental limitation of `Traversable`, however. I've opened #11174 regarding this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 19:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 19:03:01 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.b008f4800424e95485fab11062ea8d14@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 RyanGlScott: Old description: > Unlike `Functor` and `Foldable`, `Traversable` cannot be derived for > datatypes that contain arguments with unboxed types. A simple example: > > {{{#!hs > {-# LANGUAGE DeriveTraversable, MagicHash #-} > > import GHC.Prim (Int#) > > data IntHash a = IntHash Int# deriving (Functor, Foldable, Traversable) > }}} > > The generated `Traversable` instance reveals the issue: > > {{{#!hs > instance Traversable IntHash where > traverse f (IntHash a1) = fmap IntHash (pure a1) > }}} > > {{{ > Couldn't match kind `*' with `#' > When matching types > a0 :: * > Int# :: # > Expected type: a0 -> IntHash b > Actual type: Int# -> IntHash b > In the first argument of `fmap', namely `IntHash' > In the expression: fmap IntHash (pure a1) > When typechecking the code for `traverse' > in a derived instance for `Traversable IntHash': > To see the code I am typechecking, use -ddump-deriv > }}} > > We have to avoid calling `pure` on `a1`, since `pure` expects an argument > with a `*`-kinded type, not a `#`-kinded one. > > One way to fix this would be restructuring the derived `traverse` > implementation such that unboxed arguments are moved to the function > initially lifted with `pure`, and doing nothing with them later. To > better articulate what I mean, envision something like this: > > {{{#!hs > data IntHash2 a = IntHash2 Int# a (IntHash2 a) Int# deriving (Functor, > Foldable) > }}} > > Then a derived `Traversable` instance that would typecheck would be: > > {{{#!hs > instance Traversable IntHash2 where > traverse f (IntHash2 a1 a2 a3 a4) = > pure (\x2 x3 -> IntHash2 a1 x2 x3 a4) <*> f a2 <*> traverse f a3 > }}} > > Conceptually, this doesn't sound hard to implement. The tricky part is > figuring out how much of the existing `Functor`/`Foldable`/`Traversable` > deriving machinery would need to be tweaked to make this work. New description: Unlike `Functor` and `Foldable`, `Traversable` cannot be derived for datatypes that contain arguments with unboxed types. A simple example: {{{#!hs {-# LANGUAGE DeriveTraversable, MagicHash #-} import GHC.Prim (Int#) data IntHash a = IntHash Int# deriving (Functor, Foldable, Traversable) }}} The generated `Traversable` instance reveals the issue: {{{#!hs instance Traversable IntHash where traverse f (IntHash a1) = fmap IntHash (pure a1) }}} {{{ Couldn't match kind `*' with `#' When matching types a0 :: * Int# :: # Expected type: a0 -> IntHash b Actual type: Int# -> IntHash b In the first argument of `fmap', namely `IntHash' In the expression: fmap IntHash (pure a1) When typechecking the code for `traverse' in a derived instance for `Traversable IntHash': To see the code I am typechecking, use -ddump-deriv }}} We have to avoid calling `pure` on `a1`, since `pure` expects an argument with a `*`-kinded type, not a `#`-kinded one. One way to fix this would be restructuring the derived `traverse` implementation such that arguments which do not mention the last type parameter are moved to the function initially lifted with `pure`, and doing nothing with them later. To better articulate what I mean, envision something like this: {{{#!hs data IntHash2 a = IntHash2 Int# a (IntHash2 a) Int deriving (Functor, Foldable) }}} Then a derived `Traversable` instance that would type-check (and kind- check) would be: {{{#!hs instance Traversable IntHash2 where traverse f (IntHash2 a1 a2 a3 a4) = pure (\x2 x3 -> IntHash2 a1 x2 x3 a4) <*> f a2 <*> traverse f a3 }}} Conceptually, this doesn't sound hard to implement. The tricky part is figuring out how much of the existing `Functor`/`Foldable`/`Traversable` deriving machinery would need to be tweaked to make this work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 22:51:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 22:51:31 -0000 Subject: [GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.6af83303c73375cca39f51255584be1b@haskell.org> #10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | 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): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "setnumcapabilities-assert-failure-Scheduler.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 22:51:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 22:51:54 -0000 Subject: [GHC] #10860: The test `setnumcapabilities001` sometimes fails on Phabricator In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.7849e4415af4afb34debf2eb0a9740da@haskell.org> #10860: The test `setnumcapabilities001` sometimes fails on Phabricator -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | 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): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "setnumcapabilities-assert-failure-GC.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 7 23:04:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Dec 2015 23:04:09 -0000 Subject: [GHC] #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 (was: The test `setnumcapabilities001` sometimes fails on Phabricator) In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.86b7344ca29666b49ad34eb119769594@haskell.org> #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) Comment: I can reproduce two different assert failures quite reliably. The output of `+RTS -Ds` is attached. Below are the stack traces from gdb. To reproduce: {{{ $ ../../../../inplace/bin/ghc-stage2 -threaded -debug setnumcapabilities001.hs -fforce-recomp $ gdb setnumcapabilities001 (gdb) run 4 8 2000 +RTS -Ds > stdout 2> stderr & }}} Retry the `run` command multiple times, and keep the cpu busy by running for example `ghc -e [0..] > /dev/null` in a separate terminal. Another way to reproduce the assert failures is to run: {{{ $ for i in `seq 1 100`; do echo ok && ./setnumcapabilities001 100 8 2000 +RTS -Ds 2> out || break ; done }}} == Assert failure in the Garbage Colletor == {{{ Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe6ffd700 (LWP 4419)] 0x00007ffff6ea7cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); bt #0 0x00007ffff6ea7cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6eab0d8 in __GI_abort () at abort.c:89 #2 0x000000000078c912 in rtsFatalInternalErrorFn (s=0x80a160 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffe6ffcc68) at rts/RtsMessages.c:182 #3 0x000000000078c54a in barf (s=0x80a160 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:46 #4 0x000000000078c5ad in _assertFail (filename=0x80e9d0 "rts/sm/GC.c", linenum=904) at rts/RtsMessages.c:61 #5 0x00000000007a314b in dec_running () at rts/sm/GC.c:904 #6 0x00000000007a32ec in scavenge_until_all_done () at rts/sm/GC.c:977 #7 0x00000000007a3431 in gcWorkerThread (cap=0x7fffec0214d0) at rts/sm/GC.c:1035 #8 0x0000000000787020 in yieldCapability (pCap=0x7fffe6ffce30, task=0x7fffec035680, gcAllowed=rtsTrue) at rts/Capability.c:708 #9 0x000000000078ee7a in scheduleYield (pcap=0x7fffe6ffce68, task=0x7fffec035680) at rts/Schedule.c:674 #10 0x000000000078e3dd in schedule (initialCapability=0x7fffec0214d0, task=0x7fffec035680) at rts/Schedule.c:298 #11 0x00000000007914a2 in scheduleWorker (cap=0x7fffec0214d0, task=0x7fffec035680) at rts/Schedule.c:2378 #12 0x000000000079a3f0 in workerStart (task=0x7fffec035680) at rts/Task.c:437 #13 0x00007ffff723e182 in start_thread (arg=0x7fffe6ffd700) at pthread_create.c:312 #14 0x00007ffff6f6b47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 }}} == Assert failure in the Scheduler == {{{ Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe77fe700 (LWP 4394)] 0x00007ffff6ea7cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); bt #0 0x00007ffff6ea7cc9 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6eab0d8 in __GI_abort () at abort.c:89 #2 0x000000000078c912 in rtsFatalInternalErrorFn (s=0x80a160 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffe77fdd58) at rts/RtsMessages.c:182 #3 0x000000000078c54a in barf (s=0x80a160 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:46 #4 0x000000000078c5ad in _assertFail (filename=0x80a529 "rts/Schedule.c", linenum=400) at rts/RtsMessages.c:61 #5 0x000000000078e5ef in schedule (initialCapability=0x7fffec0214d0, task=0x7fffe0000910) at rts/Schedule.c:400 #6 0x00000000007914a2 in scheduleWorker (cap=0x7fffec0214d0, task=0x7fffe0000910) at rts/Schedule.c:2378 #7 0x000000000079a3f0 in workerStart (task=0x7fffe0000910) at rts/Task.c:437 #8 0x00007ffff723e182 in start_thread (arg=0x7fffe77fe700) at pthread_create.c:312 #9 0x00007ffff6f6b47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 01:23:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 01:23:38 -0000 Subject: [GHC] #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic Message-ID: <047.29ed0108e386c108bb8327899f548be4@haskell.org> #11175: Holding Ctrl+C on Windows GHCI Prompt crashes with concurrency panic ----------------------------------------+--------------------------------- Reporter: cwfenner | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When I hold Control-C in the GHCI prompt (on either Windows Powershell or Command Prompt), then release, the prompt stops responding. The first few keystrokes will be ignored altogether, then the next ignored intermittently. After typing around 5 words, GHCi crashes with the following output: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation }}} If I don't type after holding Ctrl+C, GHCi seems to sit happily without crashing. No amount of waiting after holding Ctrl+C seems to make it recover. It does not matter whether I press return or not. However, faster typing seems to make it crash in fewer keystrokes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 08:16:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 08:16:50 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.cb38a4fd1f62ebbd1395107e4b6927fa@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | 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:D1240 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"2f6e87a494330837c425dab67ba26ee36bd9eacf/ghc" 2f6e87a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f6e87a494330837c425dab67ba26ee36bd9eacf" Introduce HasGhciState class and refactor use-sites This allows to reach the GhciState without having to keep track how many Monad transformer layers sit on top of the GHCi monad. While at it, this also refactors code to make more use of the existing `modifyGHCiState` operation. This is a preparatory refactoring for #10874 Differential Revision: https://phabricator.haskell.org/D1582 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 08:48:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 08:48:58 -0000 Subject: [GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. Message-ID: <046.937cef8232773714745473eb92c453ee@haskell.org> #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Code: {{{#!hs module B where aaa x = aaa x bbb = aaa 1 }}} === In the renamed AST The reference is to the exported aaa (span 3:1-3, sort WiredIn), which is as expected (by me at least). (dump with ghc-dump-tree with some local mods compiled by GHC 7.10.2) {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar here ------------> { n_loc = /tmp/B.hs:3:1-3 <----------- here , n_sort = { WiredIn = Module main B } , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} === In the typechecked AST Here the call target changes to internal (as described by the monomorphic binding abe_mono). {{{ (HsApp (L /tmp/B.hs:3:9-11 (HsVar { varType = { t -> t = FunTy (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) (TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t }) } here -------------> , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , VarName = aaa })) (L /tmp/B.hs:3:13 (HsVar { varType = { t = TyVarTy { varType = { * = TyConApp * [] } , n_loc = /tmp/B.hs:3:1-13 , n_sort = Internal , TvName = t } } , n_loc = /tmp/B.hs:3:5 , n_sort = Internal , VarName = x }))))) }}} (Just remarking, that GHC 7.8 and 7.10 seem to have improved the span ranges a bit over 7.6, so trying to reproduce with 7.6 the span will be the shorter one on the function name, but the sort will still be the internal). Note that referring the function in a non-recursive way seem to refer to the exported (abe_poly) binding. From the perspective of a tooling writer, this difference is somewhat surprising, and is a case to be handled separately. * Is there a fundamental reason why the reference changes after Typechecking? * Since I'm not deeply familiar with the AST, I might miss something. Does it happen in other cases too that sometimes abe_poly is referred, sometimes the abe_mono? If so, what is the rule? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 10:09:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 10:09:57 -0000 Subject: [GHC] #5273: error and undefined should print a location In-Reply-To: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> References: <047.0c5631d5110d7e8dd17fdeae86e25a82@haskell.org> Message-ID: <062.5895f5d0013ca95c4ed100fd82dd1fc7@haskell.org> #5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Rev(s): Phab:D861 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce/ghc" 9f4ca5a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce" Associate ErrorCall pattern with ErrorCall type This way, import Control.Exception (ErrorCall(ErrorCall)) or import Control.Exception (ErrorCall(..)) work as expected, and import the `ErrorCall` compatibility pattern as well. When #5273 was implemented, it wasn't possible yet to associated patterns with their types (see #10653). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1588 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 10:09:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 10:09:57 -0000 Subject: [GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation In-Reply-To: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> References: <049.0e5a3c33a167308dc99ecaed5730df14@haskell.org> Message-ID: <064.deb6ae96f897cb710026df7ca240be6a@haskell.org> #10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: mpickering Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | PatternSynonyms, pattern synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1258 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce/ghc" 9f4ca5a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f4ca5afaccc8a397d8ee91b5423a9c2fcd151ce" Associate ErrorCall pattern with ErrorCall type This way, import Control.Exception (ErrorCall(ErrorCall)) or import Control.Exception (ErrorCall(..)) work as expected, and import the `ErrorCall` compatibility pattern as well. When #5273 was implemented, it wasn't possible yet to associated patterns with their types (see #10653). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1588 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 10:16:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 10:16:19 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.86ce040e1ce56677a5d9c15b216c4b64@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | 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:D1240 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"fd3b845c01aa26b6e5cd12c00af59e5468e21b1b/ghc" fd3b845c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd3b845c01aa26b6e5cd12c00af59e5468e21b1b" Make HasDynFlags more transformers friendly Ideally, we'd have the more general instance (MonadTrans t, Monad m, HasDynFlags m) => HasDynFlags (t m) where getDynFlags = lift getDynFlags definition. However, that one would overlap with the `HasDynFlags (GhcT m)` instance. Instead we define instances for a couple of common Monad transformers explicitly in order to avoid nasty overlapping instances. This is a preparatory refactoring for #10874 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1581 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 10:26:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 10:26:47 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 8.0.1 RC (was: Update libffi shortly before first GHC 7.12.1 RC) In-Reply-To: <042.27be62378f24cc29ae2d842288972a74@haskell.org> References: <042.27be62378f24cc29ae2d842288972a74@haskell.org> Message-ID: <057.52891ec08704c4aff1199dd2754d6ff4@haskell.org> #10238: Update libffi shortly before first GHC 8.0.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: libffi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1589 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D1589 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 10:32:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 10:32:48 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 8.0.1 RC In-Reply-To: <042.27be62378f24cc29ae2d842288972a74@haskell.org> References: <042.27be62378f24cc29ae2d842288972a74@haskell.org> Message-ID: <057.e6ae92b43bca37e529f310ca1741c379@haskell.org> #10238: Update libffi shortly before first GHC 8.0.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: libffi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1589 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7a40a6cde92896d7de09919499c66324a2d01771/ghc" 7a40a6cd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7a40a6cde92896d7de09919499c66324a2d01771" Update libffi-tarballs submodule to libffi 3.1 (re #10238) Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1589 GHC Trac Issues: #10238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 12:31:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 12:31:18 -0000 Subject: [GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. In-Reply-To: <046.937cef8232773714745473eb92c453ee@haskell.org> References: <046.937cef8232773714745473eb92c453ee@haskell.org> Message-ID: <061.fb3c72fddbf6f6b841313f132286e7ba@haskell.org> #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm surprised that `n_sort` is `WiredIn` for `aaa`. That is most peculiar. Did you read `Note [AbsBinds]` in `HsBinds`? {{{ Note [AbsBinds] ~~~~~~~~~~~~~~~ The AbsBinds constructor is used in the output of the type checker, to record *typechecked* and *generalised* bindings. Consider a module M, with this top-level binding M.reverse [] = [] M.reverse (x:xs) = M.reverse xs ++ [x] In Hindley-Milner, a recursive binding is typechecked with the *recursive* uses being *monomorphic*. So after typechecking *and* desugaring we will get something like this M.reverse :: forall a. [a] -> [a] = /\a. letrec reverse :: [a] -> [a] = \xs -> case xs of [] -> [] (x:xs) -> reverse xs ++ [x] in reverse Notice that 'M.reverse' is polymorphic as expected, but there is a local definition for plain 'reverse' which is *monomorphic*. The type variable 'a' scopes over the entire letrec. That's after desugaring. What about after type checking but before desugaring? That's where AbsBinds comes in. It looks like this: AbsBinds { abs_tvs = [a] , abs_exports = [ABE { abe_poly = M.reverse :: forall a. [a] -> [a], , abe_mono = reverse :: [a] -> [a]}] , abs_binds = { reverse :: [a] -> [a] = \xs -> case xs of [] -> [] (x:xs) -> reverse xs ++ [x] } } Here, * abs_tvs says what type variables are abstracted over the binding group, just 'a' in this case. * abs_binds is the *monomorphic* bindings of the group * abs_exports describes how to get the polymorphic Id 'M.reverse' from the monomorphic one 'reverse' Notice that the *original* function (the polymorphic one you thought you were defining) appears in the abe_poly field of the abs_exports. The bindings in abs_binds are for fresh, local, Ids with a *monomorphic* Id. If there is a group of mutually recursive functions without type signatures, we get one AbsBinds with the monomorphic versions of the bindings in abs_binds, and one element of abe_exports for each variable bound in the mutually recursive group. This is true even for pattern bindings. Example: (f,g) = (\x -> x, f) After type checking we get AbsBinds { abs_tvs = [a] , abs_exports = [ ABE { abe_poly = M.f :: forall a. a -> a , abe_mono = f :: a -> a } , ABE { abe_poly = M.g :: forall a. a -> a , abe_mono = g :: a -> a }] , abs_binds = { (f,g) = (\x -> x, f) } }}} If it's not clear enough I should rewrite it until it is. So yes, there's a fundamental reason. The rule is this: a reference on the RHS goes to the monomorphic version (`abe_mono`) iff * The variable, say 'x', has no type signature * The RHS is part of a mutually recursive group which binds 'x'. To find mutually recursive groups, perform a strongly-connnected-component analysis on the bindings, where there is a an edge from binding `y = ey` to `x = ex` iff * `ey` mentions `x` * `x` does not have a type signature Does that help? How could the Note be better? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 12:35:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 12:35:51 -0000 Subject: [GHC] #11177: panic! tc_hs_type: record Message-ID: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> #11177: panic! tc_hs_type: record --------------------------------+--------------------------------- Reporter: apanagio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- when trying to compile a file where "deriving" was missing from a data type got the message: ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-linux): tc_hs_type: record Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug the source file is: {{{#!hs data Epafi = Epafi { } (Show) main :: IO () main = do print "hello" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 12:43:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 12:43:23 -0000 Subject: [GHC] #11177: panic! tc_hs_type: record In-Reply-To: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> References: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> Message-ID: <062.5ef5e1336841fc5055e1858fac6c59ed@haskell.org> #11177: panic! tc_hs_type: record ---------------------------------+----------------------------- Reporter: apanagio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Changes (by simonpj): * cc: alanz (added) Comment: This looks like fallout from the 'refactor `ConDecl` patch. Alan? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 12:54:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 12:54:28 -0000 Subject: [GHC] #11178: Documentation bug in Data.List.NonEmpty Message-ID: <047.366d4367ffa92509b4848ace839d952a@haskell.org> #11178: Documentation bug in Data.List.NonEmpty -------------------------------------+------------------------------------- Reporter: audunska | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (also filed against the semigroups package) The documentation for cycle says that > cycle [1,2,3] = 1 :| [2,3,1,2,3,...] But the argument should be NonEmpty, so it should read > cycle (1 :| [2,3]) = 1 :| [2,3,1,2,3,...] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 12:54:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 12:54:41 -0000 Subject: [GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. In-Reply-To: <046.937cef8232773714745473eb92c453ee@haskell.org> References: <046.937cef8232773714745473eb92c453ee@haskell.org> Message-ID: <061.6c217706240ac6535ccc13686de93a2d@haskell.org> #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 literon): * status: new => closed * resolution: => wontfix Comment: Makes a lot of sense, thank you! Some comments: * WiredIn results from a ghc-dump-tree printing bug, thanks for noting! * The note is very helpful - unfortunately I often only browse the haddock, so some source-only comments escape me. I often have the feeling that many source comments would be useful haddock comments too. * If you didn't explicitly mention it, I would have missed the requirement for not having a type signature, based on the note only. Maybe "Consider a module M, with this top-level binding [without an explicit type signature]", if that is correct? Resolving ticket, thank you again for the explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 13:04:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 13:04:19 -0000 Subject: [GHC] #11177: panic! tc_hs_type: record In-Reply-To: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> References: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> Message-ID: <062.eb3a3265b890608acad1b1d295b96dad@haskell.org> #11177: panic! tc_hs_type: record ---------------------------------+----------------------------- Reporter: apanagio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by mpickering): It seems that the bug was reported for GHC 7.6.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 13:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 13:05:59 -0000 Subject: [GHC] #11177: panic! tc_hs_type: record In-Reply-To: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> References: <047.0f254c4665a63056f6de68f4cd3f761c@haskell.org> Message-ID: <062.4a0cba92fe1f962d364f00399115b41d@haskell.org> #11177: panic! tc_hs_type: record ---------------------------------+------------------------------ Reporter: apanagio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by jstolarek): * status: new => closed * resolution: => invalid Comment: I checked and 7.8 and 7.10 reject this program with `Record syntax is illegal here: {}`. Closing as invalid (though it might be a duplicate of some bug that was reported in the past). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 15:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 15:05:11 -0000 Subject: [GHC] #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. In-Reply-To: <046.937cef8232773714745473eb92c453ee@haskell.org> References: <046.937cef8232773714745473eb92c453ee@haskell.org> Message-ID: <061.18b5662af204e7bc3c3da8e99aac18ca@haskell.org> #11176: Typechecked AST for recursive top-level call refers to non-exported HsVar. -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6c794c311d5312ba3f92434ee6f35040d3b69353/ghc" 6c794c31/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c794c311d5312ba3f92434ee6f35040d3b69353" Comments about polymorphic recursion See Trac #11176 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 15:34:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 15:34:54 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.aa8e3b735e294f4ebf136133cdd336c7@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): I'd like to reproduce, but I get this (with the current HEAD). Any suggestions, anyone? {{{ bash$ cabal install --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin /ghc-stage2 Resolving dependencies... cabal: Could not resolve dependencies: trying: impossible-case-alternative-repro-0.0 (user goal) trying: base-4.9.0.0/installed-4.9... (dependency of impossible-case-alternative-repro-0.0) trying: either-4.4.1 (dependency of impossible-case-alternative-repro-0.0) trying: semigroupoids-5.0.0.4 (dependency of either-4.4.1) trying: semigroupoids-5.0.0.4:+tagged trying: semigroupoids-5.0.0.4:+comonad trying: comonad-4.2.7.2 (dependency of semigroupoids-5.0.0.4:+comonad) trying: comonad-4.2.7.2:+distributive trying: comonad-4.2.7.2:+contravariant trying: contravariant-1.3.3 (dependency of comonad-4.2.7.2:+contravariant) trying: void-0.7.1 (dependency of contravariant-1.3.3) next goal: hashable (dependency of void-0.7.1) rejecting: hashable-1.2.3.3, 1.2.3.2 (conflict: base==4.9.0.0/installed-4.9..., hashable => base>=4.0 && <4.9) rejecting: hashable-1.2.3.1, 1.2.3.0, 1.2.2.0, 1.2.1.0, 1.2.0.10, 1.2.0.9, 1.2.0.8, 1.2.0.7, 1.2.0.6, 1.2.0.5, 1.2.0.4, 1.2.0.3, 1.2.0.2, 1.2.0.1, 1.2.0.0, 1.1.2.5, 1.1.2.4, 1.1.2.3 (conflict: base==4.9.0.0/installed-4.9..., hashable => base>=4.0 && <4.8) rejecting: hashable-1.1.2.2, 1.1.2.1, 1.1.2.0, 1.1.1.0, 1.1.0.0 (conflict: base => ghc-prim==0.5.0.0/installed-0.5..., hashable => ghc-prim<0.3) rejecting: hashable-1.0.1.1, 1.0.1.0, 1.0.0 (conflict: void => hashable>=1.1) Dependency tree exhaustively searched. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 17:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 17:35:20 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" Message-ID: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- GHC removes dead-bindings quite early in the compilation process, which makes perfect sense from a pure compilation point of view. But with user- plugins, some of the dead-bindings can be interesting: They might be properties or other code that instructs the plugin to do a certain action, even if the binding isn't otherwise used anywhere else or exported. (Think of embedded properties.) Here's a discussion about the issue, where SimonPJ asked for a ticket to be filed: [http://mail.haskell.org/pipermail/ghc- devs/2015-December/010708.html] It appears the desugarer removes some of the dead-code. One option could be to stop the desugarer from doing that, and leaving it to the later optimizer passes so plugins can still see all the bindings (if they run early enough), or require the user to put in an "KeepAlive" pragma on bindings that she cares about. While keeping all-dead code in the desugarer would be the simplest thing to do, requiring the user to put in a pragma isn't a terrible solution either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 17:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 17:46:48 -0000 Subject: [GHC] #11169: Remove the word "skolem" from user error messages In-Reply-To: <045.5b94ce81fe35377ff5af0392dcafee0f@haskell.org> References: <045.5b94ce81fe35377ff5af0392dcafee0f@haskell.org> Message-ID: <060.f2302ed82e5783d7c90aaba27fa6766d@haskell.org> #11169: Remove the word "skolem" from user error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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 kanetw): I agree, opaque words like rigid/skolem here should be replaced with something more comprehensible to normal users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 17:47:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 17:47:48 -0000 Subject: [GHC] #10527: Panic Simplifier ticks exhausted with type families In-Reply-To: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> References: <045.3e1b7beda71c6891caa1dc0451a59ca1@haskell.org> Message-ID: <060.154ea147253dd944c0cdbc132379e6f3@haskell.org> #10527: Panic Simplifier ticks exhausted with type families -------------------------------------+------------------------------------- Reporter: sopvop | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is now fixed on `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:15:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:15:23 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.9d398b1b248c6922e17290d74c004ae2@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:29:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:29:17 -0000 Subject: [GHC] #609: Useful optimisation for set-cost-centre In-Reply-To: <046.f04d8146962f266f7ad02f26719b5ba3@haskell.org> References: <046.f04d8146962f266f7ad02f26719b5ba3@haskell.org> Message-ID: <061.67365ba663da859f26844844e5b7cd7b@haskell.org> #609: Useful optimisation for set-cost-centre -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Profiling | Version: None Resolution: None | Keywords: 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): Is this ticket still valid? I just tried to reproduce this, but I don't think we're generating `scc` calls anymore. (maybe scc operation is done by the RTS now?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:40:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:40:44 -0000 Subject: [GHC] #11180: A program writing to a read-only stdout should not succeed Message-ID: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> #11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- In the shell, redirection of file descriptors can be read-only (<), write- only (>), or read-write (<>). A program trying to write to stdout, while stdout is redirected read-only, currently exits with exit code 0. {{{ $ cat hello.hs main = print "hello world" $ ghc hello.hs ... $ ./hello 1< /dev/null; echo Exit status: $? Exit status: 0 }}} This should however show some error message, and return some non-zero error message, because the write never succeeds. Note that this example is different from `./hello 1> /dev/null`, which rightfully does succeed. As suggested by this [http://roscidus.com/blog/blog/2013/06/09/choosing-a -python-replacement-for-0install/ blog post]: > "If you?re not sure why this is important, imagine the command is `dump-database > backup` and the filesystem is full." Supposedly OCaml gets this right. For reference, from my bash man page: > *Redirecting Input* > > Redirection of input causes the file whose name results from the expansion of word to be opened for reading on file descriptor n, or the standard input (file descriptor 0) if n is not specified. > > The general format for redirecting input is: > > [n] GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:46:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:46:09 -0000 Subject: [GHC] #11181: Program hands forever in sched_yield() / yield() unless -N is limited Message-ID: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> #11181: Program hands forever in sched_yield() / yield() unless -N is limited ---------------------------------------+---------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Solaris Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- We have a web application executable that, when run with -N24 (on our 24-core machine) hangs indefinitely, taking up 100% CPU. Introspecting with strace reveals that it's stuck in {{{yield}}} (on native SmartOS) and {{{shed_yield}}} (on both SmartOS LX and Linux emulation with KVM). If we run with +RTS -N2 -RTS, we do not observe this behavior. Attached is the output of truss(1) on an instance of a hung process. Other possibly-relevant information: this is an instance of the Warp web server and the Snap framework. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:49:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:49:41 -0000 Subject: [GHC] #11181: Program hands forever in sched_yield() / yield() unless -N is limited In-Reply-To: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> References: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> Message-ID: <069.1e0fe7893ebc67fcebdf2514ff7f08a2@haskell.org> #11181: Program hands forever in sched_yield() / yield() unless -N is limited ------------------------------------+-------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by patrick_thomson): The trace was too lengthy to attach. Find it here: https://gist.github.com/patrickt/8c1e7a0587270d341350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 19:52:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:52:14 -0000 Subject: [GHC] #11181: Program hangs forever in sched_yield() / yield() unless -N is limited (was: Program hands forever in sched_yield() / yield() unless -N is limited) In-Reply-To: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> References: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> Message-ID: <069.b721d9d928df1bb1bdb784a1c229b730@haskell.org> #11181: Program hangs forever in sched_yield() / yield() unless -N is limited ------------------------------------+-------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | 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 Dec 8 19:57:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 19:57:17 -0000 Subject: [GHC] #11181: Program hangs forever in sched_yield() / yield() unless -N is limited In-Reply-To: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> References: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> Message-ID: <069.38d88cc5b97ee4c565e430b62a34345e@haskell.org> #11181: Program hangs forever in sched_yield() / yield() unless -N is limited ------------------------------------+-------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by thomie): * cc: simonmar (added) * component: Compiler => Runtime System Comment: Is this during shutdown by any chance? Maybe related to #10860. The output of `./your-program +RTS -Ds` could be useful, as well as a backtrace from gdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:03:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:03:03 -0000 Subject: [GHC] #11181: Program hangs forever in sched_yield() / yield() unless -N is limited In-Reply-To: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> References: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> Message-ID: <069.83308c0d0d2cb704eb5ce8d600c7464b@haskell.org> #11181: Program hangs forever in sched_yield() / yield() unless -N is limited ------------------------------------+-------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by patrick_thomson): @thomie Nope, this is during the initialization of the web server. I'm working on the backtraces/debug output now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:08:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:08:00 -0000 Subject: [GHC] #11181: Program hangs forever in sched_yield() / yield() unless -N is limited In-Reply-To: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> References: <054.6cf1abe9b8f7a7a0675658ba497dc8af@haskell.org> Message-ID: <069.3fec54bced1cb9f858fdcfcf43d1551e@haskell.org> #11181: Program hangs forever in sched_yield() / yield() unless -N is limited ------------------------------------+-------------------------------------- Reporter: patrick_thomson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by patrick_thomson): @thomie gdb says it's stuck in ioctl/epoll: https://gist.github.com/patrickt/7b358c533d832a8625aa -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:21:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:21:35 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData Message-ID: <050.7371157dda089c577427400940c719c0@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #8347 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this code: {{{#!hs {-# LANGUAGE Strict #-} data Lazy a = Lazy ~a main :: IO () main = case Lazy undefined of Lazy _ -> putStrLn "Lazy" }}} fails with the following error: {{{ $ .\inplace\bin\ghc-stage2.exe ../Lazy.hs [1 of 1] Compiling Main ( ..\Lazy.hs, ..\Lazy.o ) ..\Lazy.hs:3:15: error: * Lazy annotation (~) without StrictData on the first argument of `Lazy' * In the definition of data constructor `Lazy' In the data type declaration for `Lazy' }}} I was under the impression that `-XStrict` implied `-XStrictData`. Is this not the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:29:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:29:04 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData In-Reply-To: <050.7371157dda089c577427400940c719c0@haskell.org> References: <050.7371157dda089c577427400940c719c0@haskell.org> Message-ID: <065.40109f01ace17912cb00ce95eae3b400@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tibbe): It should imply `-XStrictData` or else it's a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:30:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:30:19 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData In-Reply-To: <050.7371157dda089c577427400940c719c0@haskell.org> References: <050.7371157dda089c577427400940c719c0@haskell.org> Message-ID: <065.27a85927a280e31b67ae7b4b1dffc2ae@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: adamse Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * owner: => adamse Comment: It definitely should, and definitely did at some point during my development: it must have been lost during a rebase. Will investigate! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:43:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:43:48 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData In-Reply-To: <050.7371157dda089c577427400940c719c0@haskell.org> References: <050.7371157dda089c577427400940c719c0@haskell.org> Message-ID: <065.b6d68fcf444b5adb101d2a9f2ac943eb@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: adamse Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8347 | Differential Rev(s): Phab:D1592 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * differential: => Phab:D1592 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:46:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:46:49 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.9f98ce75afc457d7b204e3359de303c0@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Currently, the {{{template-haskell}}} API is lagging behind what is > possible with GHC's strictness annotations in data types, especially > since the advent of {{{StrictData}}}. Currently, {{{template-haskell}}} > has {{{Strict}}}: > > {{{#!hs > data Strict > = IsStrict > | NotStrict > | Unpacked > }}} > > But it appears that there are actually nine different combinations of > packedness and strictness annotations: > > {{{#!hs > data A = A Int -- No unpackedness, no strictness > data A = A !Int -- No unpackedness, strict > data A = A ~Int -- No unpackedness, lazy > data A = A {-# NOUNPACK #-} A Int -- NOUNPACK, no strictness > data A = A {-# NOUNPACK #-} A !Int -- NOUNPACK, strict > data A = A {-# NOUNPACK #-} A ~Int -- NOUNPACK, lazy > data A = A {-# UNPACK #-} A Int -- UNPACK, no strictness > data A = A {-# UNPACK #-} A !Int -- UNPACK, strict > data A = A {-# UNPACK #-} A ~Int -- UNPACK, lazy > }}} > > It seems like the most consistent thing to do would be change > {{{Strict}}} and add {{{Unpack}}} to the {{{template-haskell}}} API: > > {{{#!hs > data Strict > = IsStrict > | NotStrict > | IsLazy > > data Unpack > = Unpack > | NoUnpack > | NotUnpacked > > type UnpackStrictType = (Unpack, Strict, Type) > > type VarUnpackStrictType = (Name, Unpack, Strict, Type) > }}} > > And so on. New description: Currently, the {{{template-haskell}}} API is lagging behind what is possible with GHC's strictness annotations in data types, especially since the advent of {{{StrictData}}}. Currently, {{{template-haskell}}} has {{{Strict}}}: {{{#!hs data Strict = IsStrict | NotStrict | Unpacked }}} But it appears that there are actually nine different combinations of packedness and strictness annotations: {{{#!hs data A = A Int -- No unpackedness, no strictness data A = A !Int -- No unpackedness, strict data A = A ~Int -- No unpackedness, lazy data A = A {-# NOUNPACK #-} Int -- NOUNPACK, no strictness data A = A {-# NOUNPACK #-} !Int -- NOUNPACK, strict data A = A {-# NOUNPACK #-} ~Int -- NOUNPACK, lazy data A = A {-# UNPACK #-} Int -- UNPACK, no strictness data A = A {-# UNPACK #-} !Int -- UNPACK, strict data A = A {-# UNPACK #-} ~Int -- UNPACK, lazy }}} It seems like the most consistent thing to do would be change {{{Strict}}} and add {{{Unpack}}} to the {{{template-haskell}}} API: {{{#!hs data Strict = IsStrict | IsLazy | NoStrictAnnot data Unpack = Unpack | NoUnpack | NoUnpackAnnot type UnpackStrict = (Unpack, Strict) type UnpackStrictType = (UnpackStrict, Type) type VarUnpackStrictType = (Name, UnpackStrict, Type) type StrictType = UnpackStrictType type VarStrictType = VarUnpackStrictType }}} And so on. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 20:53:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 20:53:36 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.f1cfd1ce0ced53032c28e364752dec6c@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: adamse (added) Comment: It turns out that even without considering `NOUNPACK`, `Strict` and `TemplateHaskell` don't play well together at the moment. This code: {{{#!hs {-# LANGUAGE StrictData, TemplateHaskell #-} import Language.Haskell.TH data T a = T !a a ~a $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . show) }}} produces this output (prettied up a bit): {{{#!hs TyConI (DataD [] Main.T [KindedTV a_1627391747 StarT] [NormalC Main.T [ (IsStrict, VarT a_1627391747) , (NotStrict,VarT a_1627391747) , (NotStrict,VarT a_1627391747) ]] []) }}} Which is pretty darn misleading, since the second argument is actually strict! That being said, I'm not exactly sure what it ''should'' output here. One might could argue is should be `(IsStrict, NotStrict, IsLazy)`, but then again, the definition of `NotStrict` depends on whether `StrictData` is enabled or not. If we output `(Strict, NotStrict, IsLazy)`, then would splicing the TH code for that datatype into a module without `StrictData` fail (since `IsLazy` implies a laziness annotation)? Perhaps TH should check whether `StrictData` is on and splice accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 21:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 21:04:26 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.453a7564887007e3b0687aad0ab9bdae@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): I remember discussing this during development, but I don't remember why no change was made. I think someone (Simon?) said that the TH ast is supposed to represent source code and therefore your suggestion makes sense to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 21:19:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 21:19:46 -0000 Subject: [GHC] #11180: A program writing to a read-only stdout should not succeed In-Reply-To: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> References: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> Message-ID: <060.ee3f9dd6d64bcaba0ac3ce69ae48e85b@haskell.org> #11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this is quite unexpected. I believe the relevant code it is `libraries/base/GHC/IO/FD.hs:writeRawBufferPtrNoBlock`. Judging by the code it ought to be throwing an exception. I'm not yet sure why it is not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 21:37:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 21:37:21 -0000 Subject: [GHC] #11180: A program writing to a read-only stdout should not succeed In-Reply-To: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> References: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> Message-ID: <060.e91b3a0ab4d0b5d0050a52e6cf44d7c7@haskell.org> #11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It does fail if you add a `hFlush stdout` after the `print`. After `main` finishes, apparently control somehow reaches `hs_exit()`, which calls `flushStdHandles()` which in turn calls the Haskell function `flushStdHandles` defined as {{{ -- try to flush stdout/stderr, but don't worry if we fail -- (these handles might have errors, and we don't want to go into -- an infinite loop). flushStdHandles :: IO () flushStdHandles = do hFlush stdout `catchAny` \_ -> return () hFlush stderr `catchAny` \_ -> return () }}} So, it's apparently intentional. I agree this is poor, though. Maybe we should swallow exceptions when flushing stderr, but not stdout? Or at least have the exception handler cause the program to exit with a different status code (if that's still possible at this point)? For what it's worth gcc does the same thing as ghc currently does (the error status of the `fflush` that happens after `main` finishes is apparently not checked). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 21:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 21:59:31 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.1de542658f8f296f5e599332231d6dfa@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | 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:D1240 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7997d6c0f0ba4560dab799cd87850917e0df5e2f/ghc" 7997d6c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7997d6c0f0ba4560dab799cd87850917e0df5e2f" Refactor GHCi Command type; allow "hidden" commands This transforms the 'Command' tuple into a record which is easier to extend. While at it, this refactoring turns the IDE `:complete` into a hidden command excluded from completion. The next obvious step is to add a summary text field for constructing the `:help` output (as well as allowing to get `:help ` for single commands. This is a preparatory refactoring for D1240 / #10874 Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1590 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 22:13:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 22:13:37 -0000 Subject: [GHC] #11180: A program writing to a read-only stdout should not succeed In-Reply-To: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> References: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> Message-ID: <060.9fa9a9c3cbea7f326b8134f6835413e7@haskell.org> #11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Or don't do any automatic flushing of handles on exit. Teach people to always flush/close handles manually, as they have to do already with other handles but stdout/stderr, as noted in commit message 47f3a578a22ed5942ed44ddc81dfd362060e78b4: {{{ Author: simonmar Date: Fri Jan 21 16:02:48 2005 +0000 [project @ 2005-01-21 16:02:47 by simonmar] Don't try to run finalizers at program exit. This turned out to be hard if not impossible to do in general, so now we don't attempt it at all. The Main.main wrapper, previously called runIO and now called runMainIO, flushes stdout and stderr before exiting. This should catch most cases where programs rely on Handles being flushed at program exit, but note that now if you simply drop a Handle in your program, there's no guarantee it'll be flushed on exit. If the punters complain enough, I suppose we could implement a global Handle table and flush them all at exit... I'd rather not do this if possible, though. Better to teach people to close their Handles properly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 8 23:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Dec 2015 23:10:46 -0000 Subject: [GHC] #11180: A program writing to a read-only stdout should not succeed In-Reply-To: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> References: <045.32e51e5c9d825eeda3568b5614bc3a2c@haskell.org> Message-ID: <060.95254cee2ec4aac2ed2f9d1b82f4ef62@haskell.org> #11180: A program writing to a read-only stdout should not succeed -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): That seems needlessly spiteful and different from every other language and will cause many more data loss problems. It's traditionally the programmer's responsibility to close handles that they opened, but the handles `stdin`/`stdout`/`stderr` are opened automatically and so it makes sense to close them automatically too, or at least behave as though they are closed (by flushing the buffers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 02:38:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 02:38:02 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell In-Reply-To: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> References: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> Message-ID: <062.52cf1edf37ab2406e25894a1cb9d0d84@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | 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): Wiki Page: | TemplateHaskell/Introspective | -------------------------------------+------------------------------------- Changes (by lerkok): * cc: lerkok (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 02:46:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 02:46:42 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell In-Reply-To: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> References: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> Message-ID: <062.ae8b313ddb11a78f54e0557227e2dd95@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | 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): Wiki Page: | TemplateHaskell/Introspective | -------------------------------------+------------------------------------- Comment (by lerkok): I think this is a great idea. In the past, I've tried both TH and haskell- src-exts to do relatively simple things, but ended-up abandoning them due to the inherent complexity of source level haskell that had very little to do with what I really cared about. Being able to get your hands on Core at the regular Haskell level would truly simplify life, and I suspect would open the flood-gates for a lot of people to develop extremely useful artifacts, making the GHC/Haskell experience even better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 03:15:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 03:15:58 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell In-Reply-To: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> References: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> Message-ID: <062.3b19578304a276643d06e69c59ac5033@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | 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): Wiki Page: | TemplateHaskell/Introspective | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 09:03:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 09:03:25 -0000 Subject: [GHC] #11183: Numeric.showFFloat outputs decimal point when it should not. Message-ID: <046.d3c43edae72a062bbf9240e8568707dd@haskell.org> #11183: Numeric.showFFloat outputs decimal point when it should not. -------------------------------------+------------------------------------- Reporter: Dobiasd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: Numeric, | Operating System: Unknown/Multiple showFFloat, showFFloatAlt | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs showFFloat Nothing 42 "" }}} The expression above should give "42" but actually gives "42.0". Only showFFloatAlt should do this. Minimal example: http://ideone.com/yYvqrf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 09:14:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 09:14:19 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.9589d684bb893dd030526210054b3244@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"af77089b08b60c00128f0e5a65d18211ea62dfee/ghc" af77089/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af77089b08b60c00128f0e5a65d18211ea62dfee" Fix DeriveAnyClass (Trac #9968) The main issue concerned things like data T a = MkT a deriving( C Int ) which is supposed to generate instance C Int (T a) where {} But the 'Int' argument (called cls_tys in the code) wasn't even being passed to inferConstraints and mk_data_eqn, so it really had no chance. DeriveAnyClass came along after this code was written! Anyway I did quite a bit of tidying up in inferConstraints. Also I discovered that this case was not covered at all data T a b = MkT a b deriving( Bifunctor ) What constraints should we generate for the instance context? We can deal with classes whose last arg has kind *, like Eq, Ord; or (* -> *), like Functor, Traversable. But we really don't have a story for classes whose last arg has kind (* -> * -> *). So I augmented checkSideConditions to check for that and give a sensible error message. ToDo: update the user manual. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 09:26:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 09:26:23 -0000 Subject: [GHC] #11183: Numeric.showFFloat outputs decimal point when it should not. In-Reply-To: <046.d3c43edae72a062bbf9240e8568707dd@haskell.org> References: <046.d3c43edae72a062bbf9240e8568707dd@haskell.org> Message-ID: <061.d4700b47afa534ff89f4860bb1b13290@haskell.org> #11183: Numeric.showFFloat outputs decimal point when it should not. -------------------------------------+------------------------------------- Reporter: Dobiasd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: invalid | Keywords: Numeric, | showFFloat, showFFloatAlt 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 Dobiasd): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 09:35:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 09:35:55 -0000 Subject: [GHC] #11183: Numeric.showFFloat outputs decimal point when it should not. In-Reply-To: <046.d3c43edae72a062bbf9240e8568707dd@haskell.org> References: <046.d3c43edae72a062bbf9240e8568707dd@haskell.org> Message-ID: <061.01d27c3ccf68c23dc9831463d79efefb@haskell.org> #11183: Numeric.showFFloat outputs decimal point when it should not. -------------------------------------+------------------------------------- Reporter: Dobiasd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: invalid | Keywords: Numeric, | showFFloat, showFFloatAlt 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 thomie): Some discussion here: https://www.reddit.com/r/haskell/comments/3w1rjd/numericshowffloat_vs_numericshowffloatalt/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 09:42:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 09:42:54 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.66f6294838835e5a9c06128e9a5348ce@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, TH is supposed to reflect source code. So if source code can have bangs and twiddles, than TH should too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 11:19:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 11:19:36 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code Message-ID: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Aeson.TH data Record = Record { type_ :: Int } $(deriveJSON defaultOptions{ fieldLabelModifier = \x -> case x of "type_" -> "type" _ -> x } ''Record) }}} gives {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): tcMonoExpr _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 11:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 11:40:27 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.9df6e1789c1035a3332853f98e812c8d@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 phadej): This happens because some "grammar" checks happen after the parsing phase: This fails with parse error: {{{ foo = \x -> case x of "foo" -> "bar" _ -> x {- bar.hs:32:21: parse error on input ?->? -} }}} But this, which is triggered in TH slice, is something different: {{{ foo = (\x -> case x of "foo" -> "bar" _ -> x) {- bar.hs:20:8: Pattern syntax in expression context: \ x -> case x of { "foo" -> "bar" (...) } -> x -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 11:50:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 11:50:34 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.079ba4ec6078931d7d988fdfda66e5e9@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+---------------------------------- Reporter: waern | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Can someone distill from the Github issue a concise set of instructions to reproduce this issue? I have installed nix but it's totally unclear to me how to reproduce this. At the moment I have, {{{ $ cd ~/ghc/ghc $ nix-shell -Ahaskell.packages.ghcHEAD.ghc '' error: Package ?VisualBoyAdvance-1.7.2? in ?/nix/store /p1jp78n8mmk5sj9wpz5hf5jk8x8zqcdy- nixpkgs-16.03pre71923.3087ef3/nixpkgs/pkgs/misc/emulators/VisualBoyAdvance/default.nix:18? is marked as broken, refusing to evaluate. For `nixos-rebuild` you can set { nixpkgs.config.allowBroken = true; } in configuration.nix to override this. For `nix-env` you can add { allowBroken = true; } to ~/.nixpkgs/config.nix. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 13:40:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 13:40:13 -0000 Subject: [GHC] #11081: Implement Introspective Template Haskell In-Reply-To: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> References: <047.67eb7661a40be634ed16872d272a44ca@haskell.org> Message-ID: <062.7ed056e19ef3f67fac80798847805c19@haskell.org> #11081: Implement Introspective Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | 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): Wiki Page: | TemplateHaskell/Introspective | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sceptical about the stuff about Core until I see more details. But that's for the future. The fundamental idea here is to replace `Language.Haskell.TH.Syntax` outright with `HsSyn`. The advantages, of course, are (a) avoiding duplication, (b) TH stop lagging GHC. The disadvantage is that `HsSyn` is designed as an internal data type for a compiler. We feel free to * decorate it with extra information (mostly types) as it moves down the pipeline, * have one constructor before type checking and a different one afterwards (eg `ConPatIn` and `ConPatOut` in `HsPat` * add elaboration info for type and dictionary applications and instantiation. For TH programs that construct syntax trees directly (ie not using quotation) or pattern-match over them, all this extra clutter might be confusing and/or awkward. I'm very unsure about the back-compat shim, but maybe it's possible. Yay for pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 13:42:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 13:42:42 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.eb890ba526b3e5f4bc3840d99b04042e@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"83178931aa7e244b7c37860d03e2ab4a29d6a34e/ghc" 8317893/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83178931aa7e244b7c37860d03e2ab4a29d6a34e" Improve documentation for DeriveAnyClass c.f. Trac #9968 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 13:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 13:43:24 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.664255058f701a690a4ffd69c5d151a9@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T9968, | should_fail/T9968a Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => deriving/should_compile/T9968, should_fail/T9968a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:07:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:07:03 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.e158ab27742682996a07e863b9c63c62@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+---------------------------------- Reporter: waern | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by simons): We have the exact same issue with GHC 7.10.3. See http://hydra.cryp.to/build/1411032/log/raw for a complete build log. Run {{{ nix-build ~/src/nixpkgs -A haskell.compiler.ghc7103 }}} to re-produce, where `~/src/nixpkgs` refers to a recent checkout of the Nixpkgs `master` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:08:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:08:42 -0000 Subject: [GHC] #11147: Linker errors related to response files change In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.38f231ba519156dbd3ec5768ccb37f24@haskell.org> #11147: Linker errors related to response files change ----------------------------------------+---------------------------------- Reporter: waern | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by simons): * cc: simons@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:17:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:17:17 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.20441be267ceb2062f0845ccf7785e3c@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 phadej): Also happens with latest HEAD {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151209 for x86_64-apple-darwin): tcMonoExpr _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:35:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:35:03 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.3fafc43151f4dfbfdef99f51841c1830@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature request | 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: #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #9479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:50:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:50:38 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.842828e03fa3deeb7efa48e936dd2c63@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): Simon, for reproducing with GHC 8 HEAD it seems a little more effort is needed, but it seems to work for me this way: * From my repro, use the `ghc-8-head` branch instead (https://github.com/fpco/impossible-case-alternative- repro/tree/ghc-8-head); use `cabal install --with-ghc=...` as you did, it will now break at compiling `aeson` because that's not yet GHC 8 ready; ignore that issue * Use my custom `aeson` version from https://github.com/nh2/aeson/tree/ghc-8-head-workaround, which should compile with `cabal install --with-ghc=...` Then you should be able to `ghc --make` with GHC head. Please let me know if it works! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 15:51:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 15:51:57 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.627934c6738ac9207a7da8f3aca9e89e@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What I'm still very unsure about is how we should handle strictness in `reify` versus handling strictness during splicing. When spicing in a data declaration, we should probably interpret it as literally as possible. For example, {{{#!hs [d| data U = U {-# UNPACK #-} Int |] }}} should splice just that, even though GHC would notice that a field is marked `{-# UNPACK #-}` without a strictness annotation, emit a warning, and then change that field to lazy afterwards. (On a side note, TH currently doesn't parse `{-# UNPACK #-}` annotations, but that would be easy to fix.) On the other hand, if we were to define a datatype [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0:/compiler/basicTypes/DataCon.hs#l499 like this]: {{{#!hs data T = MkT !Int {-# UNPACK #-} !Int Bool }}} and call `reify ''T`, the strictness annotations would probably be meaningless by themselves. You'd need to know whether `-O`, `-funbox- strict-fields`, and/or `-XStrictData` were enabled to get the full story. I believe this is why internally, GHC distinguishes between [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0:/compiler/basicTypes/DataCon.hs#l457 HsSrcBangs] (strictness annotations as the user wrote) and [http://git.haskell.org/ghc.git/blob/688069ca83e949b9bde9883af7df26114e2f9bc0:/compiler/basicTypes/DataCon.hs#l470 HsImplBangs] (strictness annotations as GHC interprets them). With TH, we can cheat a little bit by using the [https://phabricator.haskell.org/D1200 forthcoming] `isExtEnabled` functionality to query whether `StrictData` is turned on, but for a [https://ghc.haskell.org/trac/ghc/ticket/10716 similar ticket] involving the ability to lookup strictness via generics, we have no such escape hatch. We should probably come up with a satisfying answer to this question so we can have a uniform treatment of strictness reification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 16:05:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 16:05:01 -0000 Subject: [GHC] #11185: runghc can't find ghc-stage2 on a Windows build Message-ID: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> #11185: runghc can't find ghc-stage2 on a Windows build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 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: -------------------------------------+------------------------------------- (Originally [https://mail.haskell.org/pipermail/ghc- devs/2015-December/010729.html reported] on the ghc-devs mailing list.) After completing a stage-2 GHC build on Windows, `runghc` does not work at all. Calling it on any file will result in the following error: {{{ $ .\ghc\inplace\bin\runghc.exe Z.hs runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc: rawSystem: does not exist (No such file or directory) }}} A workaround is to make a symlink to `ghc-stage2` with `ln -s ghc- stage2.exe ghc.exe` in MSYS2. This leads me to believe that Windows' `runghc` is always looking for `ghc` even when it ''should'' be looking for `ghc-stage2` in this particular scenario. [http://git.haskell.org/ghc.git/blob/1f1c7c610b0ff26dccaef089e27003497fa25beb:/utils/runghc/Main.hs#l56 This code] in `runghc` looks highly suspect: {{{#!hs let ghc = takeDirectory (normalise path) "ghc" in uncurry (doIt ghc) $ getGhcArgs args' }}} It probably shouldn't be hardcoding the name `"ghc"` here. On Unix-like OSes, this doesn't appear to be an issue since `runghc` invokes a [http://git.haskell.org/ghc.git/blob/6d17125dccda76b7aafe33181df822045ff5b9bf:/utils/runghc/runghc.wrapper shell script] that detects the proper `ghc` name and invokes the `runghc` ''executable''. On the other hand, I believe on Windows calling `runghc` directly invokes the executable, so the proper name detection never happens. What would be a proper fix for this? I'm tempted to just have `runghc` check for `ghc-stage2`'s existence and fall back on `ghc`, but I'd like to get the opinions of people familiar with the build system so that the fix is robust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 16:12:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 16:12:49 -0000 Subject: [GHC] #11186: Give strong preference to type variable names in scope when reporting hole contexts Message-ID: <045.ec3602207be70a11c13d8a0bda77bb5a@haskell.org> #11186: Give strong preference to type variable names in scope when reporting hole contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: typed-holes | 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 using `ScopedTypeVariables` with typed holes, I want GHC to bend over backwards to preserve the names of type variables that the user has chosen to bring into scope. I can't immediately reproduce the situations I've run into recently where that hasn't happened, but sometimes I've had a signature like {{{#!hs foo :: forall bar . ... foo = ... _ ... }}} and yet the typed hole message shows that `bar` has been lost in unification and replaced by some unrelated name. I would very much prefer if this never happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 16:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 16:23:08 -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.831b52ed7f53c81604fe4e87347952b8@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): Can you give a concrete example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 16:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 16:48:10 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.6c8b1b06d7b92adc40a26bf9a01260d7@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dsf): This could use a milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 18:38:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 18:38:32 -0000 Subject: [GHC] #11187: Odd interaction between type families and coercions (regression) Message-ID: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> #11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} module Wonk where import Data.Type.Coercion type family X coercionXX :: Coercion X X coercionXX = Coercion }}} This works just fine in 7.8.3, but in 7.10.2 it gives the following peculiar error: {{{ Couldn't match representation of type ?X? with that of ?X? NB: ?X? is a type function, and may not be injective In the expression: Coercion In an equation for ?coercionXX?: coercionXX = Coercion }}} I don't even know what it means for a ''nullary'' type function to be injective. I tried the following workarounds: {{{#!hs coercionXX1 :: Coercion X X coercionXX1 = c where c :: x ~ X => Coercion x x c = Coercion coercionXX2 :: Coercion X X coercionXX2 = c where c = Coercion }}} Interestingly, `coercionXX1` seems to work under all circumstances, with or without the top-level type signature; `coercionXX2` works if it's in a `.hs` file, but does ''not'' work if entered by hand at the `ghci` prompt (it produces a similar error). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 19:18:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 19:18:52 -0000 Subject: [GHC] #11187: Odd interaction between type families and coercions (regression) In-Reply-To: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> References: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> Message-ID: <060.63c7d249054d162646635dc873c67b76@haskell.org> #11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Thomie indicates this is fixed in HEAD, and may need a test suite entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 19:20:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 19:20:28 -0000 Subject: [GHC] #11187: Odd interaction between type families and coercions (regression) In-Reply-To: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> References: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> Message-ID: <060.137fa7d7bb494cef6062759959afe871@haskell.org> #11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > {{{#!hs > {-# LANGUAGE TypeFamilies #-} > > module Wonk where > import Data.Type.Coercion > > type family X > > coercionXX :: Coercion X X > coercionXX = Coercion > }}} > > This works just fine in 7.8.3, but in 7.10.2 it gives the following > peculiar error: > > {{{ > Couldn't match representation of type ?X? with that of ?X? > NB: ?X? is a type function, and may not be injective > In the expression: Coercion > In an equation for ?coercionXX?: coercionXX = Coercion > }}} > > I don't even know what it means for a ''nullary'' type function to be > injective. > I tried the following workarounds: > > {{{#!hs > coercionXX1 :: Coercion X X > coercionXX1 = c where > c :: x ~ X => Coercion x x > c = Coercion > > coercionXX2 :: Coercion X X > coercionXX2 = c where c = Coercion > }}} > > Interestingly, `coercionXX1` seems to work under all circumstances, > with or without the top-level type signature; `coercionXX2` works > if it's in a `.hs` file, but does ''not'' work if entered by hand > at the `ghci` prompt (it produces a similar error). New description: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Wonk where import Data.Type.Coercion type family X coercionXX :: Coercion X X coercionXX = Coercion }}} This works just fine in 7.8.3, but in 7.10.2 it gives the following peculiar error: {{{ Couldn't match representation of type ?X? with that of ?X? NB: ?X? is a type function, and may not be injective In the expression: Coercion In an equation for ?coercionXX?: coercionXX = Coercion }}} I don't even know what it means for a ''nullary'' type family to be injective. I tried the following workarounds: {{{#!hs coercionXX1 :: Coercion X X coercionXX1 = c where c :: x ~ X => Coercion x x c = Coercion coercionXX2 :: Coercion X X coercionXX2 = c where c = Coercion }}} Interestingly, `coercionXX1` seems to work under all circumstances, with or without the top-level type signature; `coercionXX2` works if it's in a `.hs` file, but does ''not'' work if entered by hand at the `ghci` prompt (it produces a similar error). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 19:56:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 19:56:36 -0000 Subject: [GHC] #11188: Confusing "parse error in pattern" for missing indentation. Message-ID: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> #11188: Confusing "parse error in pattern" for missing indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following problem exists at least in ghc 7.4.2 through 7.10.1: {{{#!hs main = do putStrLn "Hello, lots of crap" $ do a <- return 3 -- The following line is mis-indented, the error is incomprehensible c <- do return 5 }}} Error: {{{ :2:3: Parse error in pattern: putStrLn Possibly caused by a missing 'do'? }}} The hint about "missing do" exists from ghc 7.8, but is wrong in this case. Problematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here: {{{#!hs -- | Type check a function clause. checkClause :: Type -> A.SpineClause -> TCM Clause checkClause t c@(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do unless (null withPats) $ do typeError $ UnexpectedWithPatterns withPats traceCall (CheckClause t c) $ do aps <- expandPatternSynonyms aps checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $ \ (LHSResult delta ps trhs perm) -> do -- Note that we might now be in irrelevant context, -- in case checkLeftHandSide walked over an irrelevant projection pattern. -- As we will be type-checking the @rhs@ in @delta@, but the final -- body should have bindings in the order of the pattern variables, -- we need to apply the permutation to the checked rhs @v at . let mkBody v = foldr (\ x t -> Bind $ Abs x t) b xs where b = Body $ applySubst (renamingR perm) v xs = [ stringToArgName $ "h" ++ show n | n <- [0..permRange perm - 1] ] -- introduce trailing implicits for checking the where decls TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs (body, with) <- do let n = size htel addCtxTel htel $ checkWhere (size delta + n) wh $ -- for the body, we remove the implicits again escapeContext n $ handleRHS aps (unArgs trhs) rhs0 escapeContext (size delta) $ checkWithFunction with reportSDoc "tc.lhs.top" 10 $ escapeContext (size delta) $ vcat [ text "Clause before translation:" , nest 2 $ vcat [ text "delta =" <+> prettyTCM delta , text "perm =" <+> text (show perm) , text "ps =" <+> text (show ps) , text "body =" <+> text (show body) , text "body =" <+> prettyTCM body ] ] return $ Clause { clauseRange = getRange i , clauseTel = killRange delta , clausePerm = perm , namedClausePats = ps , clauseBody = body , clauseType = Just trhs } }}} {{{ src/full/Agda/TypeChecking/Rules/Def.hs:328:5: Parse error in pattern: checkLeftHandSide Possibly caused by a missing 'do'? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 19:58:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 19:58:12 -0000 Subject: [GHC] #11188: Confusing "parse error in pattern" for spurious indentation. (was: Confusing "parse error in pattern" for missing indentation.) In-Reply-To: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> References: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> Message-ID: <066.07cd652730186f2f74be714872b8b2b2@haskell.org> #11188: Confusing "parse error in pattern" for spurious indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | 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 Wed Dec 9 21:29:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 21:29:18 -0000 Subject: [GHC] #11189: bang pattern parsing inconsistency Message-ID: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> #11189: bang pattern parsing inconsistency -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{#!haskell -- Works f2 (!x, !y) = [x, y] -- Parse error on input '!' len1 lst = case lst of [] -> 0 (!x : !xs) -> 1 + len1 xs -- Parse error on input '!' len2 [] = 0 len2 (!x : !xs) = 1 + len xs }}} Tried with: HEAD, 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 23:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 23:12:38 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.fc51c736da6f79a5faad95b03f41269f@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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 ak3n): Replying to [comment:1 simonpj]: > Solution: when printing typechecked code, suppress details generated by the type checker itself. Excuse me, but how to suppress details? Is there a function for this? I found a warning generation function [https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/deSugar/DsExpr.hs#L1003 badMonadBind]. On which step do we need to suppress them ? `HsExpr` or `SDoc`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 23:14:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 23:14:13 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." Message-ID: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> #11190: Hello "schedule: re-entered unsafely." --------------------------------+---------------------------------- Reporter: Chobbes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: 951 Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- After compiling the following program on ARM: {{{#!hs main = putStrLn "Hello, world!" }}} using `ghc hello.hs` I receive the following error when running the compiled code: {{{ $ ./hello hello: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }}} I'm trying to get GHC running on my Raspberry Pi 2, running Raspbian Jessie Light, which can be found here: https://www.raspberrypi.org/downloads/raspbian/ I was following the instructions for installing the compiler on a freshly flashed RPI2 from here: http://statusfailed.com/blog/2015/11/29/haskell-and-servant-on-scaleway- arm-servers.html This was using the Linux ARMv7 binaries: https://www.haskell.org/ghc/download_ghc_7_10_3#linux_armv7 https://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7 Additionally trying to upgrade cabal with `cabal install cabal-install` seems to hang forever. It gets stuck in various Setup.hs files and doesn't seem to progress. No CPU is taken up using this. Some summary information: - llvm 3.5 - gcc 4.9.2 - original GHC from Raspbian is 7.6.3 - cabal-install from Raspbian is 1.20.0.3 - cabal is 1.20.0.2 - This same problem affects both 7.10.2, and 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 9 23:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Dec 2015 23:29:14 -0000 Subject: [GHC] #11191: provide `make uninstall` Message-ID: <042.5746e3abd3ed92aad05386db98c39033@haskell.org> #11191: provide `make uninstall` -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: installation | 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 now there is no `make uninstall` for GHC. Even though most of the times this is not strictly needed, there are cases where this would be useful (a system with not much disk space available). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 05:53:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 05:53:44 -0000 Subject: [GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! Message-ID: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: numeric | Operating System: Unknown/Multiple literal, partial type signature, | the impossible happened, panic | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I use a partial type signature in a non-top-level let-binding (or where clause), ''and'' the type is sufficiently ambiguous, ''and'' the binding in question uses a numeric literal, I get a panic from GHC instead of a report of the inferred type of the hole. So, this breaks: {{{#!hs module Fails where fails :: a fails = let go :: _ go 0 a = a in go (0 :: Int) undefined }}} {{{ Fails.hs:7:11: Couldn't match expected type ?a? with actual type ?Int? ?a? is untouchable inside the constraints () bound by the type signature for fails :: a1 at Fails.hs:3:10ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): No skolem info: a_a1iD[sk] }}} ...but this succeeds: {{{#!hs module Succeeds where succeeds :: a succeeds = let go :: _ go _ a = a in go (0 :: Int) undefined }}} {{{ Succeeds.hs:13:14: Found hole ?_? with type: t -> t1 -> t1 Where: ?t? is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 ?t1? is a rigid type variable bound by the inferred type of go :: t -> t1 -> t1 at Succeeds.hs:14:8 To use the inferred type, enable PartialTypeSignatures }}} The '''only''' difference between these two modules is the use of a numeric literal in a pattern match; that is, the troublesome line boils down to: {{{#!hs go 0 a = a }}} vs. {{{#!hs go _ a = a }}} Note that GHC gives us several pieces of feedback before talking about the panic. Before the above-quoted error, we get: {{{ Fails.hs:5:14: Found hole ?_? with type: a2 -> t1 -> t1 Where: ?t1? is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 ?a2? is a rigid type variable bound by the inferred type of go :: (Eq a2, Num a2) => a2 -> t1 -> t1 at Fails.hs:6:8 To use the inferred type, enable PartialTypeSignatures Fails.hs:6:8: No instance for (Eq a) When checking that ?go? has the specified type go :: forall t a. a -> t -> t Probable cause: the inferred type is ambiguous Fails.hs:7:7: Couldn't match expected type ?a1? with actual type ?t? because type variable ?a1? would escape its scope This (rigid, skolem) type variable is bound by the type signature for fails :: a1 at Fails.hs:3:10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 09:15:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 09:15:24 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.d2d8c5af89b7dc94158ded066cedcfd2@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+----------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Description changed by bgamari: Old description: > when compiling i get the warning > /usr/bin/d.gold: warning: cannot scan executable section 1 of ..... > transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping > symbols. > > there are some informations on the web on the cortex-a8 erratum, but i > cannot see how i could apply them. should the compiler be recompiled? i > installed from the debian distribution. > the hardware is a cubietruck. > i observe that compilation, especially the phase of preparing the > configuration in cabal takes very long - perhaps this is related to this > problem. the resulting code is ok and runs with expected speed. > > thank you for producing a full ghc for arm! > andrew New description: when compiling i get the warning {{{ /usr/bin/d.gold: warning: cannot scan executable section 1 of ..... transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping symbols. }}} there are some informations on the web on the cortex-a8 erratum, but i cannot see how i could apply them. should the compiler be recompiled? i installed from the debian distribution. the hardware is a cubietruck. i observe that compilation, especially the phase of preparing the configuration in cabal takes very long - perhaps this is related to this problem. the resulting code is ok and runs with expected speed. thank you for producing a full ghc for arm! andrew -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 09:16:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 09:16:02 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.bf59b177125e4a959973532b8b77521d@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+----------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10376 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Changes (by bgamari): * related: => #10376 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:15:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:15:25 -0000 Subject: [GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! In-Reply-To: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> References: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> Message-ID: <057.78da96d10f1215bf14936961673a8b2e@haskell.org> #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: numeric Resolution: fixed | literal, partial type signature, | the impossible happened, panic 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 => closed * resolution: => fixed Comment: Thanks for the report. Happily this too is fixed as part of my work on wildcards. Now for `Fails` you get {{{ T11192.hs:7:14: warning: ? Found type wildcard ?_? standing for ?Int -> t -> t? Where: ?t? is a rigid type variable bound by the inferred type of go :: Int -> t -> t at T11192.hs:8:8 }}} which is what you wanted. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:15:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:15:57 -0000 Subject: [GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! In-Reply-To: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> References: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> Message-ID: <057.3f09d3d63543353bce64606be7844a1c@haskell.org> #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: numeric Resolution: fixed | literal, partial type signature, | the impossible happened, panic 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:"602889aa23daecc21caaecb99ae8b055bca191f6/ghc" 602889a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="602889aa23daecc21caaecb99ae8b055bca191f6" Test Trac #11192 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:31:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:31:55 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.4cc14a13e19000d0a22bdeaa729025ad@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): I fell at the first fence. I downloaded your custom `aeson`, cd'd into its directory. Then {{{ bash$ cabal install --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin /ghc-stage2 Resolving dependencies... cabal: Could not resolve dependencies: trying: aeson-0.10.0.0 (user goal) trying: base-4.9.0.0/installed-4.9... (dependency of aeson-0.10.0.0) next goal: vector (dependency of aeson-0.10.0.0) rejecting: vector-0.11.0.0 (conflict: base==4.9.0.0/installed-4.9..., vector => base>=4.3 && <4.9) trying: vector-0.10.12.3 next goal: primitive (dependency of vector-0.10.12.3) rejecting: primitive-0.6.1.0, 0.5.4.0 (conflict: base==4.9.0.0/installed-4.9..., primitive => base>=4.3 && <4.9) rejecting: primitive-0.5.3.0, 0.5.2.1 (conflict: base==4.9.0.0/installed-4.9..., primitive => base>=4.3 && <4.8) rejecting: primitive-0.5.1.0 (conflict: base==4.9.0.0/installed-4.9..., primitive => base>=4 && <4.8) rejecting: primitive-0.5.0.1 (conflict: base==4.9.0.0/installed-4.9..., primitive => base>=4 && <4.7) rejecting: primitive-0.5, 0.4.1, 0.4.0.1, 0.4, 0.3.1, 0.3, 0.2.1, 0.2, 0.1 (conflict: vector => primitive>=0.5.0.1 && <0.7) rejecting: primitive-0.6 (conflict: base==4.9.0.0/installed-4.9..., primitive => base>=4.3 && <4.9) Dependency tree exhaustively searched. simonpj at cam-05-unx:~/tmp/aeson-ghc-8-head-workaround$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:35:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:35:10 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.9ddb0eb5e60dd1c7f61f8800b83d0543@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well, data constructors do record their `HsSrcBangs` as well as their impl-bangs. {{{ dataConSrcBangs :: DataCon -> [HsSrcBang] dataConSrcBangs = dcSrcBangs }}} So can't you just reify those? Then you get back what the user wrote, which seems reasonable for reification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:38:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:38:18 -0000 Subject: [GHC] #11189: bang pattern parsing inconsistency In-Reply-To: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> References: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> Message-ID: <058.0e89b3c310f587385daed132ebb5e396@haskell.org> #11189: bang pattern parsing inconsistency -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): That's odd... have you investigated at all? Thanks for identifying this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:40:50 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.5e379473976ec13010b5402fbdaf61aa@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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): Mostly it's a matter of not-printing the stuff added by the typechecker. E.g. not printing the `HsWrap` constructor in `HsExpr`; that is already suppressed (and sadly there is no way to display it even when debugging). But currently we do print the `AbsBinds` constructor in `HsBinds`. Probably we shouldn't unless some flag `-fprint-typechecker-elaboration` is on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:48:10 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.51525686c8aa3293b4a0f049800a43cd@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): Can you give a repro case that does not depend on Aeson? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:49:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:49:21 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.b7af8016668dcc32679b97174b287fe0@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 phadej): {{{ {-# LANGUAGE TemplateHaskell #-} $((\x -> case x of "foo" -> "bar" _ -> x)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:53:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:53:53 -0000 Subject: [GHC] #11187: Odd interaction between type families and coercions (regression) In-Reply-To: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> References: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> Message-ID: <060.eb4093b83c62b806a30094348032f716@haskell.org> #11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11187 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T11187 * status: new => closed * resolution: => fixed Comment: I'm happy that it works in HEAD, so I'll just add a regression test Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:54:50 -0000 Subject: [GHC] #11187: Odd interaction between type families and coercions (regression) In-Reply-To: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> References: <045.b2b14f8d55b86b501034061640d842a7@haskell.org> Message-ID: <060.7298e74aeac9731859b392b481b1b7e0@haskell.org> #11187: Odd interaction between type families and coercions (regression) -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T11187 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f4f00c0f28f3c21eb6f1396f48058c430c4e9b30/ghc" f4f00c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4f00c0f28f3c21eb6f1396f48058c430c4e9b30" Test Trac #11187 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 10:55:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 10:55:41 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.85cb910189e0538ece1a0a8e52b49d48@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm happy to advise. It's actually the occurrence analyser that's dropping the dead code, incidentally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 12:27:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 12:27:00 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.da7f21a7b26d49e37d272ed21c10575b@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 thomie): I can not reproduce this bug with HEAD. To reproduce with ghc-7.10.2, `cabal install repa`, and compile the above example with `-O -funfolding-use-threshold=90` (`-funfolding-use- threshold=80` makes the bug go away). Maybe it is fixed. But I can't be certain: change the example ever so slightly, and the bug is not reproducible with ghc-7.10.2 either. Adding this as a test is difficult, because it depends on `repa`, and we don't want to add that to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 12:57:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 12:57:25 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.2617770fd28facd5199ad0b6f617a283@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): Ah, you'd have to use `cabal` with `--allow-newer`, both for the first invocation in my repro until cabal fails installing aeson, and then for the invocation and for aeson as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 14:42:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 14:42:35 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.7c3cbe330fc7a345ed9de7d2978ff85b@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 15:36:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 15:36:42 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict Message-ID: <051.563028756f74e7233040685912e51248@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | 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 two programs are not equivalent with respect to the strictness of `readFile`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Main where main = do !contents <- readFile "foo.txt" print contents }}} And: {{{#!hs {-# LANGAUGE Strict #-} module Main where main = do contents <- readFile "foo.txt" print contents }}} Inspecting GHC Core for these two programs suggests that {{{#!hs !contents <- readFile "foo.txt" }}} is not equivalent to (with Strict enabled): {{{#!hs contents <- readFile "foo.txt" }}} Here's core using '''BangPatterns''': {{{ (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> case contents_asg of contents1_Xsk { __DEFAULT -> print @ String $dShow_rYy contents1_Xsk }) }}} Here's core using '''Strict''': {{{ (readFile (unpackCString# "foo.txt"#)) (\ (contents_asg :: String) -> print @ String $dShow_rYv contents_asg) }}} Does this core align with the design of the Strict extension? If it does, are users going to understand that using Strict is going to make let/where bindings strict, but is not going to make `>>=` bindings strict? However, this is likely to just be a bug. At least, Johan Tibell and Adam Sandberg Eriksson, the designers and implementers of the `Strict` extension, believe this to be a bug: > Johan Tibell @ Thu Dec 10 14:34:39 UTC 2015 writes: > > I believe this is just a bug, since the desugaring ought to be strict in the \x. https://mail.haskell.org/pipermail/ghc-devs/2015-December/010747.html > Adam Sandberg Eriksson @ Thu Dec 10 15:26:17 UTC 2015 writes: > > I agree that this seems to be a bug. I have a lot to do currently, but might be able to look at it sometime during next week. https://mail.haskell.org/pipermail/ghc-devs/2015-December/010749.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 16:05:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 16:05:13 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict In-Reply-To: <051.563028756f74e7233040685912e51248@haskell.org> References: <051.563028756f74e7233040685912e51248@haskell.org> Message-ID: <066.e1b7d14820b231296272cc5520a6ba6e@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | 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 adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 16:32:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 16:32:11 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.4eb34564a1f114f31cbb4cd9a2f3c7a6@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The problem is that the info in `HsSrcBangs` may not reflect what is actually going on in some cases. Let's suppose a user wanted to write a TH function that checks if every argument of a data constructor is unpacked. If the user wrote this: {{{#!hs data T = T !Int Int }}} then how would the user know for sure if the fields are actually unpacked? If `-funbox-strict-fields` is on, then the first argument is unpacked, but if not, it's strict but not unpacked. If `-funbox-strict-fields` ''and'' `-XStrict` is on, then ''both'' would be unpacked. But if the user relied on `HsSrcBangs`, they would be mislead into believing that the first argument always is strict (but not unpacked) and the second argument is always lazy. This situation kind of reminds me of TH's `TyVarBndr` in that `PlainTV` represents a type variable without an explicit kind variable, which should only be used during splicing. Afterwards, a kind is inferred, so reifying the datatype back gives you a `KindedTV` instead. Perhaps we should do something similar with strictness annotations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 16:51:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 16:51:56 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.ddcec3ec0ef9a444b738a517cb8c447c@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): But if > TH is supposed to reflect source code it is clear to the user of TH that the GHC could do more things to the code. I think this is true: a datatype will always be *at least* as strict and unpacked as `HsSrcBangs`/reification says. (relatedly I wonder if I can get GHC to tell me what strictness/unpackedness is ultimately choosen, as a debugging tool) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 17:25:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 17:25:07 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.dfda7253788e3a159a4af25b5f11e353@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > (relatedly I wonder if I can get GHC to tell me what strictness/unpackedness is ultimately choosen, as a debugging tool) You can, with [http://git.haskell.org/ghc.git/blob/f4f00c0f28f3c21eb6f1396f48058c430c4e9b30:/compiler/basicTypes/DataCon.hs#l886 dataConImplBangs]. [http://git.haskell.org/ghc.git/blob/f4f00c0f28f3c21eb6f1396f48058c430c4e9b30:/compiler/basicTypes/DataCon.hs#l472 HsImplBang] only has three possible configurations: `HsLazy`, `HsStrict`, and `HsUnpack`. This is more or less what TH tries to do right now, except in a half-baked way. For example, if you try to splice in a datatype with an argument that is both unpacked and lazy, it will just revert to `NotStrict`. (It doesn't take `-XStrict` or `-funbox-strict-fields` into account, however.) I strongly feel that we need to include both the `HsSrcBang` and `HsImplBang` information in Template Haskell (and probably in generics, if we fix [https://ghc.haskell.org/trac/ghc/ticket/10716 this issue]). Otherwise, we are misleading users. I don't like the idea of having to look up whether a dynamic flag is turned on or not (via `isExtEnabled` or otherwise) to know for sure what something's strictness is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 17:33:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 17:33:42 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.c6d21ed2b37040cc3f11b49bb1e517ba@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): > You can, with ?dataConImplBangs. ?HsImplBang only has three possible configurations: HsLazy, HsStrict, and HsUnpack. I'm well aware, I was thinking more of some debug flag to give GHC: perhaps `-ddump-dataconrep`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 17:39:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 17:39:13 -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.8e8d4ea9d75a09a93f071ab74aaabb3e@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: thoughtpolice => * priority: high => normal Comment: Demoting priority as we have disabled dynamic linking on Windows (see comment:29). My understanding of this situation is that it is not an intrinsic limitation of PE. The relevant data structures are the `.edata` and `.idata` tables which are defined in sections 63 and 64 of the PE/COFF specification. The specification specifies that one means of referring to exported symbols is via a 16-bit ordinal. However, this is not the only way; if the lookup fails the loader will fall back to a standard name search. Indeed, Microsoft even explicitly says that ordinals [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy artifact]] and their use is discouraged in new code (this document describes the `.def` format, but the idea still applies), > You can use @ordinal to specify that a number, and not the function name, will go into the DLL's export table. Many Windows DLLs export ordinals to support legacy code. It was common to use ordinals in 16-bit Windows code, because it can help minimize the size of a DLL. We don?t recommend exporting functions by ordinal unless your DLL?s clients need it for legacy support. Because the .LIB file will contain the mapping between the ordinal and the function, you can use the function name as you normally would in projects that use the DLL. For this reason I believe the problem is in fact that `ld.bfd` is producing DLLs with symbols exported by (or perhaps objects that are imported by) ordinal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 17:49:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 17:49:25 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.083c167e7d0a4e2d4d3103c24ccd977c@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Right, I probably should have you'd know all about `HsImplBang`. Better safe than sorry. :) If no one has any objections, I'd like to take back my earlier proposal and instead propose this be the redesign for strictness in TH: {{{#!hs data SourceStrictness = NoSourceStrictness | SourceLazy | SourceStrict data SourceUnpackedness = NoSourceUnpackedness | SourceNoUnpack | SourceUnpack data DecidedStrictness = DecidedLazy | DecidedStrict | DecidedUnpack data Bang = PendingBang SourceStrictness | DecidedBang SourceStrictness DecidedStrictness type BangType = (Bang, Type) type VarBangType = (Name, Bang, Type) type StrictType = BangType type VarStrictType = VarBangType }}} The tricky part is distinguishing between strictness at the point of splicing and strictness post-compilation. I attempt to do this with the `Bang` data type, which has two constructors for these purposes. I would also propose that attempting to splice in a datatype with a `DecidedBang` value would lead to a warning and silently revert to a `PendingBang` value (after all, what GHC decides is the right `Bang` completely depends on the environment!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:00:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:00:55 -0000 Subject: [GHC] #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! In-Reply-To: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> References: <042.7a4312a606c50750a49b129a7bcdca34@haskell.org> Message-ID: <057.3e9ac2b9e45902c57138b74bfbc892c4@haskell.org> #11192: Induced `Eq` constraint on numeric literal + partial type signature = panic! -------------------------------------+------------------------------------- Reporter: kwf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: numeric Resolution: fixed | literal, partial type signature, | the impossible happened, panic 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 kwf): Awesome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:19:54 -0000 Subject: [GHC] #11137: configure is broken for the unix package In-Reply-To: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> References: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> Message-ID: <057.6d8a35e3361f03ab6d5fe0d335be4023@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: libraries/unix | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => upstream Comment: Pull request in https://github.com/haskell/unix/pull/53. I'd prefer not to add `+SRC_CC_WARNING_OPTS += -Werror=implicit-function- declaration`. We already use -Werror on validate (but filter it out for configure), so it would make the command lines unnecessarily long. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:31:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:31:23 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.5827c3becae5a96d051b90262d2c3923@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: Type: feature request | Status: new Priority: low | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => feature request Comment: See the description of #11024 for example output. irc confo: * rwbarton > I think this is going to be kind of a messy continuum between representing all the data in the AST and producing output that's at all comprehensible to a human * mpickering > rwbarton: we have some code in ghc-exactprint which dumps the while AST and it has been very useful for us fwiw * mpickering > it's useful when you want to check what exact SrcSpan something has for example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:37:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:37:33 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.ae25701e8cb46476930fb3a879c8e346@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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 thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:40:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:40:02 -0000 Subject: [GHC] #11146: Manual eta expansion leads to orders of magnitude less allocations In-Reply-To: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> References: <046.e20145b8e1978b205b8160f6e3f4254c@haskell.org> Message-ID: <061.bed84632420a09f3c11ce0b492e37d3a@haskell.org> #11146: Manual eta expansion leads to orders of magnitude less allocations -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 18:51:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 18:51:51 -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.d4affcbd60ff736d23319055ff670cc7@haskell.org> #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy --------------------------------------+---------------------------------- Reporter: blippy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Resolution: | 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 thomie): * status: new => infoneeded Comment: Thanks for the report. Which version of `lens` did you have installed before? Are you able to reproduce this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:09:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:09:24 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X In-Reply-To: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> References: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> Message-ID: <059.a1b28c3538a0b53f8f55b6da95ff5c62@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by thomie): The difference in linker arguments you are seeing is because the ghc api seems to default to dynamic linking. This seems to be a result of the confusion in #10636. Here is a workaround: replace the call to `setSessionDynFlags` by: {{{ setSessionDynFlags (updateWays dflags) }}} Dynamic linking should work though, so that link failure is a bug by itself. Can you confirm that the following command fails as well: `ghc -dynamic test.hs`. This might require a Nix expert to fix. Why does it mention 32-bit, while you are on a 64-bit platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:13:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:13:44 -0000 Subject: [GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static` In-Reply-To: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> References: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> Message-ID: <060.465a872393a7b5383bdce55854b9f31b@haskell.org> #10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie Comment: Also (partially) causes #8294. This needs fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:14:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:14:33 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.595f37412ff87f7e46d1b40157a2d871@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+------------------------------ Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Indeed, LLVM 3.5.0-10 is very much unusable on ARM; sadly this is what Debian Jessie appears to ship with. 3.5.2 appears to work fine. We probably should have merged that configure check into `ghc-7.10` but it's water under the bridge now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:14:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:14:36 -0000 Subject: [GHC] #11053: Add a warning for pattern synonyms without signatures In-Reply-To: <049.14bd36767d1a42a7a773049896471d92@haskell.org> References: <049.14bd36767d1a42a7a773049896471d92@haskell.org> Message-ID: <064.ad70fc1d4cd745cae3e24f3341204a95@haskell.org> #11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:19:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:19:05 -0000 Subject: [GHC] #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) In-Reply-To: <046.f3343909017e4c8a715a7e1591804072@haskell.org> References: <046.f3343909017e4c8a715a7e1591804072@haskell.org> Message-ID: <061.3cc2e6e091fa2e22b3f148d9f1722933@haskell.org> #11157: (Optimized prime generation) ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: jachymb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | 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 thomie): * status: new => closed * resolution: => duplicate Comment: I'm assuming you are loading this in GHCi. The workaround is to remove the {-# OPTIONS_GHC -O2 #-} from your file. Indeed fixed in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:38:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:38:43 -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.13dce0d4579229750140a03085bebc26@haskell.org> #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy --------------------------------------+---------------------------------- Reporter: blippy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+---------------------------------- Comment (by blippy): Result of ghc-pkg list is at http://pastebin.com/h4XA7Ksy Result of stack install lens is at http://pastebin.com/Wqk7DbmK Performing cabal install lens seems to be OK though: http://pastebin.com/zxDjvP59 . lens-4.13 successfully installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:41:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:41:48 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.27ae476b02e199d06ea57764fecb423d@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: bravit (added) * related: => #5461 Comment: Still a problem with HEAD. Maybe the creator of this feature, @bravit, knows a solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 20:42:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 20:42:06 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.6d8d86c08a97e4d1fa3674c17da78d69@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => GHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 10 22:12:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Dec 2015 22:12:58 -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.26b36bc1f76b897d61def686e278e993@haskell.org> #11153: building lens-4.12.3 impossible happened: dupe _hs_primitive_memcpy --------------------------------------+---------------------------------- Reporter: blippy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries (other) | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+---------------------------------- Comment (by thomie): Hmm, I can't reproduce this. I installed haskell-platform 7.10.2, and then ran `stack install lens --resolver=lts-3.16`. Perhaps it really is a Windows-only bug. Part of the problem is that `haskell-platform` and `stack` don't play well together. See for example: https://mail.haskell.org/pipermail/haskell- community/2015-September/000014.html. So one solution would be to uninstall `haskell-platform`, and use only `stack`. Maybe upgrading to `haskell-platform 7.10.3` could also work (after uninstalling 7.10.2). 7.10.3 has the same version of `primitive` installed as `stack` wants to install, so that might circumvent the issue. But you might run into other problems later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 02:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 02:10:15 -0000 Subject: [GHC] #3559: split ghci modules off into their own package In-Reply-To: <044.482aa0aa1f1cefce182fab9f2b16a74b@haskell.org> References: <044.482aa0aa1f1cefce182fab9f2b16a74b@haskell.org> Message-ID: <059.ca14f11e0b92a61711151dededeb14ff@haskell.org> #3559: split ghci modules off into their own package -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: GHCi | Version: 6.10.4 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): * failure: => None/Unknown Comment: See also wiki:RemoteGHCi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 02:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 02:45:14 -0000 Subject: [GHC] #11194: Frontend plugins Message-ID: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> #11194: Frontend plugins -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.11 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 frontend plugin adds a new major mode to GHC, like `--make`, `--abi- hash`, etc. This will be useful for GHC API clients, because GHC's frontend `ghc/Main.hs` handles a lot of plumbing (flag parsing, setting up the session) which otherwise is painful to reimplement in GHC API (worse yet, it rapidly changes between GHC versions). For example, suppose someone wants to reimplement `--make` using the Shake library. They would define a frontend plugin which implements the `--shake` major mode. Here's how it will work: * A frontend plugin is a module which exports a single identifier `frontendPlugin` of type `GhcPlugins.FrontendPlugin`. This data structure has the following form: {{{ type FrontendPluginAction = [CommandLineOption] -> [(String, Maybe Phase)] -> GHC () data FrontendPlugin = FrontendPlugin { frontendPluginAction :: FrontendPluginAction, -- possibly more fields } defaultFrontendPlugin :: FrontendPluginAction -> FrontendPlugin }}} * There is a new major mode, `--frontend Foo.Plugin`, which loads and runs your plugin. You can pass extra flags to the plugin using `-ffrontend- opt`. We reuse the dynamic loading facilities for normal plugin loading. This should be relatively easy to backport. Possible design flex points: 1. Here, you only load the plugin that you actually want to run. You could also imagine loading a plugin adding a new major mode flag. 2. An alternative to having a full-on plugin architecture is to lib-ify most of `ghc/Main.hs`, so that other clients can use it but with different sets of options, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 04:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 04:57:49 -0000 Subject: [GHC] #11194: Frontend plugins In-Reply-To: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> References: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> Message-ID: <060.85869e9ee0e76ee7c5d9072d0e5e4b72@haskell.org> #11194: Frontend plugins -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 7.11 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:D1598 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D1598 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 06:42:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 06:42:08 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant Message-ID: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 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 my work in merging Phab:D808 (and originally pointed out by thomie), I ran into a peculiar bug: the new pattern-match check took gobs of memory (~10GB) to check !OptCoercion in the stage-2 compiler. My analysis got only as far as nailing the problem down to `pmTraverse`, which took 80% of the time, and got called roughly a gajillion times. To reproduce, simply compile !OptCoercion (with `-package ghc`) and you'll see your memory usage explode. So that you'll be able to build GHC until this is fixed, I've disable the pattern-match check in that file. There is a good chance that this is caused by an interaction between the pattern-match check and the type=kind code. I'm happy to probe further, but I'd want George's help. NB: This applies only after my patch is merged. Which should be today. For some value of today. Hopefully today's value of today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 07:23:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 07:23:54 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X In-Reply-To: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> References: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> Message-ID: <059.751b9d8c6094007e3e786c1981ebd9b5@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by svenk): The `updateWays` fix works, `ghc -dynamic test.hs` also works. Here is the interesting part of the output of `ghc -v3 -dynamic test.hs`: {{{ Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4 Using binary package database: /nix/store /cgmak4wilmf1p5ps2063w0hignmxgjzx- ghc-7.10.2/lib/ghc-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-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-7f9cf5112c3d0cf538f2bf65ccb929b3 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: 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-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-7f9cf5112c3d0cf538f2bf65ccb929b3 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: <<>> *** Assembler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_2.s -o test.o Upsweep completely successful. *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_3.c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_2.s /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_1.s Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_3.c Warning: deleting non-existent /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_1.s link: linkables are ... LinkableM (2015-12-11 07:08:36 UTC) Main [DotO test.o] Linking test ... *** C Compiler: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_4.c -o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_5.o -I/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/include -fno-common -U__PIC__ -D__PIC__ *** Linker: /nix/store/2bf6xr0v5mxlfx0lawgk6lcnw5dibk1a-clang-wrapper-3.6.2/bin/cc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -o test -Wl,-no_compact_unwind test.o -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw -L/nix/store /vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -Wl,-rpath -Wl,/nix/store/vm4zm9mh0ias79f7bqknls1xfga0lp5r-libiconv-41/lib -L/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -Wl,-rpath -Wl,/nix/store /aw51dk2wbmnvm9hxg75gmwmcl2xral6q-gmp-5.1.3/lib -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/nix/store /65vl06cjwmd2y985fl372r9nfchy9m6d-ghc-7.10.2/lib/ghc-7.10.2/rts -Wl,-rpath -Wl,/nix/store/65vl06cjwmd2y985fl372r9nfchy9m6d- ghc-7.10.2/lib/ghc-7.10.2/rts /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_5.o -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlersPtr_closure -Wl,-search_paths_first -lHSbase-4.8.1.0-GDytRqRVSUX7zckgKqJjgw-ghc7.10.2 -lHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2 -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2 -lHSrts-ghc7.10.2 -lffi -liconv -lgmp -lm -ldl link: done *** Deleting temp files: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_5.o /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0/ghc_4.c *** Deleting temp dirs: Deleting: /var/folders/qs/963nksq94bxdb3tv41w194fh0000gn/T/ghc20157_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 08:08:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 08:08:54 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.8f5106c8a735669580c6ab5c0f753677@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.11 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): Looking at the code I'd suspect the problem is either `opt_trans_rule` or `opt_co4` as these both have a substantial number of patterns each with many guards. I'll try distilling a testcase from one of these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 08:11:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 08:11:25 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.2ca579e7a5349e25de4abbb616ed82db@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: gkaracha (added) * failure: None/Unknown => Compile-time crash * owner: => goldfire * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 08:41:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 08:41:03 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.f92e933f6f86968979d3bbaf87342bf1@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's fine to make ''both'' source-code ''and'' GHC-decision information available to reification in TH. But you may want to consider making the latter come via some "info" structure returned by reification, rather than trying to put it in a TH `Decl`. Why? * If you put it in a TH `Decl` you are forced into this `Pending` vs `Decided` sum type which is ugly. * It'll conflict with #11081 (introspective TH) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 09:26:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 09:26:24 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.e4381210d689dc14929e3f944338fed0@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): * Attachment "T11195.hs" added. A not-so-minimal-testcase -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 09:30:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 09:30:41 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.1aee4b73074ba920c99a7499a4912430@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 bgamari): {{{ $ inplace/bin/ghc-stage2 Test.hs -package ghc -O +RTS -s [1 of 1] Compiling Test ( Test.hs, Test.o ) 22,902,711,336 bytes allocated in the heap 33,446,941,712 bytes copied during GC 2,960,993,984 bytes maximum residency (21 sample(s)) 15,073,104 bytes maximum slop 7835 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 530 colls, 0 par 16.236s 61.556s 0.1161s 29.5767s Gen 1 21 colls, 0 par 8.853s 69.183s 3.2944s 61.3812s 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 6.645s ( 60.820s elapsed) GC time 25.089s (130.739s elapsed) EXIT time 0.251s ( 1.432s elapsed) Total time 31.996s (192.991s elapsed) Alloc rate 3,446,736,733 bytes per MUT second Productivity 21.6% of total user, 3.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 Fri Dec 11 09:31:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 09:31:04 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.03a9f05930f5c8a6f3d3d482a27670ba@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): * Attachment "T11195.hs" added. Fix testcase -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 09:31:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 09:31:04 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.e4381210d689dc14929e3f944338fed0@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): * Attachment "T11195.hs" removed. A not-so-minimal-testcase -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 11:06:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 11:06:38 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.0b85a07234652213f6d5fcac71a13123@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 gkaracha): Replying to [comment:1 bgamari]: > Looking at the code I'd suspect the problem is either `opt_trans_rule` or `opt_co4` as these both have a substantial number of patterns each with many guards. I'll try distilling a testcase from one of these. Yes, I think so too. For example, concerning this part: {{{#!hs -- Push transitivity inside forall opt_trans_rule is co1 co2 | ForAllCo tv1 eta1 r1 <- co1 , Just (tv2,eta2,r2) <- etaForAllCo_maybe co2 = undefined | ForAllCo tv2 eta2 r2 <- co2 , Just (tv1,eta1,r1) <- etaForAllCo_maybe co1 = undefined }}} Considering only the guards `ForAllCo tv1 eta1 r1 <- co1` and `ForAllCo tv2 eta2 r2 <- co2` will generate as missing cases the following: {{{ TcRefl _ _ ~ co1 TcTyConAppCo _ _ _ ~ co1 TcAppCo _ _ ~ co1 TcCoVarCo _ ~ co1 ... TcCoercion _ ~ co1 ForAllCo tv1 eta1 r1 ~ co1, TcRefl _ _ ~ co2 ForAllCo tv1 eta1 r1 ~ co1, TcTyConAppCo _ _ _ ~ co2 ForAllCo tv1 eta1 r1 ~ co1, TcAppCo _ _ ~ co2 ForAllCo tv1 eta1 r1 ~ co1, TcCoVarCo _ ~ co2 ... ForAllCo tv1 eta1 r1 ~ co1, TcCoercion _ ~ co2 }}} This will be passed to the next clause and each one will be checked individually so the numbers will be multiplied and the sets will **really** grow exponentially. Guards are expensive by definition so I cannot think of a nice way out of this. Some options I can think of though are: 1. Restructure the code to use less guards (or use them differently) 2. See if I can make the check to eagerly solve some constraints to decrease the size of the sets it generates (I am not sure if it will be enough though, since, the above sets are all consistent for example so pruning eagerly wouldn't decrease the size of the above uncovered set) 3. Oversimplify the check to drop all the guards I hate to admit it but after all these performance failures (#11160, #11161, ... and now this), I am really tempted to drop the guards. The new checker will still be accurate when it comes to GADTs but will have almost the same performance as the old checker, by not reasoning about guards at all, like it used to do. I am not sure about the price we are willing to pay for the additional reasoning (I feel that we are paying a lot) so I would like some input on this. What do you think? In any case I will investigate it more and see if this really has anything to do with the type=kind change or if it is inherent to the check. I assume the latter but if I am mistaken I am sure we can sort it out with Richard. George -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 11:56:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 11:56:32 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.d37cc79d2de5cb6e07c2797c312a805b@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): I just learned from our application that this bug can also lead to `segmentation fault` instead of `Impossible case alternative`. Consequently I'm very eager to contribute anything necessary to find a solution ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 12:20:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 12:20:55 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.b71c8deebf18662f74c4806788d70ed4@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+----------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10376 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Description changed by bgamari: Old description: > when compiling i get the warning > {{{ > /usr/bin/d.gold: warning: cannot scan executable section 1 of ..... > transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping > symbols. > }}} > there are some informations on the web on the cortex-a8 erratum, but i > cannot see how i could apply them. should the compiler be recompiled? i > installed from the debian distribution. > the hardware is a cubietruck. > i observe that compilation, especially the phase of preparing the > configuration in cabal takes very long - perhaps this is related to this > problem. the resulting code is ok and runs with expected speed. > > thank you for producing a full ghc for arm! > andrew New description: when compiling i get the warning {{{ /usr/bin/ld.gold: warning: cannot scan executable section 1 of ..... transformers-04.3.0a... for Cortex-A8 erratum because it has no mapping symbols. }}} there are some informations on the web on the cortex-a8 erratum, but i cannot see how i could apply them. should the compiler be recompiled? i installed from the debian distribution. the hardware is a cubietruck. i observe that compilation, especially the phase of preparing the configuration in cabal takes very long - perhaps this is related to this problem. the resulting code is ok and runs with expected speed. thank you for producing a full ghc for arm! andrew -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 14:01:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 14:01:46 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.f9563216afa7da56db029a1d2ad1ebb8@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 thomie): I got this far using HEAD: {{{ Preprocessing library free-4.12.1... [ 1 of 16] Compiling Control.Monad.Free.TH ( src/Control/Monad/Free/TH.hs, dist/build/Control/Monad/Free/TH.o ) src/Control/Monad/Free/TH.hs:235:5: error: ? The constructor ?DataConI? should have 3 arguments, but has been given 4 ? In the pattern: DataConI _ _ tname _ In a case alternative: DataConI _ _ tname _ -> genFree typeSig (Just [cname]) tname In a stmt of a 'do' block: case info of { DataConI _ _ tname _ -> genFree typeSig (Just [cname]) tname _ -> fail "makeFreeCon expects a data constructor" } Failed to install free-4.12.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 14:13:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 14:13:23 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.e0c255f9b0844c57e460893c708a296c@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 thomie): Here is a workaround: use `-fno-cse`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:03:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:03:02 -0000 Subject: [GHC] #11196: TypeInType performance regressions Message-ID: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are: * T3064, bytes allocated up by 14.9% (will update description) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:12:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:12:29 -0000 Subject: [GHC] #11172: Turning on optimisations produces Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.215a6700e03ddfb376f604ec4d34fbfc@haskell.org> #11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): (Small digression:) Replying to [comment:1 rwbarton]: > Are you sure you have seen GHC ask you to report a bug when running a program compiled by GHC (other than GHC itself)? I don't think that ever happens. @rwbarton: Actually, I did find such a case, I have one right here: A yesod webserver that when compiled without `-threaded`, and Ctrl-C'd, throws the following error: {{{ src/main/Main Development ^CMain: internal error: removeFromQueues: 22294 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:22:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:22:58 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.3df99598bccb7a72d3348496ce672459@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest * version: 7.10.2 => 7.11 * milestone: => 8.0.1 Old description: > This ticket is to track the handful of performance regressions seen with > the addition of `TypeInType`. It is quite possibly a good idea to break > these out into separate tickets, but until we investigate, they're all > bundled here. > > The regressions are: > * T3064, bytes allocated up by 14.9% > > (will update description) New description: This ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are: * T3064, bytes allocated up by 14.9% * T5030, up by 61.8% * T5837, up by 13% * T5321Fun, up by 11% * T5631, up by 39% * T9872d, '''down''' by 91.8% (see below) * T9872a, up by 33.6% * T9872c, up by 59.4% * T9872b, up by 49.4% * T9675, up by 29.7%, and peak megabytes allocated up by 28.4% * haddock.base, up by 12.4% * haddock.Cabal, up by 9.5% I did add an optimization around type family reduction (the function `zonk_eq_types` in !TcCanonical) that could cause such a drastic reduction. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:29:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:29:12 -0000 Subject: [GHC] #11197: Overeager deferred type errors Message-ID: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 `TypeInType`, the solver now works in terms of unlifted equality. The only place this matters is in deferred type errors, which now are more eager than they were before. For example: {{{ {-# OPTIONS_GHC -fdefer-type-errors #-} module Main where main = do putStrLn "Hi there." putStrLn True }}} This used to print {{{ Hi there. Defer: Defer.hs:7:12: error: ... }}} Now it prints {{{ Defer: Defer.hs:7:12: error: ... }}} No more `Hi there.`. Thinking about Core, this change should be expected. GHC puts all evidence bindings for `main` at the top, and with unlifted equality in the solver, these bindings now contain `case typeError ... of ...`, which forces the type error eagerly. Previously, there was a lazy binding for a lifted equality witness, unpacked only at the last moment by magic in the desugarer, thus the lazier warning. Simon has proposed customizing the !FloatIn pass to deal with this scenario. I do believe this would work nicely, but I have not yet implemented it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:32:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:32:21 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.b765f4837643f6e76ccb40f8c683e360@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: Old description: > This ticket is to track the handful of performance regressions seen with > the addition of `TypeInType`. It is quite possibly a good idea to break > these out into separate tickets, but until we investigate, they're all > bundled here. > > The regressions are: > * T3064, bytes allocated up by 14.9% > * T5030, up by 61.8% > * T5837, up by 13% > * T5321Fun, up by 11% > * T5631, up by 39% > * T9872d, '''down''' by 91.8% (see below) > * T9872a, up by 33.6% > * T9872c, up by 59.4% > * T9872b, up by 49.4% > * T9675, up by 29.7%, and peak megabytes allocated up by 28.4% > * haddock.base, up by 12.4% > * haddock.Cabal, up by 9.5% > > I did add an optimization around type family reduction (the function > `zonk_eq_types` in !TcCanonical) that could cause such a drastic > reduction. New description: This ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are (all in bytes allocated, unless otherwise noted): * T3064, up by 14.9% * T5030, up by 61.8% * T5837, up by 13% * T5321Fun, up by 11% * T5631, up by 39% * T9872d, '''down''' by 91.8% (see below) * T9872a, up by 33.6% * T9872c, up by 59.4% * T9872b, up by 49.4% * T9675, up by 29.7%, and peak megabytes allocated up by 28.4% * haddock.base, up by 12.4% * haddock.Cabal, up by 9.5% I did add an optimization around type family reduction (the function `zonk_eq_types` in !TcCanonical) that could cause such a drastic reduction. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:39:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:39:53 -0000 Subject: [GHC] #11198: TypeInType error message regressions Message-ID: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- `TypeInType` causes error messages around certain kind errors to degrade. Here is the case: {{{ [W] (alpha :: k) ~ (Int :: *) }}} where `alpha` is a unification variable, `k` is a skolem, and there is no witness that `k ~ *`. The solver will simplify to {{{ [W] kco :: k ~ * [W] (alpha :: k) ~ (Int |> sym kco) }}} and then the latter, now homogeneous equality is solved by unification {{{ alpha := Int |> sym kco }}} This is all sound. But when reporting a kind error around `k` not equalling `*`, GHC likes to report the type error that the kind error came from. But, after zonking, the type error looks like `Int ~ Int`, when we drop coercions (as we tend to do in error messages). That's unfortunate. It affects test cases * T9196 * T8262 * T8603 * tcfail122 Simon has proposed a rule that should avoid this: never, ever use a wanted as a kind cast. That might work, but an attempt at implementing caused a loop when kind families were involved. I will keep pushing on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 15:43:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 15:43:16 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.f2b48e3c36266873c3c307e14c04d6a9@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This regression affects test cases `Defer02` and `T7861`. I'm less concerned about the latter, as it requires `ImpredicativeTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 16:13:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 16:13:16 -0000 Subject: [GHC] #11199: Outdated documentation for type operators Message-ID: <047.bc69110f06c37418a05cf5b426cd2efe@haskell.org> #11199: Outdated documentation for type operators -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: -------------------------------------+------------------------------------- John Leo writes: According to sections 7.4.3 and 7.4.4 of the latest [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data- type-extensions.html GHC documentation] you can define (7.4.3) an infix type constructor as long as it begins with a colon, for example {{{ data a :*: b = Foo a b }}} and furthermore (7.4.4) you can define an infix operator without having to use a colon if you enable the `TypeOperators` extension: {{{ data a * b = Foo a b }}} However if I try the former without using `TypeOperators` I get this compiler error in 7.10.2: {{{ Illegal declaration of a type or class operator ?:*:? Use TypeOperators to declare operators in type and declarations }}} Using `TypeOperators` fixes this, but then `*` without colon also works so I don't see the point of using colon anymore. My guess is this was some some kind of historical distinction which is no longer valid and the documentation needs to be updated. Is this true, or am I missing something? ------------------------- Answer: it's just historical and the documentation is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 16:32:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 16:32:19 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.5d2df8d65a57e610830bd72abaf7458c@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: adamgundry Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11167 | Differential Rev(s): Phab:D1600 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * differential: => Phab:D1600 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 17:14:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 17:14:01 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative (was: Turning on optimisations produces Impossible case alternative) In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.a36ef00cef97587e239c2900d51dfe87@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): I managed to reproduce the `segmentation fault` now! See branch `segfault`, https://github.com/fpco/impossible-case- alternative-repro/tree/segfault (Note that that branch is only for GHC <= 7.10, I'd have to make the same adjustments as for the other repro to make it work on GHC 8 HEAD, if that is desired.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 17:25:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 17:25:36 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.547aac42b901e3a12b0abeeb4f8b303a@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): Hmm, I'm afraid I'm having some trouble reproducing this on 7.10.2, {{{ $ ghc --make -O -Wall Main.hs -fforce-recomp && ./Main [1 of 2] Compiling Module ( Module.hs, Module.o ) Module.hs:34:1: Warning: The import of ?Control.Applicative? is redundant except perhaps to import instances from ?Control.Applicative? To import instances alone, use: import Control.Applicative() [2 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:7:1: Warning: The import of ?Control.Applicative? is redundant except perhaps to import instances from ?Control.Applicative? To import instances alone, use: import Control.Applicative() Linking Main ... Main: Impossible case alternative [1826 ben at ben-laptop impossible-case-alternative-repro(master)] $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 17:27:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 17:27:58 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.9880796649c6d7c01b54b32d66c899fb@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): Replying to [comment:8 thomie]: > I got this far using HEAD: > > {{{ > Preprocessing library free-4.12.1... > }}} @thomie: On the branch `ghc-8-head` branch it shouldn't try to install `free` (at least it's not in my `ghc-pkg list`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 17:44:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 17:44:15 -0000 Subject: [GHC] #11200: "Indentity" in Data.Traversable Haddock Message-ID: <050.146c808cd5f3919a00f8c97b98441944@haskell.org> #11200: "Indentity" in Data.Traversable Haddock -------------------------------------+------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.11 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: -------------------------------------+------------------------------------- In the Haddock for Data.Traversable, there's an unfortunate typo "indentity". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 18:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 18:00:30 -0000 Subject: [GHC] #11200: "Indentity" in Data.Traversable Haddock In-Reply-To: <050.146c808cd5f3919a00f8c97b98441944@haskell.org> References: <050.146c808cd5f3919a00f8c97b98441944@haskell.org> Message-ID: <065.bd676e8d5ff44ce7d94a5607729f64cb@haskell.org> #11200: "Indentity" in Data.Traversable Haddock -------------------------------------+------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: libraries/base | 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): * status: new => closed * version: 7.11 => 7.10.2 * resolution: => fixed * milestone: => 8.0.1 Comment: It appears that this is already fixed upstream. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 18:00:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 18:00:47 -0000 Subject: [GHC] #11200: "Indentity" in Data.Traversable Haddock In-Reply-To: <050.146c808cd5f3919a00f8c97b98441944@haskell.org> References: <050.146c808cd5f3919a00f8c97b98441944@haskell.org> Message-ID: <065.2dc692f2a32b17e41b3a697ead47438c@haskell.org> #11200: "Indentity" in Data.Traversable Haddock -------------------------------------+------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: 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): * failure: None/Unknown => Documentation bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:22:30 -0000 Subject: [GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input Message-ID: <045.aefffb38475deae13a93b03d7772087f@haskell.org> #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Create any valid files A.hs and A.c, then run `ghc --make A.hs A.c`. You'll get one `A.o` file for `A.hs`; the `A.o` from `A.c` is lost to the sands of time. I thought this situation would be pretty unlikely but geekosaur mentioned to me that he had seen someone run into this problem before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:40:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:40:35 -0000 Subject: [GHC] #11202: T10667 is broken on OS X Message-ID: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> #11202: T10667 is broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It fails with, {{{ =====> T10667(normal) 2 of 18 [0, 1, 0] cd ./codeGen/should_compile && "/Users/bgamari/ghc/inplace/test spaces /ghc-stage2" -c T10667.hs -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed- specialisations -fno-ghci-history -g > T10667.comp.stderr 2>&1 Compile failed (status 256) errors were: /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:101:2: error: error: unknown directive .hword 3 ^ /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:129:2: error: error: unknown directive .hword 1 ^ /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:131:2: error: error: unknown directive .hword 13 ^ . . . }}} [[https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF101|Apparently]] we should be using `.short` on Darwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:41:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:41:48 -0000 Subject: [GHC] #11202: T10667 and debug tests are broken on OS X (was: T10667 is broken on OS X) In-Reply-To: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> References: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> Message-ID: <061.2e953220e73bbf839d05c43c17a39fc2@haskell.org> #11202: T10667 and debug tests are broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: debug, T10667 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => debug, T10667 * failure: None/Unknown => Compile-time crash * milestone: => 8.0.1 * owner: => bgamari * os: Unknown/Multiple => MacOS X Old description: > It fails with, > {{{ > =====> T10667(normal) 2 of 18 [0, 1, 0] > cd ./codeGen/should_compile && "/Users/bgamari/ghc/inplace/test spaces > /ghc-stage2" -c T10667.hs -fforce-recomp -dcore-lint -dcmm-lint -dno- > debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn- > missed-specialisations -fno-ghci-history -g > T10667.comp.stderr 2>&1 > Compile failed (status 256) errors were: > > /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:101:2: > error: > error: unknown directive > .hword 3 > ^ > > /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:129:2: > error: > error: unknown directive > .hword 1 > ^ > > /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:131:2: > error: > error: unknown directive > .hword 13 > ^ > > . > . > . > }}} > [[https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF101|Apparently]] > we should be using `.short` on Darwin. New description: This is due to the use of `-g` by this testcase, which apparently the broken on Darwin. The test fails with, {{{ =====> T10667(normal) 2 of 18 [0, 1, 0] cd ./codeGen/should_compile && "/Users/bgamari/ghc/inplace/test spaces /ghc-stage2" -c T10667.hs -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed- specialisations -fno-ghci-history -g > T10667.comp.stderr 2>&1 Compile failed (status 256) errors were: /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:101:2: error: error: unknown directive .hword 3 ^ /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:129:2: error: error: unknown directive .hword 1 ^ /var/folders/4l/06tjh3z978l_b5plmkq08ff80000gq/T/ghc56547_0/ghc_1.s:131:2: error: error: unknown directive .hword 13 ^ . . . }}} [[https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/Assembler/040-Assembler_Directives/asm_directives.html#//apple_ref/doc/uid/TP30000823-TPXREF101|Apparently]] we should be using `.short` on Darwin. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:43:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:43:53 -0000 Subject: [GHC] #11202: T10667 and debug tests are broken on OS X In-Reply-To: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> References: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> Message-ID: <061.5ecc7774d0a13218bb5722aa24a40ff6@haskell.org> #11202: T10667 and debug tests are broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: debug, T10667 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1602 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:48:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:48:25 -0000 Subject: [GHC] #10937: "ghc -no-link --make A.hs -o foo" does something silly In-Reply-To: <045.889834166a030bc3b81adffd573d6eb7@haskell.org> References: <045.889834166a030bc3b81adffd573d6eb7@haskell.org> Message-ID: <060.d9ecd087156f7d1abf21bbba87cf61dd@haskell.org> #10937: "ghc -no-link --make A.hs -o foo" does something silly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): A related silliness: {{{ ghc -no-link --make -o foo A.hs a.c b.c }}} All of the products: the builds of A.hs, a.c and b.c are all placed in foo, clobbering each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 19:59:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 19:59:49 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong Message-ID: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Consider {{{#!hs data SameKind :: k -> k -> * data Q (a :: k1) (b :: k2) c = MkQ (SameKind a b) }}} This code should be rejected. Yet it is accepted. The problem is that, when kind-checking a datatype declaration without a CUSK, GHC uses `SigTv`s for user-written kind variables. `SigTv`s are allowed to unify with other `SigTv`s, leading to incorrect behavior here. The motivating scenario is this: {{{#!hs data T (a :: k1) x = MkT (S a ()) data S (b :: k2) y = MkS (T b ()) }}} This program should be accepted. Neither type has a CUSK and therefore is not generalized before kind-checking the group. GHC must then unify `k1` and `k2`. If they were skolems, this unification would fail and this pair of definitions would be rejected. This ticket is identical in spirit to #9201, but that example has a CUSK and thus works. The bug can happen only when there is no CUSK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 20:34:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 20:34:44 -0000 Subject: [GHC] #11202: T10667 and debug tests are broken on OS X In-Reply-To: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> References: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> Message-ID: <061.2117d257c3e090fa7e4641a2dc22d781@haskell.org> #11202: T10667 and debug tests are broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: debug, T10667 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 20:49:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 20:49:24 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.dfd2b201d81bb423c3e4f3c07814e1a7@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghc-api/T7478 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this seems to be resolved on Darwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 20:49:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 20:49:35 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.dc0a6fd3256b4989dad0560b4e652815@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghc-api/T7478 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f7c17c84f7dd8f2f1ddbfd7c5bdc3d918f25ea4d/ghc" f7c17c84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7c17c84f7dd8f2f1ddbfd7c5bdc3d918f25ea4d" T7478: Don't expect broken on Darwin This appears to be fixed as noted by goldfire on #7478 and my own experience. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:06:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:06:02 -0000 Subject: [GHC] #11204: Recompilation checking stochastically broken on Darwin Message-ID: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> #11204: Recompilation checking stochastically broken on Darwin ----------------------------------------+---------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The `retc001` test usually fails on Darwin. Unfortunately, it also sometimes passes. Failures look like this, {{{ =====> retc001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory retc001 retc001.run.stdout 2> retc001.run.stderr Actual stderr output differs from expected: --- ./retc001.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ?B? does not export ?foo? \ No newline at end of file Actual stdout output differs from expected: --- ./retc001.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -3,5 +3,3 @@ [3 of 3] Compiling Main ( C.hs, nothing ) Middle End -[2 of 3] Compiling B ( B.hs, nothing ) -[3 of 3] Compiling Main ( C.hs, nothing ) [B changed] \ No newline at end of file *** unexpected failure for retc001(normal) }}} I suspect the problem is mtime resolution as if I apply the following patch it almost always passes, {{{ diff --git a/testsuite/tests/driver/retc001/Makefile b/testsuite/tests/driver/retc001/Makefile index a3cf6eb..bb1eca8 100644 --- a/testsuite/tests/driver/retc001/Makefile +++ b/testsuite/tests/driver/retc001/Makefile @@ -20,5 +20,6 @@ retc001: clean echo 'Middle' '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite-interface --make C.hs echo 'End' + sleep 1 cp B2.hs B.hs -'$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- interface --make C.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:07:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:07:44 -0000 Subject: [GHC] #11204: Recompilation checking stochastically broken on Darwin In-Reply-To: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> References: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> Message-ID: <061.413d346a0860c6a67ed162ae0fa1018f@haskell.org> #11204: Recompilation checking stochastically broken on Darwin -----------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Description changed by bgamari: Old description: > The `retc001` test usually fails on Darwin. Unfortunately, it also > sometimes passes. > > Failures look like this, > {{{ > =====> retc001(normal) 1 of 1 [0, 0, 0] > cd . && $MAKE -s --no-print-directory retc001 > retc001.run.stdout 2> retc001.run.stderr > Actual stderr output differs from expected: > --- ./retc001.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 > +++ ./retc001.run.stderr.normalised 2015-12-11 23:02:23.000000000 > +0200 > @@ -1,2 +0,0 @@ > - > -C.hs:3:11: Module ?B? does not export ?foo? > \ No newline at end of file > Actual stdout output differs from expected: > --- ./retc001.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 > +++ ./retc001.run.stdout.normalised 2015-12-11 23:02:23.000000000 > +0200 > @@ -3,5 +3,3 @@ > [3 of 3] Compiling Main ( C.hs, nothing ) > Middle > End > -[2 of 3] Compiling B ( B.hs, nothing ) > -[3 of 3] Compiling Main ( C.hs, nothing ) [B changed] > \ No newline at end of file > *** unexpected failure for retc001(normal) > }}} > > I suspect the problem is mtime resolution as if I apply the following > patch it almost always passes, > {{{ > diff --git a/testsuite/tests/driver/retc001/Makefile > b/testsuite/tests/driver/retc001/Makefile > index a3cf6eb..bb1eca8 100644 > --- a/testsuite/tests/driver/retc001/Makefile > +++ b/testsuite/tests/driver/retc001/Makefile > @@ -20,5 +20,6 @@ retc001: clean > echo 'Middle' > '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- > interface --make C.hs > echo 'End' > + sleep 1 > cp B2.hs B.hs > -'$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- > interface --make C.hs > }}} New description: The `retc001` test usually fails on Darwin. Unfortunately, it also sometimes passes. Failures look like this, {{{ =====> retc001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory retc001 retc001.run.stdout 2> retc001.run.stderr Actual stderr output differs from expected: --- ./retc001.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ?B? does not export ?foo? \ No newline at end of file Actual stdout output differs from expected: --- ./retc001.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -3,5 +3,3 @@ [3 of 3] Compiling Main ( C.hs, nothing ) Middle End -[2 of 3] Compiling B ( B.hs, nothing ) -[3 of 3] Compiling Main ( C.hs, nothing ) [B changed] \ No newline at end of file *** unexpected failure for retc001(normal) }}} I suspect the problem is mtime resolution as the test nearly always passes with the following patch, {{{ diff --git a/testsuite/tests/driver/retc001/Makefile b/testsuite/tests/driver/retc001/Makefile index a3cf6eb..bb1eca8 100644 --- a/testsuite/tests/driver/retc001/Makefile +++ b/testsuite/tests/driver/retc001/Makefile @@ -20,5 +20,6 @@ retc001: clean echo 'Middle' '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite-interface --make C.hs echo 'End' + sleep 1 cp B2.hs B.hs -'$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- interface --make C.hs }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:11:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:11:22 -0000 Subject: [GHC] #11204: Recompilation checking stochastically broken on Darwin In-Reply-To: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> References: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> Message-ID: <061.8223e95f40509daa3457f3d585a4d997@haskell.org> #11204: Recompilation checking stochastically broken on Darwin -----------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | 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:"5447c20e5d9d4e968df91f538ca942807dc46a53/ghc" 5447c20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5447c20e5d9d4e968df91f538ca942807dc46a53" Mark retc001 as broken on Darwin Due to #11204. A relatively easy fix would be to add a one second delay as described in the ticket, but this seems terrible. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:13:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:13:28 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.e33d0ab728a7707aaad00bc6652a3bfc@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Use of `SigTv`s also sometimes gets in the way of `splitTelescopeTvs`, which depends on the kind variables in a tycon's kind having the same names as the `LHsQTyVars` in the tycon definitions. This is blocking `perf/compiler/T9872d` from compiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:26:54 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.aae3d3ac604101b46cc364735b92eadf@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #9286,#8756,#7876,#7877 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I believe I've cleaned up the remaining validation issues on Darwin for the 8.0 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:29:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:29:17 -0000 Subject: [GHC] #11205: Validation on ARM fails to due Corex-A8 erratum check Message-ID: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> #11205: Validation on ARM fails to due Corex-A8 erratum check --------------------------------+--------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------------- Numerous tests fail during validation on ARM due to linking issues. All seem to be of the flavor, {{{ =====> RolesIArray(normal) 74 of 4859 [0, 18, 1] --- /dev/null 2015-12-11 10:17:52.480000000 +0100 +++ ./warnings/should_compile/T10890/T10890.comp.stderr.normalised 2015-12-11 22:25:38.453251095 +0100 @@ -0,0 +1,174 @@ +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Either.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Typeable.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Internal.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Base.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(IO.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Signal.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Sync.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Err.o) for Cortex-A8 erratum because it has no mapping symbols. +/usr/bin/ld.gold: warning: cannot scan executable section 1 of /mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151211/base-4.9.0.0/libHSbase-4.9.0.0.a(Exception.o) for Cortex-A8 erratum because it has no mapping symbols. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 21:38:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 21:38:00 -0000 Subject: [GHC] #11205: Validation on ARM fails to due Corex-A8 erratum check In-Reply-To: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> References: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> Message-ID: <061.d7425830d45a54fa06bf3ae8a8e8046c@haskell.org> #11205: Validation on ARM fails to due Corex-A8 erratum check ---------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1599 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1599 Comment: This appears to be the same issue as #10376 and #10464. This bug will track the issue with respect to testsuite validation failure in particular. My attempt at fixing this was Phab:D1599 but sadly this doesn't appear to be sufficient. In particular it appears that bindist preparation strips binaryies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:17:18 -0000 Subject: [GHC] #10785: ghc-pkg appends colon to db path when piped/redirected In-Reply-To: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> References: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> Message-ID: <060.1d173bb768c2a41b08b9b64bb59023ab@haskell.org> #10785: ghc-pkg appends colon to db path when piped/redirected -------------------------------------+------------------------------------- Reporter: jgertm | Owner: jgertm Type: bug | Status: patch Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: | Keywords: colon pipe | redirect ghc-pkg list newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1164 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c205aebda7005744a5bbe44c11f37e98242145fa/ghc" c205aeb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c205aebda7005744a5bbe44c11f37e98242145fa" Removed colon append operation (fixes #10785) Reviewers: jgertm, austin, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1164 GHC Trac Issues: #10785 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:17:18 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.98d5470ca8a86c64a897e3b42ee28268@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | 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:D1573, Wiki Page: | phab:D1587 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b1382481ac14a9f8999321581eaf88148bd44415/ghc" b1382481/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1382481ac14a9f8999321581eaf88148bd44415" Improved data family export documentation Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1587 GHC Trac Issues: #11164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:17:18 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.498def9db5c34b2e2e825e2f3b69d0d4@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"ceaf0f4683a3e0ba85ae420956cfc394824e9a38/ghc" ceaf0f46/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ceaf0f4683a3e0ba85ae420956cfc394824e9a38" testsuite: Only run recomp015 on ELF-based platforms It fails on OS X with hundreds of messages of the form, ``` ManySections.s:196576:10: error: error: mach-o section specifier uses an unknown section type .section s65525,"", at progbits ^ ManySections.s:196579:10: error: error: mach-o section specifier uses an unknown section type .section s65526,"", at progbits ``` It fails on Windows with messages of the form, ``` ManySections.s:196579:10: error: Error: junk at the end of line, first unrecognized character is ',' ``` Test Plan: Validate Reviewers: hsyl20, thomie, austin Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D1601 GHC Trac Issues: #11022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:17:18 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.43968caba94b2e78f5e7e0f502d518db@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: adamgundry Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11167 | Differential Rev(s): Phab:D1600 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e56ac58a6905197412d58e32792a04a63b94d7e/ghc" 6e56ac58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e56ac58a6905197412d58e32792a04a63b94d7e" Fix infix record field fixity (#11167 and #11173). This extends D1585 with proper support for infix duplicate record fields. In particular, it is now possible to declare record fields as infix in a module for which `DuplicateRecordFields` is enabled, fixity is looked up correctly and a readable (although unpleasant) error message is generated if multiple fields with different fixities are in scope. As a bonus, `DEPRECATED` and `WARNING` pragmas now work for duplicate record fields. The pragma applies to all fields with the given label. In addition, a couple of minor `DuplicateRecordFields` bugs, which were pinpointed by the `T11167_ambig` test case, are fixed by this patch: - Ambiguous infix fields can now be disambiguated by putting a type signature on the first argument - Polymorphic type constructor signatures (such as `ContT () IO a` in `T11167_ambig`) now work for disambiguation Parts of this patch are from D1585 authored by @KaneTW. Test Plan: New tests added. Reviewers: KaneTW, bgamari, austin Reviewed By: bgamari Subscribers: thomie, hvr Differential Revision: https://phabricator.haskell.org/D1600 GHC Trac Issues: #11167, #11173 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:17:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:17:18 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.66c91c36ecbadc091fa35a01d3f323d5@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: patch Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): phab:D1585 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e56ac58a6905197412d58e32792a04a63b94d7e/ghc" 6e56ac58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e56ac58a6905197412d58e32792a04a63b94d7e" Fix infix record field fixity (#11167 and #11173). This extends D1585 with proper support for infix duplicate record fields. In particular, it is now possible to declare record fields as infix in a module for which `DuplicateRecordFields` is enabled, fixity is looked up correctly and a readable (although unpleasant) error message is generated if multiple fields with different fixities are in scope. As a bonus, `DEPRECATED` and `WARNING` pragmas now work for duplicate record fields. The pragma applies to all fields with the given label. In addition, a couple of minor `DuplicateRecordFields` bugs, which were pinpointed by the `T11167_ambig` test case, are fixed by this patch: - Ambiguous infix fields can now be disambiguated by putting a type signature on the first argument - Polymorphic type constructor signatures (such as `ContT () IO a` in `T11167_ambig`) now work for disambiguation Parts of this patch are from D1585 authored by @KaneTW. Test Plan: New tests added. Reviewers: KaneTW, bgamari, austin Reviewed By: bgamari Subscribers: thomie, hvr Differential Revision: https://phabricator.haskell.org/D1600 GHC Trac Issues: #11167, #11173 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:22:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:22:31 -0000 Subject: [GHC] #11206: ARM is generally a disaster Message-ID: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> #11206: ARM is generally a disaster --------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- I'll be recording the state of the testsuite on ARM here as I try to trace down the villains that plague this poor architecture. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 22:24:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 22:24:29 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.e807f6024f94b6222f4ccb907aff4d28@haskell.org> #11206: ARM is generally a disaster ---------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by bgamari): As of 688069ca83e949b9bde9883af7df26114e2f9bc0 things look like the following, {{{ TEST="T1372 T4891 landmines joao-circular cabal01 debug T2578 T10518 tc263 T7835 cabal06 cabal07 barton-mangler-bug linker_unload T4850 T5423 T7037 T5435_dyn_asm T5435_v_gcc outofmem T5435_v_asm outofmem2 T4059 T5435_dyn_gcc plugins01 mod175 T8628 T6145 T9595 T8639_api T10508_api literals parsed par003 mod179 T7476 T10890_1 T10890 Check04 T1959 recomp008 hs-boot recomp015 safePkg01 T149 T2902 T3736 T10052 recomp004 T9430 sigof01 sigof01m sigof03 sigof02dm sigof02m sigof02d sigof02 dynCompileExpr bug1465 dynamic_flags_001 cabal04 rn.prog006 T5313 T703 T9938B withRtsOpts rtsopts002 rtsopts001 driver081b T9938 driver062a driver062b driver062c driver062d driver062e driver081a T7478 recomp001 integerConstantFolding showsrcspan T3007 Capi_Ctype_001 Capi_Ctype_002 T10955dyn dynamicToo001 hsc2hs004 hsc2hs003 CmmSwitchTest T437 encoding004 T3307 environment001 parseTree T10313 annotations comments listcomps recomp012 recomp007 recomp010 recomp011 gadt23 T8726 T7014 T5243 T10359 T9203 T7257 lazy-bs-alloc haddock.Cabal haddock.compiler haddock.base T5321FD T5030 T4801 T5631 T783 T9872d T9872b T3064 T1969 T5321Fun T5837 T9233 T9961" OVERALL SUMMARY for test run started at Fri Dec 11 22:07:33 2015 CET 1:13:14 spent to go through 4859 total tests, which gave rise to 15400 test cases, of which 10592 were skipped 72 had missing libraries 4506 expected passes 104 expected failures 1 caused framework failures 0 unexpected passes 106 unexpected failures 20 unexpected stat failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.c1e7178148bcd7118d579906a9e4e412@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.4d0597b6318a9477c6549963fdc87254@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.490cd9068cadf9e516ab4a17e8c75c91@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.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 Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.87068fc265e2ad5635b83b308b62035f@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11197: Overeager deferred type errors In-Reply-To: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> References: <047.311058030fc6bc2d09ef05760e42135c@haskell.org> Message-ID: <062.c2381983de16b1577c56933a03203b6d@haskell.org> #11197: Overeager deferred type errors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.740d87d19b9056ed726038d643f16bb3@haskell.org> #8566: Given kind equalities are discarded ----------------------------------+---------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: None/Unknown | Test Case: polykinds/T8566, T8566a Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds In-Reply-To: <044.615421c3033985dd14fef72264fc6cea@haskell.org> References: <044.615421c3033985dd14fef72264fc6cea@haskell.org> Message-ID: <059.c0ec42de0042a2d0d492c39ca161905f@haskell.org> #9017: Confusing error message with PolyKinds -------------------------------------+------------------------------------- Reporter: edsko | 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): -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.a0d62cad8c48a0f63a4b6b23c7e37f24@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.396330860e7fa257b1a4005a5453dadc@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.ed778f39c9fccb18f8483d591ad71302@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: #6024 | Differential Rev(s): Phab:D808 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:22:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:22:46 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.2152085f4f73899973b4b82e9c57c086@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6746549772c5cc0ac66c0fce562f297f4d4b80a2/ghc" 67465497/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6746549772c5cc0ac66c0fce562f297f4d4b80a2" Add kind equalities to GHC. This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 11 23:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Dec 2015 23:43:24 -0000 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@haskell.org> Message-ID: <061.d5676b66d9c6f048b0ccc8328303f7d7@haskell.org> #888: Implement the static argument transformation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 00:06:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 00:06:07 -0000 Subject: [GHC] #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative In-Reply-To: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> References: <042.7b78f14d7eab93a6c441e5c7034a5986@haskell.org> Message-ID: <057.16b7b685f663fa40d152caf7ffd8b2cd@haskell.org> #11172: Turning on optimisations produces SEGFAULT or Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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 nh2): Replying to [comment:12 bgamari]: > Hmm, I'm afraid I'm having some trouble reproducing this on 7.10.2, > {{{ > Module.hs:34:1: Warning: > The import of ?Control.Applicative? is redundant > }}} @bgamari: I think you are on the `master` branch - for reproducing the segfault you need to go on the `segfault` branch of my repo, and on that one the `Control.Applicative` import is on a different line than in your warning: https://github.com/fpco/impossible-case-alternative- repro/blob/segfault/Module.hs#L44 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 02:53:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 02:53:12 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.f34dd0be44bf9f4607985ccb96557051@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: #6024 | Differential Rev(s): Phab:D808 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"68f198f50ca6439957a65a95ce6e087d43b56eed/ghc" 68f198f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68f198f50ca6439957a65a95ce6e087d43b56eed" Test case for #7961. Test case: dependent/shoud_compile/TypeLevelVec }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 02:55:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 02:55:42 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.c6cd5890d524b5ac480cadedd57f09e0@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/TypeLevelVec Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D808 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/TypeLevelVec * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:05:07 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds In-Reply-To: <044.615421c3033985dd14fef72264fc6cea@haskell.org> References: <044.615421c3033985dd14fef72264fc6cea@haskell.org> Message-ID: <059.481a1d2f05f42873c46274d91bd8e2c4@haskell.org> #9017: Confusing error message with PolyKinds -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T9017 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => polykinds/T9017 * status: new => closed * resolution: => fixed Comment: This test case still produces a suboptimal message: {{{ T9017.hs:8:7: error: ? Couldn't match kind ?k? with ?*? ?k? is a rigid type variable bound by the type signature for: foo :: forall k k1 (a :: k1 -> k -> *) (b :: k1) (m :: k1 -> k). a b (m b) at T9017.hs:7:8 When matching the kind of ?a? ? In the expression: arr return In an equation for ?foo?: foo = arr return ? Relevant bindings include foo :: a b (m b) (bound at T9017.hs:8:1) T9017.hs:8:7: error: ? Couldn't match kind ?k1? with ?*? ?k1? is a rigid type variable bound by the type signature for: foo :: forall k k1 (a :: k1 -> k -> *) (b :: k1) (m :: k1 -> k). a b (m b) at T9017.hs:7:8 When matching the kind of ?a? ? In the expression: arr return In an equation for ?foo?: foo = arr return ? Relevant bindings include foo :: a b (m b) (bound at T9017.hs:8:1) }}} We get two duplicate messages, and it's still quite hard to see what's going on. Actually, a little more thought tells me the messages aren't quite duplicates: the kind-generalized type signature contains two different kind variables, both of which are distinct from `*`. With the type signature given, I think it's OK. I'm going to accept this output, but shout if you see a way to improve. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:06:56 -0000 Subject: [GHC] #9017: Confusing error message with PolyKinds In-Reply-To: <044.615421c3033985dd14fef72264fc6cea@haskell.org> References: <044.615421c3033985dd14fef72264fc6cea@haskell.org> Message-ID: <059.5eabdcc1b2a0390d4cc53aa21eb8f182@haskell.org> #9017: Confusing error message with PolyKinds -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T9017 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"779dfea1d9cc713d9b1e26bb559e8da309b2aeec/ghc" 779dfea1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="779dfea1d9cc713d9b1e26bb559e8da309b2aeec" Test #9017 in polykinds/T9017 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:09:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:09:50 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.918be86cb810e01f5fb63489ea8eedb3@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Confirming that the example from comment:7 is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:11:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:11:06 -0000 Subject: [GHC] #8566: Given kind equalities are discarded In-Reply-To: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> References: <046.8c016f9279bc4f1e089a2406e478ec67@haskell.org> Message-ID: <061.3ea7e36981917b3eb0e5b723051ba86d@haskell.org> #8566: Given kind equalities are discarded -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T8566, T8566a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Given kind equalities are no longer discarded. And the "expect broken" test case (polykinds/T8566a) now passes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:12:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:12:49 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.8645b66b80038dd42103327857baadfa@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 goldfire): The information needed in !TcErrors to address this ticket is now very much to hand, in the `uo_thing` field of a `TypeEqOrigin`. There is some refactoring to do to improve the plumbing, but it would now be easy for someone to take an honest stab at this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 03:14:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 03:14:36 -0000 Subject: [GHC] #11142: Type-level skolem capture leads to core lint error In-Reply-To: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> References: <047.20b4d77975ac1b8abb3a0fd9c718929f@haskell.org> Message-ID: <062.e208dfd70ee78f56f4136ac10d3e5c6e@haskell.org> #11142: Type-level skolem capture leads to core lint error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => polykinds/T11142 * status: new => closed * resolution: => fixed Comment: This mistake is now detected. See `Note [Scope-check inferred kinds]` in !TcHsType. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 07:42:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 07:42:37 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.bb9ad0345b4b865f348b5232d2855064@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1603 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 08:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 08:38:06 -0000 Subject: [GHC] #11194: Frontend plugins In-Reply-To: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> References: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> Message-ID: <060.f4ed968caf1acaed56c711e7daeac113@haskell.org> #11194: Frontend plugins -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 7.11 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:D1598 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"a3c2a26b3af034f09c960b2dad38f73be7e3a655/ghc" a3c2a26/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3c2a26b3af034f09c960b2dad38f73be7e3a655" Frontend plugins. Summary: Frontend plugins enable users to write plugins to replace GHC major modes. E.g. instead of saying ghc --make A B C a user can now say ghc --frontend GHC.Frontend.Shake A B C which might provide an alternative implementation of a multi-module build. For more details, see the manual entry. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1598 GHC Trac Issues: #11194 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 08:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 08:53:04 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.e0cb0a60681aeb5393822fdd805fe69c@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 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 ppetr): I can confirm this happens for other packages as well. I was compiling arithmoi==0.4.1.3 against stackage-lts-3.17 with GHC 7.10.2 and cabal 1.22.6.0 (cabal library 1.22.4.0). I interrupted cabal during the build phase, and when compiling again, it failed with {{{ gcc: error: dist/build/Math/NumberTheory/GCD.dyn_o: No such file or directory }}} Recompiling diidn't help {{{ $ cabal build -j Warning: /home/p/.cabal/config: Unrecognized field constraints on line 5 Building arithmoi-0.4.1.3... Preprocessing library arithmoi-0.4.1.3... gcc: error: dist/build/Math/NumberTheory/GCD.dyn_o: No such file or directory }}} but ''cabal clean'' and rebuilding everything solved the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 11:10:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 11:10:42 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.bd3b6e1cd3347895d1ca2c3fbbf5a0d9@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 13:59:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 13:59:46 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind Message-ID: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The following does not work: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} import GHC.TypeLits (Nat, type (-)) type family Replicate (n :: Nat) (a :: k) = (r :: [k]) | r -> n where Replicate 0 a = '[] Replicate n a = a ': Replicate (n - 1) a }}} It fails to compile with the following error: {{{ error: ? Type family equation violates injectivity annotation. Type variable ?n? cannot be inferred from the right-hand side. In the type family equation: forall (k :: BOX) (n :: Nat) (a :: k). Replicate n a = a : Replicate (n - 1) a ? In the equations for closed type family ?Replicate? In the type family declaration for ?Replicate? Failed, modules loaded: none. }}} However, the following does: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} data Nat = Zero | Succ Nat type family Replicate (n :: Nat) (a :: k) = (r :: [k]) | r -> n where Replicate Zero a = '[] Replicate (Succ n) a = a ': Replicate n a }}} Sure GHC.TypeLits' built-in Nat type is isomorphic to the one defined above, and thus GHC should be able to infer injectivity for Replicate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 14:00:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 14:00:01 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.9960593284642b9656a5a04810755d14@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 duairc): * version: 7.10.2 => 7.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 15:32:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 15:32:41 -0000 Subject: [GHC] #11167: Fixity of field-deconstructors incorrect In-Reply-To: <042.83659aad46ca11303d89f1536bb73368@haskell.org> References: <042.83659aad46ca11303d89f1536bb73368@haskell.org> Message-ID: <057.3be9f4ac88df6d315ebad51663205268@haskell.org> #11167: Fixity of field-deconstructors incorrect -------------------------------------+------------------------------------- Reporter: hvr | Owner: kanetw Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1585 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 15:32:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 15:32:47 -0000 Subject: [GHC] #11173: Infix declarations for record fields with DuplicateRecordFields are broken In-Reply-To: <045.445187b93a05b360f24646d0112109cc@haskell.org> References: <045.445187b93a05b360f24646d0112109cc@haskell.org> Message-ID: <060.63fe02fe0352154d28ab5d39db8c2bd8@haskell.org> #11173: Infix declarations for record fields with DuplicateRecordFields are broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: adamgundry Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11167 | Differential Rev(s): Phab:D1600 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 15:33:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 15:33:06 -0000 Subject: [GHC] #10785: ghc-pkg appends colon to db path when piped/redirected In-Reply-To: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> References: <045.3d47d5b2ab2694bd10b297d594ba35c3@haskell.org> Message-ID: <060.88cebcae252f18b6863a14a50e444c65@haskell.org> #10785: ghc-pkg appends colon to db path when piped/redirected -------------------------------------+------------------------------------- Reporter: jgertm | Owner: jgertm Type: bug | Status: closed Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.2 Resolution: fixed | Keywords: colon pipe | redirect ghc-pkg list newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1164 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 15:52:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 15:52:08 -0000 Subject: [GHC] #11194: Frontend plugins In-Reply-To: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> References: <045.5f854bc9615ab47dc9c37fa021011616@haskell.org> Message-ID: <060.93f978879d788cfa189da70e16639397@haskell.org> #11194: Frontend plugins -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.11 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:D1598 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 16:39:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 16:39:27 -0000 Subject: [GHC] #11053: Add a warning for pattern synonyms without signatures In-Reply-To: <049.14bd36767d1a42a7a773049896471d92@haskell.org> References: <049.14bd36767d1a42a7a773049896471d92@haskell.org> Message-ID: <064.14d780d0c9dda4c2d069777ac9f067b5@haskell.org> #11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"1883afb2eee88c828adf6aa8014bab64dd6e8096/ghc" 1883afb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1883afb2eee88c828adf6aa8014bab64dd6e8096" Implement -fwarn-missing-pat-syn-sigs This adds a warning when a pattern synonym is not accompanied by a signature in the style of `-fwarn-missing-sigs`. It is turned on by -Wall. If the user specifies, `-fwarn-missing-exported-signatures` with `-fwarn-missing-pat-syn-sigs` then it will only warn when the pattern synonym is exported. Test Plan: ./validate Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1596 GHC Trac Issues: #11053 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 16:53:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 16:53:21 -0000 Subject: [GHC] #11053: Add a warning for pattern synonyms without signatures In-Reply-To: <049.14bd36767d1a42a7a773049896471d92@haskell.org> References: <049.14bd36767d1a42a7a773049896471d92@haskell.org> Message-ID: <064.b75d74429431070647fa9b7b9af07b60@haskell.org> #11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyns/T11053 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * testcase: => patsyns/T11053 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 17:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 17:38:48 -0000 Subject: [GHC] #11202: T10667 and debug tests are broken on OS X In-Reply-To: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> References: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> Message-ID: <061.9c9083121df69bccccb92ac3654e408e@haskell.org> #11202: T10667 and debug tests are broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: debug, T10667 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1602 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3640ae92fc1ffa283425203bba3dbf231fcb3e52/ghc" 3640ae92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3640ae92fc1ffa283425203bba3dbf231fcb3e52" Dwarf: Use .short instead of .hword on Darwin Apparently gnu as uses `.short` as a synonym for `.word`. To emit a 16-bit value one would use `.hword`. However, Darwin doesn't support `.hword`, instead taking `.short` to mean a 16-bit value. The insanity is nearly unbearable! OS X reference: https://developer.apple.com/library/mac/documentation/DeveloperTools/Ref erence/Assembler/040-Assembler_Directives/asm_directives.html#//apple_re f/doc/uid/TP30000823-TPXREF101 gnu as reference: https://sourceware.org/binutils/docs/as/hword.html#hword Test Plan: Validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1602 GHC Trac Issues: #11202 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 17:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 17:38:48 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.e52fe83726f2740cb4d1fff1e5c56ad7@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: patch Priority: highest | Milestone: 8.0.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: Related Tickets: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3ec8288a18d57fb856e257905897daae237a1d5d/ghc" 3ec8288/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3ec8288a18d57fb856e257905897daae237a1d5d" Rework the Implicit CallStack solver to handle local lets. We can't just solve CallStack constraints indiscriminately when they occur in the RHS of a let-binder. The top-level given CallStack (if any) will not be in scope, so I've re-worked the CallStack solver as follows: 1. CallStacks are treated like regular IPs unless one of the following two rules apply. 2. In a function call, we push the call-site onto a NEW wanted CallStack, which GHC will solve as a regular IP (either directly from a given, or by quantifying over it in a local let). 3. If, after the constraint solver is done, any wanted CallStacks remain, we default them to the empty CallStack. This rule exists mainly to clean up after rule 2 in a top-level binder with no given CallStack. In rule (2) we have to be careful to emit the new wanted with an IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire again. This is a bit shady but I've updated the Note to explain the trick. Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1422 GHC Trac Issues: #10845 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 17:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 17:38:48 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.6fb0d13ae5cab5ad890d7a300e38e72a@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.1-rc1 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): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aaed24a4e0d8fa0d49aca167fddfb8b606755e05/ghc" aaed24a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aaed24a4e0d8fa0d49aca167fddfb8b606755e05" Build system: fix 'make install-strip' in bindist The INSTALL_PROGRAM variable is set in mk/config.mk, so we have to include that file before using it. Running 'make install' before './configure' in a bindist will now also display a nice message. Reviewers: hvr, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1604 GHC Trac Issues: #1851 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 17:38:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 17:38:48 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData In-Reply-To: <050.7371157dda089c577427400940c719c0@haskell.org> References: <050.7371157dda089c577427400940c719c0@haskell.org> Message-ID: <065.959681a91b0d2b882f522d6234201d00@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: adamse Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8347 | Differential Rev(s): Phab:D1592 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4935b48bdbed916507d585f9185960916ed5f04b/ghc" 4935b48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4935b48bdbed916507d585f9185960916ed5f04b" Make -XStrict imply -XStrictData Fixes #11182. Reviewers: bgamari, simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1592 GHC Trac Issues: #11182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 17:46:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 17:46:08 -0000 Subject: [GHC] #11182: -XStrict doesn't imply -XStrictData In-Reply-To: <050.7371157dda089c577427400940c719c0@haskell.org> References: <050.7371157dda089c577427400940c719c0@haskell.org> Message-ID: <065.e32cf3ebf127b36e31636e6ae4086549@haskell.org> #11182: -XStrict doesn't imply -XStrictData -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: adamse Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T11182 Blocked By: | Blocking: Related Tickets: #8347 | Differential Rev(s): Phab:D1592 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * status: new => closed * testcase: => T11182 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 18:57:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 18:57:19 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.01af6b6b56ffab3cb25e13a1a1b7f12d@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 19:01:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 19:01:26 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell In-Reply-To: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> References: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> Message-ID: <062.67aa5bcb83aee46eddb8a81271094b40@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 Ben Gamari ): In [changeset:"9934819f3bb086bba91874cde4f0b17b30b10451/ghc" 9934819/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9934819f3bb086bba91874cde4f0b17b30b10451" Refactor type families in Template Haskell Fixes #10902. Test Plan: validate Reviewers: goldfire, austin, hvr, jstolarek, bgamari Reviewed By: jstolarek, bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1570 GHC Trac Issues: #10902 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 19:01:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 19:01:48 -0000 Subject: [GHC] #10902: Refactor type families in Template Haskell In-Reply-To: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> References: <047.b25240b031d2012bf9d6cd9d3443b8ca@haskell.org> Message-ID: <062.b6b0aadc4905cad71bb4448c9d0d4d07@haskell.org> #10902: Refactor type families in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: johnleo Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 19:15:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 19:15:25 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore Message-ID: <042.585a8985b5aba877c56b474078648ae0@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `M.hs` contains: {{{#!hs module M where import qualified Prelude as P f n = n P.+ 1 g h (P.Just x) = P.Just (h x) g _ P.Nothing = P.Nothing }}} GHC 7.10.3 behaves as expected: {{{ $ ghci-7.10.3 -ignore-dot-ghci M.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling M ( M.hs, interpreted ) Ok, modules loaded: M. *M> :browse f :: P.Num a => a -> a g :: (t -> a) -> P.Maybe t -> P.Maybe a *M> :t f f :: P.Num a => a -> a *M> :t g g :: (t -> a) -> P.Maybe t -> P.Maybe a }}} However, GHC HEAD drops the module qualifiers {{{ $ ghci-7.11.20151209 -ignore-dot-ghci M.hs GHCi, version 7.11.20151209: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling M ( M.hs, interpreted ) Ok, modules loaded: M. *M> :browse f :: Num a => a -> a g :: (t -> a) -> Maybe t -> Maybe a *M> :t f f :: Num a => a -> a *M> :t g g :: (t -> a) -> Maybe t -> Maybe a *M> Nothing :: Maybe () :4:12: error: Not in scope: type constructor or class ?Maybe? Perhaps you meant ?P.Maybe? (imported from Prelude) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 19:19:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 19:19:35 -0000 Subject: [GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static` In-Reply-To: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> References: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> Message-ID: <060.7ea52aed4caa97fd9eca8b3022c8fa8f@haskell.org> #10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: Simon, perhaps you could shed some light why these two exist? I would imagine it is a historical accident but it would be good to know this for certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 20:32:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 20:32:47 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) In-Reply-To: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> References: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> Message-ID: <057.80ed6837ad5b1304d5ae3fafd5179ea8@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dolio Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1605 Wiki Page: | prime:Libraries/Proposals/ExpandFloating| -------------------------------------+------------------------------------- Changes (by dolio): * differential: => Phab:D1605 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 21:10:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 21:10:24 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.115f735d827141ad166caad96ade23da@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Sorry for being late to the conversation here. I find the comment:12 proposal to be a bit baroque. Let's examine the principles at play: 1. TH quotes should faithfully turn user-written syntax into the TH AST. But it's not obliged to deal with meaningless user-written syntax. Are all nine possibilities enumerated in the original post meaningful? I don't think so. (Does `{-# UNPACK #-} ~blah` ever make sense?) If it makes the design of TH harder, I don't think we need to deal with the non-meaningful combinations. But, all else being equal, being able to represent what the user wrote is helpful. 2. Splicing should respect what extensions are on in the splicing module, ''not'' the quoting module. When splicing a quote, GHC should behave exactly as if the code were copied and pasted from the quote to the splice. 3. Reification, as implemented, is a lie. GHC does not save the actual syntax the user wrote and so does a best-effort approximation. It's always going to be a bit wrong, at least until we're giving users a `TyCon` directly (which I'm not suggesting here). In addition to these bedrock principles (which, I'll admit, I've just made up on the spot; if we like them, we should enshrine these or something similar somewhere), I'd like to add 4. Reification should behave identically no matter what extensions are enabled. Anything else seems doomed to endlessly befuddle users. Given these design principles, I favor the original proposal the most. It's straightforward enough to programmatically generate, to programmatically examine, and for humans to understand. I think I favor an implementation of reification that never returns `NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you precisely what GHC is doing, all the time. This has the noted downside that laziness annotations will cause compilation problems without `StrictData`. So we also add new (quite straightforward, pure) functions that make a reified data declaration suitable for `-XNoStrictData` or `-XStrictData`. Perhaps with Phab:D1200 complete (extension checking), we can offer a function that just does the right thing. This reification problem is quite similar (as you point out) to kind annotations on type variable binders. A few versions ago, reification used `PlainTV` for all `*`-kinded variables and `KindedTV` for others. But this was just bogus, and now there are a lot more kind signatures. Of course, this means that reified code might not always compile if spliced -- just like what I'm proposing about strictness, etc. What do we think? I have not looked at the implementation, as we haven't settled on a design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 21:33:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 21:33:45 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.efa55f3145d819d5f45d07fd5a11fa6b@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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 rwbarton): This change is intentional, though perhaps not in this particular setting. I forget the ticket number though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 21:41:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 21:41:51 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.6228b2729e36102b4fd6430187a07ce7@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I will admit that I got a little too ambitious with my proposal in comment:12, which Simon noted. TH splices should never be altered if given "bad" input like what I had proposed. I like Simon's idea of granting the user the ability to reify a constructor's fields' strictness after compilation, which I incorporated in Phab:D1603. I'll go ahead and post the updated design here so we have a common point to reference in this discussion. Here is the API that concerns reification of data types, which coincides precisely with the strictness annotations a user writes in source code (i.e., `HsSrcBang`): {{{#!hs data SourceUnpackedness = NoSourceUnpackedness | SourceNoUnpack | SourceUnpack data SourceStrictness = NoSourceStrictness | SourceLazy | SourceStrict data Con = NormalC Name [BangType] | RecC Name [VarBangType] | InfixC BangType Name BangType | ForallC [TyVarBndr] Cxt Con data Bang = Bang SourceUnpackedness SourceStrictness type BangType = (Bang, Type) type VarBangType = (Name, Bang, Type) }}} There is also a similar API for discovering what GHC actually turns these strictness/unpackedness combinations into after compilation (i.e., `HsImplBang`), which can be affected by `-XStrictData`, `-funbox-strict- fields`, etc. {{{#!hs data DecidedStrictness = DecidedLazy | DecidedStrict | DecidedUnpack class Monad m => Quasi m where ... qReifyConStrictness :: Con -> m [DecidedStrictness] }}} > 1. TH quotes should faithfully turn user-written syntax into the TH AST. Agreed. > But it's not obliged to deal with meaningless user-written syntax. Are all nine possibilities enumerated in the original post meaningful? I don't think so. (Does `{-# UNPACK #-} ~blah` ever make sense?) If it makes the design of TH harder, I don't think we need to deal with the non-meaningful combinations. But, all else being equal, being able to represent what the user wrote is helpful. I somewhat disagree here. TH splices should produce syntactically valid code, but there's no guarantee that code that it will be meaningful. After all, you could conceivably splice in something like `foo :: Maybe -> Maybe`. You're right in that internally, GHC doesn't think all nine combinations are compatible. In fact, `HsImplBang` only has three combinations: strict, lazy, and unpacked. But the source language is much richer, and it would be difficult to graft `{-# NOUNPACK #-}` and laziness annotations onto Template Haskell without acknowledging that unpackedness annotations and strictness annotations can be used independently of each other in source code. Not only that, you can't always tell what GHC will produce just from examining the unpackedness and strictness annotations alone; it's also affected by language extensions, optimization levels, and other inscrutable factors. That's why GHC keeps track of `HsSrcBang` information even after it's determined what the `HsImplBang`s are. If it didn't, there'd be no way things like GHCi could tell you how the original data type was written in source code, since that information could have been distorted. For these reasons, I feel strongly that we need to be able to express all combinations of annotations, even if some of them aren't meaningful to GHC. > 2. Splicing should respect what extensions are on in the splicing module, ''not'' the quoting module. When splicing a quote, GHC should behave exactly as if the code were copied and pasted from the quote to the splice. Also agreed. I moved the `DecidedStrictness` stuff out of the AST so that this property would be preserved. > 3. Reification, as implemented, is a lie. GHC does not save the actual syntax the user wrote and so does a best-effort approximation. It's always going to be a bit wrong, at least until we're giving users a `TyCon` directly (which I'm not suggesting here). True, but I think that as long as property 2 holds, this isn't a big deal. Not only that, but TH's `SourceStrictness`, `SourceUnpackedness`, and `DecidedStrictness` are in one-to-one correspondence with GHC's `SrcStrictness`, `SrcUnpackedness`, and `HsImplBang`, respectively, so we don't have to lie in this particular case. > 4. Reification should behave identically no matter what extensions are enabled. Anything else seems doomed to endlessly befuddle users. I feel like you need to be more specific here before I can respond to this. Are you referring to reification of what the user ''wrote'', or reification of GHC-specific info that depends on compilation settings? If it's the former, I agree, but not if it's the latter. > I think I favor an implementation of reification that never returns `NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you precisely what GHC is doing, all the time. This has the noted downside that laziness annotations will cause compilation problems without `StrictData`. So we also add new (quite straightforward, pure) functions that make a reified data declaration suitable for `-XNoStrictData` or `-XStrictData`. Perhaps with Phab:D1200 complete (extension checking), we can offer a function that just does the right thing. Again, are you referring to the source strictness or the GHC-decided strictness here? If it's the decided strictness, then as you say, it doesn't make sense to return "no strictness". If it's the source strictness, adding a "no strictness" option is, IMO, unavoidable (see my response to point 1). > This reification problem is quite similar (as you point out) to kind annotations on type variable binders. A few versions ago, reification used `PlainTV` for all `*`-kinded variables and `KindedTV` for others. But this was just bogus, and now there are a lot more kind signatures. Of course, this means that reified code might not always compile if spliced -- just like what I'm proposing about strictness, etc. Upon further thought, I don't think this comparison is a very good one. `TyVarBndr` is special because it's possible to write type variables without kind signatures and have GHC infer them; that is, there's a special input form for splicing that never appears in the reified output. Strictness, on the other hand, has special ''output'' forms that should never appear in the spliced input. Going the other way is problematic, and for that reason, I adopted Simon's suggestion of splitting off the `DecidedStrictness` stuff and moving it to a `reifyConStrictness` function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 21:54:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 21:54:00 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X In-Reply-To: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> References: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> Message-ID: <059.1fb24557acc8a5f26232ba25f8eade66@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | 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): Phab:D1607 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1607 Comment: Phab:D1607 should fix it then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 22:55:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 22:55:20 -0000 Subject: [GHC] #6024: Allow defining kinds alone, without a datatype In-Reply-To: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> References: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> Message-ID: <061.ca39583ba27951ffcd8d81f8e0881acd@haskell.org> #6024: Allow defining kinds alone, without a datatype -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: goldfire (added) Comment: Is this feature request still possible to implement, now that "[wiki:DependentHaskell/Phase1#Kindsandtypesarethesame kinds and types are the same]" (6746549772c5cc0ac66c0fce562f297f4d4b80a2). See also comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 23:19:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 23:19:29 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.8545df04fe82fd0760063173f6cdf476@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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 hvr): I notice this also applies to warning messages, i.e. {{{ M.hs:5:1: Warning: Top-level binding with no type signature: f :: forall a. P.Num a => a -> a M.hs:7:1: Warning: Top-level binding with no type signature: g :: forall t a. (t -> a) -> P.Maybe t -> P.Maybe a }}} vs {{{ M.hs:5:1: warning: Top-level binding with no type signature: f :: forall a. Num a => a -> a M.hs:7:1: warning: Top-level binding with no type signature: g :: forall a r. (r -> a) -> Maybe r -> Maybe a }}} In any case, this causes breakage for tooling (and users) relying on the warnings and ghci-output to be qualified in the module-scope they've been triggered from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 23:25:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 23:25:19 -0000 Subject: [GHC] #9037: Add option to make selected warnings errors In-Reply-To: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> References: <042.6aee3bd7af8a4db00b8b565ec5ad1d4b@haskell.org> Message-ID: <057.cdf1ca57e4168d2083e193502c2f3cf2@haskell.org> #9037: Add option to make selected warnings errors -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 hvr): Fwiw, this is related to Design/Warnings which proposes to use `-Werror =redundant-imports` to selectively promote some warnings to errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 23:25:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 23:25:37 -0000 Subject: [GHC] #6024: Allow defining kinds alone, without a datatype In-Reply-To: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> References: <046.e44bc03833a60dff474759358b4e4e3f@haskell.org> Message-ID: <061.7171b172077ab0ba513e62ef30809a14@haskell.org> #6024: Allow defining kinds alone, without a datatype -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, though it's a shade less useful. Types and kinds are indeed the same now, but terms are not. I see this ticket as a request for an ability to define a datatype whose constructors are defined only in types, never in terms. From a user standpoint, this ticket is largely unaffected by type=kind. It's a shade less useful because you can now say {{{#!hs data Foo = MkFoo1 Type -- Type is a.k.a. * | MkFoo2 Int }}} so some of the motivation for kind-only has gone away. A kind-only definition would still prevent clients from constructing the object at runtime, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 12 23:34:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Dec 2015 23:34:19 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.f059f54b231fe722000570d71df65760@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 goldfire): * cc: jstolarek (added) Comment: But your definitions are subtly different. In the !TypeLits case, you're using `-` in the RHS. `-` is not injective. So GHC quite correctly rejects the equation. In the corresponding equation without !TypeLits, there are no function calls on the right; instead, you use pattern-matching on the left to get what you want. If you implement a `-` over your unary `Nat` and write the definitions the same way, GHC will reject the non-!TypeLits definition, too. What this requires is "generalized injectivity", where we could say {{{ type family (a :: Nat) - (b :: Nat) = (r :: Nat) | r a -> b, r b -> a }}} We've considered such a thing, but we have yet to work out all the details, if I recall correctly. In any case, if this existed, then GHC would be able to accept the first definition. Adding in Janek, who is Mr. Injective-Type-Families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 00:54:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 00:54:33 -0000 Subject: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles In-Reply-To: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> References: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> Message-ID: <060.c96850ce97c1fa03f5eb241e705f054d@haskell.org> #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.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 thomie): * status: infoneeded => new * cc: ekmett (added) Old description: > The `hSetNewlineMode` and `hSetEncoding` functions from > `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is > possible to use them on closed handles. hSetEncoding on a closed Handle > triggers a segfault. Similarly, the operations are also both possible on > semi-closed handles, and given the way hGetContents is implemented, this > will affect the result of hGetContents which is clearly against the > intention of the hGetContents/semi-closed stuff. > > Both functions use the `withAllHandles__` helper. Unlike similar helpers > like `wantReadableHandle_` this one doesn't do any handle mode checking. > > Additionally, `hSetBuffering` and `hSetBinary` mode also use the > `withAllHandles__` pattern and don't obviously check for an open handle > but I've not verified this. New description: The `hSetNewlineMode` and `hSetEncoding` functions from `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is possible to use them on closed handles. hSetEncoding on a closed Handle triggers a segfault. Similarly, the operations are also both possible on semi-closed handles, and given the way hGetContents is implemented, this will affect the result of hGetContents which is clearly against the intention of the hGetContents/semi-closed stuff. Both functions use the `withAllHandles__` helper. Unlike similar helpers like `wantReadableHandle_` this one doesn't do any handle mode checking. Additionally, `hSetBuffering` and `hSetBinaryMode` mode also use the `withAllHandles__` pattern and don't obviously check for an open handle but I've not verified this. -- Comment: With or without segfaults, this could be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 03:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 03:22:33 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.f495f1de699309a76f97ed9d58bc0bfe@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By the way, I'm open to ideas on what to color the bikeshed: * I'm not sure if `SourceStrictness` and `SourceUnpackedness` should have three constructors each, or if we should just remove `NoSourceStrictness`/`NoSourceUnpackedness` and just use `Nothing` to represent a lack of an annotation (e.g., `Just SourceStrict` for a `!` annotation, `Nothing` for no annotation). * What to name `SourceStrictness` and `SourceUnpackedness`. Other names I contemplated were `data AnnStrictness = StrictAnnotation | LazyAnnotation | NoStrictnessAnnotation` and `data AnnUnpackedness = NoUnpackAnnotation | UnpackAnnotation | NoUnpackednessAnnotation`. * What to name `DecidedStrictness`. I also considered `data ImplStrictness = ImplStrict | ImplLazy | ImplUnpack`. Or perhaps we should just re-use the already existing `data Strict = IsLazy | IsStrict | Unpack`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 04:29:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 04:29:57 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.5c494d48a3177392af893e4cb8696ade@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 RyanGlScott]: > I will admit that I got a little too ambitious with my proposal in comment:12, which Simon noted. TH splices should never be altered if given "bad" input like what I had proposed. I like Simon's idea of granting the user the ability to reify a constructor's fields' strictness after compilation, which I incorporated in Phab:D1603. Yes, that may be a good middle ground. > > I'll go ahead and post the updated design here so we have a common point to reference in this discussion. Here is the API that concerns reification of data types, which coincides precisely with the strictness annotations a user writes in source code (i.e., `HsSrcBang`): > > {{{#!hs > data SourceUnpackedness = NoSourceUnpackedness > | SourceNoUnpack > | SourceUnpack > > data SourceStrictness = NoSourceStrictness > | SourceLazy > | SourceStrict > > data Con = NormalC Name [BangType] > | RecC Name [VarBangType] > | InfixC BangType Name BangType > | ForallC [TyVarBndr] Cxt Con > > data Bang = Bang SourceUnpackedness SourceStrictness > > type BangType = (Bang, Type) > type VarBangType = (Name, Bang, Type) > }}} > > There is also a similar API for discovering what GHC actually turns these strictness/unpackedness combinations into after compilation (i.e., `HsImplBang`), which can be affected by `-XStrictData`, `-funbox-strict- fields`, etc. > > {{{#!hs > data DecidedStrictness = DecidedLazy > | DecidedStrict > | DecidedUnpack > > class Monad m => Quasi m where > ... > qReifyConStrictness :: Con -> m [DecidedStrictness] > }}} This might be more useful taking a `Name` instead of a `Con`. I imagine it has to just extract the name and look it up anyway, no? Or does it apply the extensions currently enabled to the `Con` definition and report back what GHC would decide if the declaration were given? That seems a bit silly. > > > 1. TH quotes should faithfully turn user-written syntax into the TH AST. > > Agreed. > > > But it's not obliged to deal with meaningless user-written syntax. ... > > I somewhat disagree here. TH splices should produce syntactically valid code, but there's no guarantee that code that it will be meaningful. After all, you could conceivably splice in something like `foo :: Maybe -> Maybe`. You're talking about splices; I'm talking about quotes. Yes, splices need to deal with whatever the TH AST provides it, producing compilation errors as appropriate. But I don't think quoting does. For example `[| x $$$ y %%% z |]` fails if `$$$` and `%%%` are both non-fix operators of the same precedence. And the TH AST even has the ability to represent that one! (Via `UInfixE`.) So I maintain that quoting doesn't need to deal with nonsensical code, if that makes things easier. > > You're right in that internally, GHC doesn't think all nine combinations are compatible. In fact, `HsImplBang` only has three combinations: strict, lazy, and unpacked. But the source language is much richer, and it would be difficult to graft `{-# NOUNPACK #-}` and laziness annotations onto Template Haskell without acknowledging that unpackedness annotations and strictness annotations can be used independently of each other in source code. I agree. Especially with the various flags that can affect this behavior. > > Not only that, you can't always tell what GHC will produce just from examining the unpackedness and strictness annotations alone; it's also affected by language extensions, optimization levels, and other inscrutable factors. That's why GHC keeps track of `HsSrcBang` information even after it's determined what the `HsImplBang`s are. If it didn't, there'd be no way things like GHCi could tell you how the original data type was written in source code, since that information could have been distorted. > > For these reasons, I feel strongly that we need to be able to express all combinations of annotations, even if some of them aren't meaningful to GHC. I'm not at all disagreeing here. Just saying that it's not the only option. But perhaps this isn't worth debating, as I do tend to agree that representing the source Haskell straightforwardly works out nicely in this case. > > > 4. Reification should behave identically no matter what extensions are enabled. Anything else seems doomed to endlessly befuddle users. > > I feel like you need to be more specific here before I can respond to this. Are you referring to reification of what the user ''wrote'', or reification of GHC-specific info that depends on compilation settings? If it's the former, I agree, but not if it's the latter. I'm saying that if I reify `Foo`, I should get the same results no matter what extensions are enabled at the point of reification. Of course, if you change the extensions at `Foo`'s definition site, then that substantively changes the definition of `Foo` and should change the output of reification. I can't distinguish between your two cases, I'm afraid. Reification never promises to get back what the user wrote -- it gives you what GHC knows. > > > I think I favor an implementation of reification that never returns `NoStrictAnnot` and never returns `NoUnpackAnnot`; that is, it tells you precisely what GHC is doing, all the time. This has the noted downside that laziness annotations will cause compilation problems without `StrictData`. So we also add new (quite straightforward, pure) functions that make a reified data declaration suitable for `-XNoStrictData` or `-XStrictData`. Perhaps with Phab:D1200 complete (extension checking), we can offer a function that just does the right thing. > > Again, are you referring to the source strictness or the GHC-decided strictness here? If it's the decided strictness, then as you say, it doesn't make sense to return "no strictness". If it's the source strictness, adding a "no strictness" option is, IMO, unavoidable (see my response to point 1). Reification talks about compiled things, not source things. The fact that it returns information using surface syntax is the "lie". So this is GHC- decided strictness. > > > This reification problem is quite similar (as you point out) to kind annotations on type variable binders. A few versions ago, reification used `PlainTV` for all `*`-kinded variables and `KindedTV` for others. But this was just bogus, and now there are a lot more kind signatures. Of course, this means that reified code might not always compile if spliced -- just like what I'm proposing about strictness, etc. > > Upon further thought, I don't think this comparison is a very good one. `TyVarBndr` is special because it's possible to write type variables without kind signatures and have GHC infer them; that is, there's a special input form for splicing that never appears in the reified output. Strictness, on the other hand, has special ''output'' forms that should never appear in the spliced input. Going the other way is problematic, and for that reason, I adopted Simon's suggestion of splitting off the `DecidedStrictness` stuff and moving it to a `reifyConStrictness` function. I don't agree here. Strictness does not need to have special output forms. It just needs to use unambiguous forms like (unpacked/strict), (not- unpacked/strict) and (not-unpacked/lazy), and never return that it doesn't know. On the other hand, there are 6 extra input forms. Exactly like `TyVarBndr`. You've chosen to implement this asymmetry by introducing new output forms. The same could have been done for `TyVarBndr`, by never giving kind annotations and instead requiring users to reify type variables to get their kinds. I prefer the current behavior. Might strictness be different? That is, might it be easier to reify strictness instead of include it in reified `Con`s? Perhaps. But it's yet another datatype and yet another function in `Quasi`, when we have the ability to say exactly what we want right in the `Con`. With the right flags set, you could even round-trip the reified `Con`s. To be honest, I don't feel strongly about a special reification function vs. returning the info right in the `Con`. But it does seem to me that this is design choice and is not a forced decision. I favor (weakly) returning the info right in the `Con`, just to lessen the footprint of this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 05:05:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 05:05:49 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.6a9f99a0ab903e8c87502057f7edb59c@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:18 goldfire]: > This might be more useful taking a `Name` instead of a `Con`. I imagine it has to just extract the name and look it up anyway, no? Or does it apply the extensions currently enabled to the `Con` definition and report back what GHC would decide if the declaration were given? That seems a bit silly. You're right, all it does is extract the `Name` and look it up. I opted for `qReifyConStrictness` to take a `Con` instead of a `Name` simply because you'd be less likely to pass it a bad `Name`, but then again, there are several other `Quasi` functions that are easy to pass bad `Name`s, so I'll change the it to `qReifyConStrictness :: Name -> m [DecidedStrictness]` for consistency's sake. To broadly address the rest of your comments: I called `DecidedStrictness` a "special output form" because I don't really feel like the strictness that GHC infers during compilation is comparable to unpackedness/strictness annotations. We ''could'' try to pursue a design where we unify `Bang` with `DecidedStrictness`, i.e., something like this: {{{#!hs data Strict = IsStrict | IsLazy | Unpack -- This must used with !, so it only needs one constructor | NoUnpackIsStrict | NoUnpackIsLazy | NoUnpack | NoAnnotation }}} but I don't feel like this is the right design. Why? 1. The naming just feels downright awkward (which is why I favored splitting it up). 2. There's a major issue with splicing in a datatype constructed from the TH AST. For example, if we splice this: {{{ DataD [] ''T [] [NormalC 'T [(NoAnnotation,ConT ''Int)]] [] }}} and later reify `T`, what would we get back as the strictness of its field? If we get back `NoAnnotation`, we lose the fact that GHC inferred it to be lazy/strict/etc. If we get back, say, `IsLazy`, we lose the fact that there wasn't an annotation in the first place. We could try putting both things in a `Con`, but I can't figure out a way to do it that makes sense. If we include both the user-marked strictness and the GHC-decided strictness information in a `Con`, then how would we splice in the example TH AST written above? {{{ DataD [] ''T [] [NormalC 'T [({- Source -} NoAnnotation,{- Decided -} ???,ConT ''Int)]] [] }}} It is this precisely this scenario where including the GHC-decided strictness seems to fall flat, IMO. Here, you have to put something in `???`'s place which GHC won't use, and even worse, reifying `T` after splicing it would possibly give you back something different in `???`'s place! Maybe there would be a way to make it work, but I can't see it, which is why I felt the most pertinent choice was to make `DecidedStrictness` into something which could only be reified. If you see another way that's more natural, please let me know! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 09:30:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 09:30:39 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.4078f09889f45b43804258ab2cdb11b1@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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 oerjan): I just learned that the author of the [http://hackage.haskell.org/package /type-combinators type-combinators] package has found the "design pattern" of associated type family superclasses very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 10:15:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 10:15:12 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.6ca5bf1a86755fefe9f77d17e1fe6074@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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 hvr): * cc: simonpj (added) Comment: Looks like this regression was caused by 547c597112954353cef7157cb0a389bc4f6303eb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 10:39:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 10:39:13 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.e3d030265d6da6003baba821fd006692@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 duairc): You're right, they are subtley different. But I can't "pattern-match" on (n + 1) on the LHS with GHC's TypeLits, because + is a type family and not a constructor. If there was some other way I could accomplish this then I would be satisfied with that for now. But obviously if we could get generalised injectivity that we be awesome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 10:51:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 10:51:20 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) Message-ID: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) --------------------------------+------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Hello! I am currently bootstrapping ghc for sh4 in Debian. In order to get the ghc build scripts detect sh4 as a valid architecture, I had to make local changes to aclocal.m4. With these changes, sh4 is properly detected as an architecture and I can both cross-build for sh4 as well as build ghc on this platform natively. Please apply the supplied patch so that we do not have to carry this patch in the Debian package [1] anymore. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807108 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 10:52:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 10:52:16 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.cc481f55d613148d9cde98aae5725df5@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) -------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "sh4-platform-detection-support.patch" added. Patch aclocal.m4 to detect sh4 as a valid but unknown architecture -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 10:53:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 10:53:36 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const Message-ID: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.11 libraries/base | Keywords: g | 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 instances are all permissible yet are not defined. They can all be derived with {{{GeneralizedNewtypeDeriving}}}. It would be useful for me if they were defined in {{{base}}}. These should probably also go into {{{base-orphans}}} and {{{transformers}}} (for versions of {{{base}}} before {{{Identity}}} was moved there). {{{#!hs instance Bounded a => Bounded (Const a b) instance Enum a => Bounded (Const a b) instance Ix a => Bounded (Const a b) instance Semigroup a => Semigroup (Const a b) instance Bounded a => Bounded (Identity a) instance Enum a => Bounded (Identity a) instance Ix a => Bounded (Identity a) instance Semigroup a => Semigroup (Identity a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 12:02:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 12:02:39 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.cfaca47296f128e801bc3459b8a61538@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) -------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by glaubitz): slyfox on #ghc just pointed at this commit which shows the same procedure for Alpha and other architectures [1]. Would be great if sh4 could be added in a similar way. Thanks, Adrian > [1] https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 12:38:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 12:38:12 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 Message-ID: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> #11211: Please add initial platform support for sparc64 --------------------------------+---------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Other | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Hello! I have successfully bootstrapped ghc for sparc64 on Debian unstable by cross-compiling it on amd64, then installing it manually into a build root and rebuild the Debian package. Unfortunately, the buildds can currently neither compile ghc itself nor any Haskell packages as gcc always passes "-relax" to the GNU linker which will fail as ghc passes "-Wl,-r" [1]: "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl- pthread -package-db libraries/bootstrapping.conf -this-package-key termi_6iVf4EBnOgfIaaOCLRs8jl -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist- boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist- boot/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist- boot/build -stubdir libraries/terminfo/dist-boot/build -c libraries/terminfo/./System/Console/Terminfo/Base.hs -o libraries/terminfo /dist-boot/build/System/Console/Terminfo/Base.o /usr/bin/ld: --relax and -r may not be used together collect2: error: ld returned 1 exit status make[3]: *** [libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o] Error 1 libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o' failed This issue has already been fixed in ghc but that was for sparc only and not sparc64 [2]. Thus, in order to be able to apply the same fix from [2], ghc needs to add sparc64 to its list of known architectures (currently "sparc64" matches to "ArchUnknown" in aclocal.m4") and then extend the fix from [2] to match *both* sparc *and* sparc64 (please don't drop sparc here). In particular, I suggest adding sparc64 in the same way that Alpha, Mipseb and Mipsel were added [3], thus matching "sparc64" to "ArchSPARC64", then extending the if-clause from [4] to set "-Wl,-no-relax" for *both* ArchSPARC *and* ArchSPARC64. Thanks, Adrian > [1] https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=7.10.3-3&stamp=1449983921 > [2] https://ghc.haskell.org/trac/ghc/ticket/3791 > [3] https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542 > [4] https://git.haskell.org/ghc.git/commitdiff/3b322660f82d0c7c4f7d02523367ebd0e34c5287 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 12:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 12:41:09 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.1c3a89275ca1ba784a6d88adb0ad0f8b@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) -------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"f48015bcac59960f6d266506a5f378c9bcf8f005/ghc" f48015b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f48015bcac59960f6d266506a5f378c9bcf8f005" configure: add support for 'sh4' (Trac #11209) Debian has Renesas SH4 (SuperH) port with a triplet: sh4-linux-gnu Patch by glaubitz adds 'sh4' CPU to recognize target as ArchUnknown. Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 12:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 12:52:10 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.b44892e61d944430a9419c833eec033c@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Corresponding bug report in Debian: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=807777 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 12:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 12:53:10 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.73b78d89bb2f867ceeec1a2173329f7c@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by slyfox): * status: new => closed * failure: None/Unknown => Building GHC failed * resolution: => fixed * milestone: => 8.0.1 Comment: Pushed. Thank you! In ''sh4'' case you don't need to add ''sh4'' as a known arch as there is no special code that behaves differently. In ''sparc64'' case you would need to add ''ArchSPARC64'' as you need to switch on arch type to disable ''--relax'' as ''sparc32'' does: http://git.haskell.org/ghc.git/blob/f48015bcac59960f6d266506a5f378c9bcf8f005:/compiler/main/DriverPipeline.hs#l2136 changeset:9756690fe7aa26aee6955d0b720377d53170c542 introduces ''ArchAlpha'' and friends to set ''bewareLoadStoreAlignment = True''. Default for ''UnknownArch'' was ''False''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 13:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 13:14:03 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.135c4f0d3a214ca0d31a654fcc1da35d@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g 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 duairc): These are also possible: {{{ instance Storable a => Storable (Const a b) instance Storable a => Storable (Identity a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 13:34:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 13:34:35 -0000 Subject: [GHC] #11212: Should be more liberal parsing pattern synonyms with view patterns Message-ID: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> #11212: Should be more liberal parsing pattern synonyms with view patterns -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Redundant parentheses are required around a view pattern if it is used on the RHS of a pattern synonym definition. I think that parsing should be relaxed to allow the first definition. {{{ -- Fails to parse, bug? pattern IsTrue :: Show a => a pattern IsTrue <- (== "True") . show -> True -- Parses pattern IsTrue :: Show a => a pattern IsTrue <- ((== "True") . show -> True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 14:06:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 14:06:10 -0000 Subject: [GHC] #11213: Incorrect reported pattern synonym signature Message-ID: <049.0060591a08c7b469b18d12224f42f93b@haskell.org> #11213: Incorrect reported pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ data T where MkT :: (Show b) => b -> T --pattern ExNumPat :: () => Show b => b -> T pattern ExNumPat x = MkT x }}} GHC reports that `ExNumPat` is missing a signature (correctly) but it reports the wrong type. The correct type is the one commented out. {{{ pstest.hs:12:1: warning: Top-level binding with no type signature: ExNumPat :: forall b. Show b => b -> T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 14:56:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 14:56:43 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.6a3c8f7ed2f184e69cb8fddd82b6f5d1@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Description changed by nomeata: Old description: > Hello! > > I have successfully bootstrapped ghc for sparc64 on Debian unstable by > cross-compiling it on amd64, then installing it manually into a build > root and rebuild the Debian package. > > Unfortunately, the buildds can currently neither compile ghc itself nor > any Haskell packages as gcc always passes "-relax" to the GNU linker > which will fail as ghc passes "-Wl,-r" [1]: > > "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi > -optl-pthread -package-db libraries/bootstrapping.conf -this-package- > key termi_6iVf4EBnOgfIaaOCLRs8jl -hide-all-packages -i > -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build > -ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/dist- > boot/build -Ilibraries/terminfo/dist-boot/build/autogen > -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist- > boot/build/autogen/cabal_macros.h -package-key > base_HQfYBxpPvuw8OunzQu6JGM -Wall -XHaskell2010 -no-user-package-db > -rtsopts -odir libraries/terminfo/dist-boot/build -hidir > libraries/terminfo/dist-boot/build -stubdir libraries/terminfo/dist- > boot/build -c libraries/terminfo/./System/Console/Terminfo/Base.hs -o > libraries/terminfo/dist-boot/build/System/Console/Terminfo/Base.o > /usr/bin/ld: --relax and -r may not be used together > collect2: error: ld returned 1 exit status > make[3]: *** [libraries/terminfo/dist- > boot/build/System/Console/Terminfo/Base.o] Error 1 > libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- > boot/build/System/Console/Terminfo/Base.o' failed > > This issue has already been fixed in ghc but that was for sparc only and > not sparc64 [2]. > > Thus, in order to be able to apply the same fix from [2], ghc needs to > add sparc64 to its list of known architectures (currently "sparc64" > matches to "ArchUnknown" in aclocal.m4") and then extend the fix from [2] > to match *both* sparc *and* sparc64 (please don't drop sparc here). > > In particular, I suggest adding sparc64 in the same way that Alpha, > Mipseb and Mipsel were added [3], thus matching "sparc64" to > "ArchSPARC64", then extending the if-clause from [4] to set "-Wl,-no- > relax" for *both* ArchSPARC *and* ArchSPARC64. > > Thanks, > Adrian > > > [1] > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=7.10.3-3&stamp=1449983921 > > [2] https://ghc.haskell.org/trac/ghc/ticket/3791 > > [3] > https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542 > > [4] > https://git.haskell.org/ghc.git/commitdiff/3b322660f82d0c7c4f7d02523367ebd0e34c5287 New description: Hello! I have successfully bootstrapped ghc for sparc64 on Debian unstable by cross-compiling it on amd64, then installing it manually into a build root and rebuild the Debian package. Unfortunately, the buildds can currently neither compile ghc itself nor any Haskell packages as gcc always passes "-relax" to the GNU linker which will fail as ghc passes "-Wl,-r" (1): {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl- pthread -package-db libraries/bootstrapping.conf -this-package-key termi_6iVf4EBnOgfIaaOCLRs8jl -hide-all-packages -i -ilibraries/terminfo/. -ilibraries/terminfo/dist-boot/build -ilibraries/terminfo/dist- boot/build/autogen -Ilibraries/terminfo/dist-boot/build -Ilibraries/terminfo/dist-boot/build/autogen -Ilibraries/terminfo/. -optP-include -optPlibraries/terminfo/dist- boot/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -Wall -XHaskell2010 -no-user-package-db -rtsopts -odir libraries/terminfo/dist-boot/build -hidir libraries/terminfo/dist- boot/build -stubdir libraries/terminfo/dist-boot/build -c libraries/terminfo/./System/Console/Terminfo/Base.hs -o libraries/terminfo /dist-boot/build/System/Console/Terminfo/Base.o /usr/bin/ld: --relax and -r may not be used together collect2: error: ld returned 1 exit status make[3]: *** [libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o] Error 1 libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- boot/build/System/Console/Terminfo/Base.o' failed }}} This issue has already been fixed in ghc but that was for sparc only and not sparc64 (2). Thus, in order to be able to apply the same fix from (2), ghc needs to add sparc64 to its list of known architectures (currently "sparc64" matches to "ArchUnknown" in aclocal.m4") and then extend the fix from (2) to match *both* sparc *and* sparc64 (please don't drop sparc here). In particular, I suggest adding sparc64 in the same way that Alpha, Mipseb and Mipsel were added (3), thus matching "sparc64" to "ArchSPARC64", then extending the if-clause from (4) to set "-Wl,-no-relax" for *both* ArchSPARC *and* ArchSPARC64. Thanks, Adrian * (1) https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=7.10.3-3&stamp=1449983921 * (2) https://ghc.haskell.org/trac/ghc/ticket/3791 * (3) https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542 * (4) https://git.haskell.org/ghc.git/commitdiff/3b322660f82d0c7c4f7d02523367ebd0e34c5287 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 15:56:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 15:56:51 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.9f1fae320a59f0744b0759f142a56d5f@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "0001-Map-sparc64-to-ArchSPARC64-instead-of- ArchUnknown.patch" added. Modify aclocal.m4 to map sparc64 to ArchSPARC64 instead of ArchUnknown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 15:57:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 15:57:22 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.a38675ffe81672314a49a3db03fe7787@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "0002-Explicitly-pass-no-relax-on-ArchSPARC64-where- gcc-s-.patch" added. Explicitly pass "-no-relax" to gcc on ArchSPARC64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 15:58:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 15:58:08 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.91f1024a324f3fc74a70710da0a30e65@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Alright, just attached two small patches with the suggested changes based on the previous discussion and patches that where used for ArchSPARC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 16:00:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 16:00:14 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.37352cc640f7d55ddcf2166af21c819e@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Thanks, but you could have set the author name and email to my name in the commit. Would have been my first official commit to ghc :(. Cheers, Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 17:01:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 17:01:24 -0000 Subject: [GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH) In-Reply-To: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> References: <047.298a23456baa2c6edd704dd7e644eaad@haskell.org> Message-ID: <062.68cac3d5a083344a37c3e8cc04db8e36@haskell.org> #11209: Please add platform detection support for sh4 (Hitachi SuperH) ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by slyfox): My apologies, did not follow the links to get preferred author identity and applied patch as is. I suggest using ''git commit'' / ''git format-patch'' next time. That way ''git am'' would do the right thing preserving the origin. Or you can submit patch for review using ''arc diff'': https://ghc.haskell.org/trac/ghc/wiki/Phabricator and get all the advantages of the presubmit build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 17:48:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 17:48:08 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.4d460583c61316ae43e371535da46466@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: report-impact 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 duairc): * cc: duairc (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 17:50:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 17:50:33 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.4ae2ff033dab67472f01f57ad882a76e@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "0001-Map-sparc64-to-ArchSPARC64-instead-of-ArchUnknown- an.patch" added. Replacement for 0001-Map-sparc64-to-ArchSPARC64-instead-of- ArchUnknown.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 17:51:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 17:51:29 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.af01a061021f06a6bfa78c2936050aae@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Ok, I obviously forgot to add ArchSPARC64 to compiler/utils/Platform.hs. Seems to work now, although the compilation hasn't finished yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 18:06:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 18:06:41 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.a38675ffe81672314a49a3db03fe7787@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "0002-Explicitly-pass-no-relax-on-ArchSPARC64-where- gcc-s-.patch" removed. Explicitly pass "-no-relax" to gcc on ArchSPARC64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 18:06:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 18:06:41 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.6fbd419478a7510e87eeac7dd5661b73@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by glaubitz): * Attachment "0002-Explicitly-pass-no-relax-on-ArchSPARC64-where- gcc-s-.patch" added. Reformatted the second patch to adapt ghc coding style better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 18:21:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 18:21:45 -0000 Subject: [GHC] #11214: Remove JavaScriptFFI from --supported-extensions list Message-ID: <044.186ef3fe83fb53d5e2a992d9a7def87d@haskell.org> #11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 18:26:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 18:26:34 -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.5a418debb743a4688d3c4f3ec9a7c8ea@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: | -------------------------------------+------------------------------------- Changes (by luite): * differential: => phab:D1609 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 18:40:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 18:40:32 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.9e372d3293e2f822495bd1b4ce9a17c6@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g 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 ekmett): I have no complaints about adding them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 19:16:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 19:16:22 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.f1cbd9c9a9e3b8dfbc0e9b544ffb5b4e@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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: | -------------------------------------+------------------------------------- Changes (by anders_): * cc: hello@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 21:15:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 21:15:29 -0000 Subject: [GHC] #10901: failing build of ghc in openSUSE with ncurses-6.0 In-Reply-To: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> References: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> Message-ID: <061.d1c5a0f5d6c0f1a260cb9880271603e0@haskell.org> #10901: failing build of ghc in openSUSE with ncurses-6.0 -------------------------------------+------------------------------------- Reporter: mimi.vx | Owner: Type: bug | Status: upstream Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => highest * milestone: => 8.0.1 Comment: The patch is merged upstream. Let's not forget to update the submodule before the 8.0 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 21:19:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 21:19:42 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.d04f93a2f630b312fac6f6e018edc288@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by thomie): * priority: normal => highest * status: new => patch * milestone: => 8.0.1 Comment: Let's get these patches in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 21:29:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 21:29:24 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.1acc5bb1b9c1b9027d87127172ab22c3@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Hello! I'd be willing to help with this issue when this means we can keep ghc on armel in Debian. In the meantime, I think it should be enough to build ghc on armel with --enable-unregisterised as this should always work, shouldn't it? Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 22:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 22:22:30 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.a471765e768ee66f7c238e99697b6acd@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Hi thomie! I just realized I forgot patching additional files in the compiler, namely compiler/cmm/PprC.hs compiler/nativeGen/AsmCodeGen.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/TargetReg.hs where the architecture is checked in case statements as well. I have already patched my tree and doing some test builds now, both on amd64 and sparc64. The latter will take some more time though :(. Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 22:53:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 22:53:11 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised Message-ID: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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 the following [http://hackage.haskell.org/package/raw-strings-qq simple quasiquoter]: {{{#!hs foo = QuasiQuoter { quoteExp = return . LitE . StringL [...] }}} When used like this: {{{#!hs bar :: String bar = [foo|FOO BAR BAZ|] }}} the string `bar` will contain either LF or CRLF line endings depending on which convention is used in the file. This is consistent with documentation, if a bit surprising. However, the problem is that version control systems (e.g. Git) usually store text files using Unix line endings, but allow checking them out in a platform- specific format. So this behaviour gives rise to subtle semantics changes in the compiled program that depend on the user's VCS settings. Therefore IMO it makes sense to always normalise CRLF to LF in quasiquotations. Originally reported [https://github.com/23Skidoo/raw-strings-qq/issues/1 here], a test case can be found [https://github.com/23Skidoo/raw-strings- qq/blob/master/test/Test.hs here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 22:58:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 22:58:19 -0000 Subject: [GHC] #11189: bang pattern parsing inconsistency In-Reply-To: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> References: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> Message-ID: <058.179f8a1073873bab575d26be75df2ac6@haskell.org> #11189: bang pattern parsing inconsistency -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10732 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Compiler (Parser) * related: => #10732 Comment: This parses: {{{ len3 (!x : (!xs)) = 1 + len xs }}} Anyway, duplicate of #10732. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 23:01:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 23:01:42 -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.e0e34b4fb703fda634fdd28e2488fbd8@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 23:07:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 23:07:44 -0000 Subject: [GHC] #10732: Legal Bang Patterns cannot parse In-Reply-To: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> References: <042.4ad4dd039de0d1dea0d83f39e9f13584@haskell.org> Message-ID: <057.fadd4259033aaddf1a851b16e67176bf@haskell.org> #10732: Legal Bang Patterns cannot parse -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Bang Pattern Resolution: | Parser Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1087, #11189 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1087, #11189 Comment: Also reported as #11189. More investigation in #1087 (reported 9 years ago!) and ?http://hackage.haskell.org/trac/haskell- prime/wiki/ArrayIndexing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 23:26:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 23:26:13 -0000 Subject: [GHC] #11212: Should be more liberal parsing pattern synonyms with view patterns In-Reply-To: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> References: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> Message-ID: <064.16e467707409edab7a4de7b6afe6a3e7@haskell.org> #11212: Should be more liberal parsing pattern synonyms with view patterns -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 13 23:28:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Dec 2015 23:28:01 -0000 Subject: [GHC] #11188: Confusing "parse error in pattern" for spurious indentation. In-Reply-To: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> References: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> Message-ID: <066.c77d65592587f83fc1ea933c48a914ae@haskell.org> #11188: Confusing "parse error in pattern" for spurious indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.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 thomie): * failure: Other => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 00:15:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 00:15:36 -0000 Subject: [GHC] #10741: add flag to dump module and package dependencies In-Reply-To: <047.188005ccfe15311e6be2a08f0516bdf3@haskell.org> References: <047.188005ccfe15311e6be2a08f0516bdf3@haskell.org> Message-ID: <062.2fe01e41ad7260c69e9bfbf15c4f3f3e@haskell.org> #10741: add flag to dump module and package dependencies -------------------------------------+------------------------------------- Reporter: elaforge | 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: | -------------------------------------+------------------------------------- Comment (by thomie): You could write your own **Frontend plugin** for this: https://github.com/ghc/ghc/commit/a3c2a26b3af034f09c960b2dad38f73be7e3a655. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 03:37:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 03:37:43 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.d53a4e872bd02beb64b8db02282b54c3@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 04:39:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 04:39:25 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` Message-ID: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE RebindableSyntax #-} module Bug where foo :: (a, b) -> () foo x | (_,_) <- x = () }}} I get {{{ Bug.hs:6:9: error: Not in scope: ?fail? }}} Yet even if I bring `fail` into scope, it's not mentioned in the Core produced by my program. And it really shouldn't: there's not a monad in sight! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 04:40:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 04:40:58 -0000 Subject: [GHC] #11217: Empty GADT-style declaration accepted without extensions Message-ID: <047.11cab397bfecfda2caf2c6d1874d3763@haskell.org> #11217: Empty GADT-style declaration accepted without extensions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 module compiles without complaint: {{{#!hs module Bug where data Foo where }}} It should require `-XGADTSyntax`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 06:51:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 06:51:33 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.b65675417b43c795eeb20200294020b0@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfordivam): * owner: dfordivam => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 09:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 09:10:46 -0000 Subject: [GHC] #11217: Empty GADT-style declaration accepted without extensions In-Reply-To: <047.11cab397bfecfda2caf2c6d1874d3763@haskell.org> References: <047.11cab397bfecfda2caf2c6d1874d3763@haskell.org> Message-ID: <062.e9c73cc4826a9a7202e5b7426ff85737@haskell.org> #11217: Empty GADT-style declaration accepted without extensions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 monoidal): * status: new => closed * resolution: => duplicate Comment: Already reported as #8258. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 09:59:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 09:59:20 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict In-Reply-To: <051.563028756f74e7233040685912e51248@haskell.org> References: <051.563028756f74e7233040685912e51248@haskell.org> Message-ID: <066.ea06ca440ba6b4b6aebda89806b7492a@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: adamse Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | 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:D1612 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * owner: => adamse * differential: => Phab:D1612 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 10:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 10:39:51 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags Message-ID: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 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: Design/Warnings -------------------------------------+------------------------------------- TODO: description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 10:43:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 10:43:06 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags In-Reply-To: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> References: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> Message-ID: <057.1fadd63864842fe618a2498e178bf3b4@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 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:D1613 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high * status: new => patch * differential: => Phab:D1613 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 10:48:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 10:48:55 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.85a86eae8bf0c8e91284451726cb1b22@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Any progress on this Phyx-? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 11:30:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 11:30:40 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility Message-ID: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: Design/Warnings -------------------------------------+------------------------------------- ...copied from Design/Warnings: Introduce variant of `-Werror` (c.f. GCC's `-Werror=*`) which allows to specify the individual warnings to be promoted to errors, e.g. - `-Wall -Werror=orphans` would only promote `-Worphans` warnings into errors - `-Wall -Werror -Wno-error=missing-methods` would promote all warnings //except// `-Wmissing-methods` into errors TODO: specify semantics a bit more exactly (the basic idea is to follow gcc/clang as much as sensible, and only deviate where it's necessary) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 11:35:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 11:35:27 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.0cfa8d52c64a76904b182e82614edb64@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11218 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #11218 Comment: this is related to #11218 as we want less confusing `-W`-flags/tokens to go together with `-Werror=...` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 11:38:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 11:38:27 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.eddcec76b2f6a0184fcffa63d405ba72@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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 hvr): * owner: => quchen * version: 7.10.2 => * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 11:38:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 11:38:40 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.012dbc4cfe8cc30cd9243775f5718b6f@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 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: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * wikipage: => Design/Warnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 12:20:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 12:20:44 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.3136d166cd32cf140f349238fa818513@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari I've tried 2 approaches which haven't worked completely: 1) I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach. 2) I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors. What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet. I'll give that a try tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 12:22:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 12:22:20 -0000 Subject: [GHC] #11189: bang pattern parsing inconsistency In-Reply-To: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> References: <043.4c94f3f08aa54ab13d08d6589afac47a@haskell.org> Message-ID: <058.8e992a8f9591ee6382d0fd8ac15339d3@haskell.org> #11189: bang pattern parsing inconsistency -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10732 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I doubt this is hurting anyone much, but it'd be great to fix it. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 12:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 12:40:04 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.dc95fa4b3a8a129c1af266bcf434c6c4@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: kylcarte@? (added) Comment: Can I ask: does `wip/T11067` make it easier? It's pretty simple: with `UndecidableSuperClasses` the whole superclass restriction is lifted. Adding kylcarte at gmail.com in cc, who is the author of type-combinators Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 13:07:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 13:07:07 -0000 Subject: [GHC] #11212: Should be more liberal parsing pattern synonyms with view patterns In-Reply-To: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> References: <049.71df40eb3b973c71d3a05bf170520dec@haskell.org> Message-ID: <064.056b9df1b58acd1212d10405a139fb74@haskell.org> #11212: Should be more liberal parsing pattern synonyms with view patterns -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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): I'm not sure actually. The former is really quite hard to parse, to my eyes! But I don't feel strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 13:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 13:22:16 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.edc0487fac41629cd9c7863b6ab92f66@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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 simonpj): I'm sorry about that. For the benefit of other readers, GHCi tries to print types that make sense in the lexical scope of the REPL (i.e. the interactive context). If a type needs to be qualified, GHC will qualify it when printing it out. But in the commit hvr points to in comment:3, I gave the pacakges `ghc- prim`, `base` and `template-haskell` special behaviour, and are printed unqualified. How bad is that? Does tooling really parse error messages? (If so there should be a Better Way!) My motivation, as explained in the commit, was to avoid printing a heavily-qualified `Constraint` when giving kind signatures. But maybe there is a better way to do that? I'd be happy with an agreed design change here. As the commit says, it's a bit arbitrary as it stands. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 13:53:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 13:53:02 -0000 Subject: [GHC] #11053: Add a warning for pattern synonyms without signatures In-Reply-To: <049.14bd36767d1a42a7a773049896471d92@haskell.org> References: <049.14bd36767d1a42a7a773049896471d92@haskell.org> Message-ID: <064.c29b11a0f38234fb227d89c7a8850fb7@haskell.org> #11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyns/T11053 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Note that including this in `-Wall` makes it harder for clients to maintain a warning-free library over 3 releases, given that pattern synonyms were available one cycle before their signatures. I'm still not personally entirely convinced about that policy, but it does seem to have traction and we should keep it in mind as we evolve the language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 13:57:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 13:57:30 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.5ca648a45fc953cc307e1abc1cb4d16a@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): You're absolutely right -- there is no way to fix the `TypeLits` style, until we have generalized injectivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:13:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:13:36 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.70184f13e7469f25a8391c881b80082f@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. I relent. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:18:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:18:49 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.72f8a55eb97f43cd349153dacb16edfd@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:20:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:20:14 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.57cb482af57f0e3e8fe0829175fa850a@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g 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): duairc, would you like to submit a patch for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:27:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:27:05 -0000 Subject: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides In-Reply-To: <041.d227e4e2f98d3171cf4e574a410067a1@haskell.org> References: <041.d227e4e2f98d3171cf4e574a410067a1@haskell.org> Message-ID: <056.ea1b49c41c58a0f8cd4b0b5dfba33c00@haskell.org> #3738: Typechecker floats stuff out of INLINE right hand sides -------------------------------------+------------------------------------- Reporter: rl | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T3738 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Small program: > {{{ > foo :: Num a => [a] -> a > {-# INLINE foo #-} > foo = go 0 > where > go m (n:ns) = m `seq` go (m+n) ns > go m [] = m > > bar :: [Int] -> Int > {-# INLINE bar #-} > bar = foo > }}} > Here is what `bar` looks like in the interface file: > {{{ > a6de4c46e53e565ed25ab5a38910e9cb > $wgo :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# > {- Arity: 2, HasNoCafRefs, Strictness: LS -} > 6838e3faa095285614477ebc92f54987 > bar :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, Inline: INLINE, > Unfolding: InlineRule: (arity 0 False) (Foo.bar_foo) -} > 5d06906ae99b9aefa1c6d251c3f2fc46 > bar_foo :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, > Unfolding: InlineRule: (arity 0 True) (\ w :: [GHC.Types.Int] -> > case @ GHC.Types.Int > Foo.$wgo 0 w of ww { DEFAULT -> > GHC.Types.I# ww }) -} > }}} > Note that the loop has disappeared from `bar`'s unfolding. Also, > `bar_foo` doesn't have an INLINE pragma. > > Incidentally, GHC specialises `foo` here and the specialisation doesn't > get an INLINE pragma, either: > {{{ > foo :: forall a. GHC.Num.Num a => [a] -> a > {- Arity: 1, HasNoCafRefs, Strictness: L, Inline: INLINE, > Unfolding: InlineRule: (arity 1 False) ... -} > > foo_$sfoo :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, > Unfolding: InlineRule: (arity 0 False) ... -} > > "SPEC Foo.foo [GHC.Types.Int]" ALWAYS forall $dNum :: GHC.Num.Num > GHC.Types.Int > Foo.foo @ GHC.Types.Int $dNum = Foo.foo_$sfoo > }}} New description: Small program: {{{#!hs foo :: Num a => [a] -> a {-# INLINE foo #-} foo = go 0 where go m (n:ns) = m `seq` go (m+n) ns go m [] = m bar :: [Int] -> Int {-# INLINE bar #-} bar = foo }}} Here is what `bar` looks like in the interface file: {{{ a6de4c46e53e565ed25ab5a38910e9cb $wgo :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# {- Arity: 2, HasNoCafRefs, Strictness: LS -} 6838e3faa095285614477ebc92f54987 bar :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Inline: INLINE, Unfolding: InlineRule: (arity 0 False) (Foo.bar_foo) -} 5d06906ae99b9aefa1c6d251c3f2fc46 bar_foo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 True) (\ w :: [GHC.Types.Int] -> case @ GHC.Types.Int Foo.$wgo 0 w of ww { DEFAULT -> GHC.Types.I# ww }) -} }}} Note that the loop has disappeared from `bar`'s unfolding. Also, `bar_foo` doesn't have an INLINE pragma. Incidentally, GHC specialises `foo` here and the specialisation doesn't get an INLINE pragma, either: {{{ foo :: forall a. GHC.Num.Num a => [a] -> a {- Arity: 1, HasNoCafRefs, Strictness: L, Inline: INLINE, Unfolding: InlineRule: (arity 1 False) ... -} foo_$sfoo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 False) ... -} "SPEC Foo.foo [GHC.Types.Int]" ALWAYS forall $dNum :: GHC.Num.Num GHC.Types.Int Foo.foo @ GHC.Types.Int $dNum = Foo.foo_$sfoo }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:33:21 -0000 Subject: [GHC] #10819: Can't generate data decls deriving multiparam type classes with TH In-Reply-To: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> References: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> Message-ID: <060.c9b6771af7f9498ec56e3409dec8eca2@haskell.org> #10819: Can't generate data decls deriving multiparam type classes with TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T18019.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1202 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"04ab55d9a6fe311b7cb544211738caca6c00c720/ghc" 04ab55d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04ab55d9a6fe311b7cb544211738caca6c00c720" Use Cxt for deriving clauses in TH (#10819) Summary: Deriving clauses in the TH representations of data, newtype, data instance, and newtype instance declarations previously were just [Name], which didn't allow for more complex derived classes, eg. multi-parameter typeclasses. This switches out [Name] for Cxt, representing the derived classes as types instead of names. Test Plan: validate Reviewers: goldfire, spinda, austin Reviewed By: goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1202 GHC Trac Issues: #10819 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:33:21 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.04a72c448cd47b450c56f45342ec3c04@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:"59d3948f02b8a50788f2049014b302bb5b88c5a7/ghc" 59d3948f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59d3948f02b8a50788f2049014b302bb5b88c5a7" Add testcase for #11216 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:33:21 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict In-Reply-To: <051.563028756f74e7233040685912e51248@haskell.org> References: <051.563028756f74e7233040685912e51248@haskell.org> Message-ID: <066.d39e0a825dcf0b55a4cde6947eb61a08@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: adamse Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | 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:D1612 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"419b6c00c194ccbd3c94539c26246dc41c88ed6c/ghc" 419b6c0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="419b6c00c194ccbd3c94539c26246dc41c88ed6c" Make binds in do-blocks strict when -XStrict (#11193) Previously bindings in `do` blocks were omitted. With `-XStrict` ```lang=hs do content <- action other_things ``` should be equivalent to ```lang=hs do !content <- action other_things ``` Fixes #11193. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1612 GHC Trac Issues: #11193 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:33:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:33:52 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.8bbc7d2612d0f936d020f17641d17b9b@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T11216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:36:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:36:18 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict In-Reply-To: <051.563028756f74e7233040685912e51248@haskell.org> References: <051.563028756f74e7233040685912e51248@haskell.org> Message-ID: <066.36c7b9c96d22be46445eaf2fd7231469@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: adamse Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | 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:D1612 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:44:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:44:34 -0000 Subject: [GHC] #10819: Can't generate data decls deriving multiparam type classes with TH In-Reply-To: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> References: <045.f6bd7f45fafc0112a449414b624abe97@haskell.org> Message-ID: <060.90104f7409882a54060ac0ac9790335f@haskell.org> #10819: Can't generate data decls deriving multiparam type classes with TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T18019.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1202 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:53:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:53:11 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route Message-ID: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- GHC 7.10.3 eats a lot of memory and segfaults compiling this. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE TypeOperators #-} module Main where import Data.Proxy import Servant.API -- requires servant data A apiP :: Proxy Api apiP = Proxy -- Users type Api = "variants" :> Get '[JSON] () routeL :: URI routeL = safeLink apiP (Proxy :: Proxy ("variants" :> Get '[A] ())) -- Should result in type error -- '[JSON] in route but '[A] here main = print routeL }}} There is '[ JSON ] in Api type, but '[A] in Proxy type passed to safeLink, so it should result in type error. Correct program compiles without problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:55:25 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.dbcafa0224e3fcb4a5e0cbb942ff2586@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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): * priority: normal => high * failure: None/Unknown => Compile-time crash * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:59:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:59:26 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.c91b101273c0b3784984a0769a5e80d8@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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 bgamari): On GHC 8.0 this fails with, {{{ $ ghc Hi.hs [1 of 1] Compiling SmAssetMan.Routes ( Hi.hs, Hi.o ) Hi.hs:40:22: error: ? Reduction stack overflow; size = 201 When simplifying the following type: Servant.Utils.Links.And (Servant.Utils.Links.IsSubList '[HALJSON] '[]) (Servant.Utils.Links.IsSubList '[] '[]) 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 expression: safeLink apiP (Proxy :: Proxy ("projects" :> (Capture "project_id" ProjectId :> ("variants" :> Get Mimes ())))) In an equation for ?variantsByProjectL?: variantsByProjectL = safeLink apiP (Proxy :: Proxy ("projects" :> (Capture "project_id" ProjectId :> ("variants" :> Get Mimes ())))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 14:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 14:59:59 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.5e12571196ed604c860fa0fe7d5cd29e@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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: goldfire (added) Old description: > GHC 7.10.3 eats a lot of memory and segfaults compiling this. > > {{{#!hs > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE EmptyDataDecls #-} > {-# LANGUAGE TypeOperators #-} > module Main where > > import Data.Proxy > > import Servant.API -- requires servant > > data A > > apiP :: Proxy Api > apiP = Proxy > > -- Users > > type Api = "variants" :> Get '[JSON] () > > routeL :: URI > routeL = safeLink apiP > (Proxy :: Proxy ("variants" :> Get '[A] ())) > -- Should result in type error > -- '[JSON] in route but '[A] here > > main = print routeL > > }}} > > There is '[ JSON ] in Api type, but '[A] in Proxy type passed to > safeLink, so it should result in type error. > > Correct program compiles without problems. New description: GHC 7.10.3 eats a lot of memory and segfaults compiling this. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE TypeOperators #-} module Main where import Data.Proxy import Servant.API -- requires servant data A apiP :: Proxy Api apiP = Proxy -- Users type Api = "variants" :> Get '[JSON] () routeL :: URI routeL = safeLink apiP (Proxy :: Proxy ("variants" :> Get '[A] ())) -- Should result in type error -- '[JSON] in route but '[A] here main = print routeL }}} There is `'[ JSON ]` in `Api` type, but `'[A]` in `Proxy` type passed to `safeLink`, so it should result in type error. Correct program compiles without problems. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:07:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:07:09 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.6b175ec169e32ea5f84f5b03ccd562d7@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1594 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:07:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:07:35 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.12f9c46d9441630fabb40c5276e02620@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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 sopvop): #10806 may be related, but is marked as fixed in master -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:09:55 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.8bf5c51e5912420d1c9ed7d2e820d56a@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Phab:D1422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:15:55 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.dd05ca6d248cc82c3ad73a0a78d156cf@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ross@? (added) * status: patch => new * owner: strake888 => Comment: Herbert thinks that the patch is incomplete, although 90% done. It'll need to be finished in the next 6 days, including coordination with the `transformers` package, if it's to get into GHC 8.0. Ryan, Ross: how much do you care? Do you want to make it happen? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:16:13 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.62537198e5dba9b33d6f3c7a085f8e35@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:16:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:16:45 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 8.0.1 RC In-Reply-To: <042.27be62378f24cc29ae2d842288972a74@haskell.org> References: <042.27be62378f24cc29ae2d842288972a74@haskell.org> Message-ID: <057.6c531625ea2bf8ab9d14b53742b707f4@haskell.org> #10238: Update libffi shortly before first GHC 8.0.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: fixed | Keywords: libffi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1589 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:19:41 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn where layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.268cbb3cc35611b3dd0a3639016fea56@haskell.org> #10250: API Annotations : add Locations in hsSyn where layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D815,Phab:D1370 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Old description: > At the moment ghc-exactprint, which uses the GHC API Annotations to > provide a framework for roundtripping Haskell source code with optional > AST edits, has to implement a horrible workaround to manage the points > where layout needs to be captured. > > These are > > MatchGroup > HsDo > HsCmdDo > HsLet > LetStmt > HsCmdLet > GRHSs > > To provide a more natural representation, the contents subject to layout > rules need to be wrapped in a SrcSpan. New description: At the moment ghc-exactprint, which uses the GHC API Annotations to provide a framework for roundtripping Haskell source code with optional AST edits, has to implement a horrible workaround to manage the points where layout needs to be captured. These are {{{ MatchGroup HsDo HsCmdDo HsLet LetStmt HsCmdLet GRHSs }}} To provide a more natural representation, the contents subject to layout rules need to be wrapped in a SrcSpan. -- Comment: It seems this is done; Alan, feel free to reopen if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:21:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:21:10 -0000 Subject: [GHC] #11150: New `-fwarn-noncanonical-monoid-instances` warning In-Reply-To: <042.55096ce3dad11d93367502f540669d4a@haskell.org> References: <042.55096ce3dad11d93367502f540669d4a@haskell.org> Message-ID: <057.54dde6b8bcc8b9098c9a92066cc63bef@haskell.org> #11150: New `-fwarn-noncanonical-monoid-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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: #11128, #11139 | Differential Rev(s): Phab:D1553 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:27:17 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.fe5b067343f624f8b747f4b4625bbcf3@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This hasn't yet been merged and likely won't make 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:27:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:27:29 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.9c999e6470514a6beec701103d7b9fb1@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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 hvr): Replying to [comment:4 simonpj]: > How bad is that? Does tooling really parse error messages? (If so there should be a Better Way!) While there *should* be a better way, there isn't yet... GHC doesn't ship with anything better than GHC(i) right now Here's two ways how this regression affects Emacs' haskell-mode: - For warnings about missing type-signatures, Emacs parses the warning message and then inserts the extracted missing type-signature - Another feature is based on GHCi, which queries the symbol under the cursors for its type, and then inserts that above as a type-signature There may be other features I may have forgotten about which also require to know renamer-information. In both cases it's important to know how to qualify (if needed) symbols. And in passive mode (e.g. when parsing GHC's warning messages w/o an active GHCi session attached) Emacs has no way to query the module namespace. In active mode (e.g. when using GHCi to resolve/introspect information) Emacs uses `:type`/`:browse`/`:info` as well as other commands newly added (soon) to GHC 8.0 (see #10874). Those now are missing the module qualifications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:27:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:27:55 -0000 Subject: [GHC] #10603: Output of -ddump-splices is parenthesized incorrectly In-Reply-To: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> References: <050.70ab9071ed50ac22038e86553f4b759c@haskell.org> Message-ID: <065.7c88e060b530552debd3152fdf2462bb@haskell.org> #10603: Output of -ddump-splices is parenthesized incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dnusbaum Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10703 | Differential Rev(s): Phab:D1114 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.2.1 => 8.0.1 Comment: This whole ticket is just symptomatic of a broader issue. As Richard says: "The problem is that HsExpr is intended to be parsed Haskell source. Printing should thus be a breeze: the programmer had to insert all the necessary parens, so we just spit back out what the programmer said. "However, splicing in TH also produces HsExpr. Because it's not programmer-specified, the parentheses are unnecessary here, because no parser will ever look at it. But here we do want parentheses. "We could try to get the HsExpr pretty-printer to be smarter about all of this. But I think that's barking up the wrong tree -- ideally, the HsExprpretty-printer should be very dumb about parentheses. (Indeed, I believe that ppr_expr should never recur into pprParendExpr. But that's more than we need to accomplish today.) "Instead, I think a better approach is to have the Convert module add HsPar nodes. By doing this, we make it more possible that printing HsExpr will be exactly what the programmer wrote, while still getting valid output from TH." And in `HsExpr` we find {{{ HsSyn records exactly where the user put parens, with HsPar. So generally speaking we print without adding any parens. However, some code is internally generated, and in some places parens are absolutely required; so for these places we use pprParendExpr (but don't print double parens of course). For operator applications we don't add parens, because the operator fixities should do the job, except in debug mode (-dppr-debug) so we can see the structure of the parse tree. }}} I like Richard's proposed solution. Let's do that rather than making an ad-hoc fix for this particular example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:28:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:28:46 -0000 Subject: [GHC] #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH In-Reply-To: <042.c278176d2dd239200103849cc54d10cc@haskell.org> References: <042.c278176d2dd239200103849cc54d10cc@haskell.org> Message-ID: <057.c8cb215238c1eca1ac811b9959b9aa34@haskell.org> #11121: Introduce `-XTemplateHaskellQuotes` pragma for subset of TH -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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: #10382, #11102 | Differential Rev(s): Phab:D1511 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:29:35 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.7c84f43f8545437ba53d94986c3ca9d4@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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): The new error is actually somewhat informative. I don't have the definitions of `IsSubList` and `And` to hand (though they're easy to imagine). Could they loop? If they are the simple definitions I imagine, this is indeed a GHC bug. If they reasonably can loop, on the other hand, then this error message might be acceptable. Need feedback from the original poster, and a test case that doesn't depend on all of `servant` would be great. (Just inline the definitions into this module?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:29:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:29:45 -0000 Subject: [GHC] #11202: T10667 and debug tests are broken on OS X In-Reply-To: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> References: <046.9bbe241c86a8c9df8ff885b81a9abfd3@haskell.org> Message-ID: <061.89a69a83b82efaf5b6620dc8b46ff3b8@haskell.org> #11202: T10667 and debug tests are broken on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: debug, T10667 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1602 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:35:58 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.264c9aa7e0d0f733bfbbe2e9a4bf347b@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm preoccupied with other tickets that I absolutely want to make it in before the 8.0 release, so I doubt I'll be able to get this one in time (especially since `transformers`-related require several rounds of back- and-forth between Ross, someone with GHC push access, and myself). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:38:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:38:18 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.5ecaa5c8f2f2710bd8a502304328413c@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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 goldfire): I'm not convinced the normalizing is something GHC should do. The quasi- quoter could easily do this. Maybe a quasi-quoter wants, for some inscrutable reason, to tell the difference between LF and CRLF. (Perhaps to warn a user about a bad newline encoding. But I admit this possibility is a stretch.) If GHC normalizes, then quasi-quoters have lost this ability. On the other hand, it's dead easy for a quasi-quoter to do this itself. If you feel strongly, I could see the benefit of having a `normaliseLineEndings :: String -> String` available in `Language.Haskell.TH.Quote` but even that seems a little special-cased. And I'm certainly in favor of making this louder in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:39:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:39:07 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.476ec2f61363af7da08c0e0b9beeb8d7@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Old description: > Straight from `Data.Foldable`, here is the documentation for `foldl`: > > {{{ > -- | Left-associative fold of a structure. > -- > -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ > }}} > > But, of course, `Prelude.foldl` is the same `foldl`! > > There are other functions with similar problems. > > When revising these, please put in (back?) examples of how these work, at > least on lists. I've been doing functional programming for some time, and > I still like to look at examples to make sure that I'm getting my `foldl` > and `foldr` straight. Maybe it's because my brain is small, but we don't > want to exclude people with small brains! New description: Straight from `Data.Foldable`, here is the documentation for `foldl`: {{{#!hs -- | Left-associative fold of a structure. -- -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ }}} But, of course, `Prelude.foldl` is the same `foldl`! There are other functions with similar problems. When revising these, please put in (back?) examples of how these work, at least on lists. I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. Maybe it's because my brain is small, but we don't want to exclude people with small brains! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:39:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:39:42 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) In-Reply-To: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> References: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> Message-ID: <057.041386be3a15ffaac6071e95f3324e60@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dolio Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1605 Wiki Page: | prime:Libraries/Proposals/ExpandFloating| -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:39:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:39:57 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.412fa79da12bace289172933cf3cde07@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee, ekmett (added) Old description: > Straight from `Data.Foldable`, here is the documentation for `foldl`: > > {{{#!hs > -- | Left-associative fold of a structure. > -- > -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ > }}} > > But, of course, `Prelude.foldl` is the same `foldl`! > > There are other functions with similar problems. > > When revising these, please put in (back?) examples of how these work, at > least on lists. I've been doing functional programming for some time, and > I still like to look at examples to make sure that I'm getting my `foldl` > and `foldr` straight. Maybe it's because my brain is small, but we don't > want to exclude people with small brains! New description: Straight from `Data.Foldable`, here is the documentation for `foldl`: {{{ -- | Left-associative fold of a structure. -- -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ }}} But, of course, `Prelude.foldl` is the same `foldl`! There are other functions with similar problems. When revising these, please put in (back?) examples of how these work, at least on lists. I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. Maybe it's because my brain is small, but we don't want to exclude people with small brains! -- Comment: Could anyone on the Core Libraries Committee nail this in the next few days. It's not hard! Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 15:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 15:44:13 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.4fceede32ebd02166200140d64043b55@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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 sopvop): * Attachment "Main.hs" added. With relevant parts of servant inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:02:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:02:12 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.6e46cad6f20db405957cb85c247ea7c6@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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): You have this definition: {{{ type family IsSubList a b :: Constraint where IsSubList '[] b = () IsSubList '[x] (x ': xs) = () IsSubList '[x] (y ': ys) = IsSubList '[x] ys IsSubList (x ': xs) y = IsSubList '[x] y `And` IsSubList xs y }}} But `IsSubList '[Int] '[]` loops by triggering the fourth equation (and being apart from all previous ones). Note that the left conjunct of the `And` is the exact same thing that we started with. So I think GHC's behavior here is quite reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:05:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:05:29 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.0d106a5049d0b0eb6abe6c99b70665c2@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: Phyx-, could you perhaps open a new ticket just to track this issue so we can close this ticket? I think most of the information needed has already been written down here in one place or another; it's just a matter of copying it to a new ticket, distilling a clear statement of the problem, and collecting the approaches that you have already tried. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:05:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:05:51 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.66d217ba17bd4441a3b60a53fd4de819@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | 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 sopvop): I'll report this to servant devs then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:22:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:22:15 -0000 Subject: [GHC] #11221: Remove -fwarn-context-quantification Message-ID: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> #11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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 option was deprecated and does nothing as of GHC 8.0. Remove `Opt_WarnContextQuantification` and its uses from `DynFlags`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:26:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:26:00 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.8abcfad1f3b9ad2e9623a676d6b87d58@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 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: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D211 => Phab:D211, Phab:D1615 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:32:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:32:06 -0000 Subject: [GHC] #11220: Stack overflow instead of type check failure in Servant route In-Reply-To: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> References: <045.57f4c4c9ffdc811865767d1f46090748@haskell.org> Message-ID: <060.b84bce4ee7887a0503a57d20dbc8c971@haskell.org> #11220: Stack overflow instead of type check failure in Servant route -------------------------------------+------------------------------------- Reporter: sopvop | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: invalid | 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 goldfire): * status: new => closed * resolution: => invalid Comment: OK. I'm closing this as invalid. Do reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:55:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:55:55 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations Message-ID: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Consider the `catch#` primop, {{{#!hs catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -- ^ thing to catch exceptions from -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -- ^ exception handler -> State# RealWorld -> (# State# RealWorld, a #) }}} Semantically, this operation will always evaluate its first argument. Ideally we would indicate this in the primop's strictness signature in `primops.txt.pp`. Sadly, we can't do this at the moment due to a subtle wrinkle (discovered in #10712): Consider, {{{#!hs let r = \st -> raiseIO# blah st in catch (\st -> ...(r st)..) handler st }}} If we give the first argument of catch a strict signature, we'll get a demand `C(S)` for `r`; that is, `r` is definitely called with one argument, which indeed it is. The trouble comes when we feed `C(S)` into `r`'s RHS as the demand of the body as this will lead us to conclude that the whole `let` will diverge; clearly this isn't right. As Simon noted in ticket:10712#comment:4, > There's something very special about catch: it turns divergence into non-divergence. In order to apply a proper strictness signature to `catch`-like operations we would need to teach the strictness analyzer about this property. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 16:56:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 16:56:55 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.355c34570a6a80c88a45eb6776a31984@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1616 Comment: I have opened Phab:D1616 with what I believe is a fix for this. I have also opened #11222 to track the fact that currently we are forced to pessimize our strictness signatures on `catch`-like operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 17:11:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 17:11:24 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.0054ecb14c01abedbdc604346e189a79@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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 refold): I'll summarise/reiterate my arguments for doing this in GHC: * Other languages do this. For example, multiline raw string literals in Python will have LF line endings regardless of the source file encoding. Same in C++. * Requiring the users to do it themselves is error-prone. Basically everyone who implements a quasiquoter now has to remember about this quirk. * The feature hurts portability but benefits no one, because line endings can change depending on which platform the program is compiled. * This behaviour already caused a [https://github.com/23Skidoo/raw- strings-qq/issues/1 bug in real code], but there're no examples of code actually depending on it. * The problem is exacerbated by the automatic newline conversion in version control systems. * If you really want to preserve this behaviour, it should be opt-in instead of opt-out. Adding `normaliseLineEndings` to the standard library is not a solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 17:39:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 17:39:19 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.050049febe75db423ddbccb72cb9f6d2@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | 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:D1617 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1617 Comment: goldfire, could you comment on Phab:D1617 and describe what else you would like to see in this documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 19:09:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 19:09:13 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.22f0579bea217b6fe511d0c86524292b@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by strake888): Sorry about this, I thought it would be a simple operation to patch transformers before the RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 19:12:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 19:12:03 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.87a2feb66229647502c1ab853c2755ba@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) Comment: I don't think that any solution which 'looks through" pattern synonyms is desirable as it would break the abstraction. I think that Joachim's suggestion is perhaps a bit better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 19:16:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 19:16:30 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.03fc42431b031683a98afb18f1944bf1@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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 jstolarek): Is this fixed by 6746549772c5cc0ac66c0fce562f297f4d4b80a2 ? I don't have latest HEAD to test :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 19:34:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 19:34:08 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.323400be32a51f11d123dfabdfb6bfa6@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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): This compiles: {{{ {-# LANGUAGE TypeInType #-} module PromotableTypeSynonyms where import Data.Kind data B = T | F data P :: B -> * type B' = B data P' :: B' -> * }}} Note: in case you are on Debian or Ubuntu, you can install always latest HEAD (1 day delay) from here: https://launchpad.net/~hvr/+archive/ubuntu/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:03:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:03:38 -0000 Subject: [GHC] #11185: runghc can't find ghc-stage2 on a Windows build In-Reply-To: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> References: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> Message-ID: <065.bc41efc99b6a5b06de7e0fd9b4e00919@haskell.org> #11185: runghc can't find ghc-stage2 on a Windows build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 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): Phab:D1621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1621 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:18:43 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex Message-ID: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10726 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting. If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error. A workaround The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile. {{{ 128 emptyPLS :: DynFlags -> PersistentLinkerState 129 emptyPLS _ = PersistentLinkerState { 130 closure_env = emptyNameEnv, 131 itbl_env = emptyNameEnv, 132 pkgs_loaded = init_pkgs, 133 bcos_loaded = [], 134 objs_loaded = [], 135 temp_sos = [] } 136 137 -- Packages that don't need loading, because the compiler 138 -- shares them with the interpreted program. 139 -- 140 -- The linker's symbol table is populated with RTS symbols using an 141 -- explicit list. See rts/Linker.c for details. 142 where init_pkgs = [rtsUnitId] }}} I've tried 2 approaches which haven't worked completely: 1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach. 2. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors. What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet. Example (LogFloat.hs file): {{{#!hs module Main (main) where import Data.Number.LogFloat (log1p) main :: IO () main = print $ log1p 1.0 }}} `runGhc LogFloat.hs` will fail: {{{ Loading package logfloat-0.13.3.3 ... linking ... LogFloat.hs: ...\x86_64-windows- ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p' LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:19:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:19:22 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.0009e716e61270799d8d7d1526a91169@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:21:51 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.c5f31861a5c6a6d727cf272e4fca3295@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 #11223 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed * related: #9218 #9014 #10435 => #9218 #9014 #10435 #11223 Comment: Closing this issue as the error isn't directly related to the upgrade of `GCC` as it predated the upgrade. New issue is now #11223 . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:35:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:35:05 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.e99e8101f07da53b457caafb5407a7bb@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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): Worth a regression test if someone could add one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:40:04 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. Message-ID: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language PatternSynonyms , ViewPatterns #-} import Text.Read -- pattern PRead :: () => Read a => a -> String pattern PRead a <- (readMaybe -> Just a) foo :: String -> Int foo (PRead x) = (x::Int) foo (PRead xs) = sum (xs::[Int]) foo _ = 666 bar :: String -> Int bar (readMaybe -> Just x) = (x::Int) bar (readMaybe -> Just xs) = sum (xs::[Int]) bar _ = 666 main :: IO () main = do print $ foo "1" -- 1 print $ foo "[1,2,3]" -- 666 -- ??? print $ foo "xxx" -- 666 print $ bar "1" -- 1 print $ bar "[1,2,3]" -- 6 print $ bar "xxx" -- 666 }}} I'm expecting that semantics of the function `foo` would not change if I inline pattern synonym. However it does. `bar` successfully matches string against list of ints, whereas `foo` apperently skips this pattern and fall back to the catch-all case. Reproducible both in GHCi and GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:51:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:51:49 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.5c0df8c01f8855946e6a9493fbd8c3a3@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this looks fishy. Phab:D1622 adds a testcase for this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:52:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:52:05 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.6d0991326618472988894a16fe8fbf80@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: mpickering (added) * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 20:59:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 20:59:44 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.1705ad11129de49d7bccc10cec793add@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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 Richard Eisenberg ): In [changeset:"05fe5463143769a2e84d5e3508a829792d5a1817/ghc" 05fe5463/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="05fe5463143769a2e84d5e3508a829792d5a1817" Test #9632 in dependent/should_compile/T9632 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 21:00:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 21:00:49 -0000 Subject: [GHC] #9632: Promotable type synonyms (or: synonyms to promoted types) In-Reply-To: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> References: <048.8fe52c5c00b593ea5a85c15f59bf61ed@haskell.org> Message-ID: <063.144556a2ebeb0afacb4349da06a0535d@haskell.org> #9632: Promotable type synonyms (or: synonyms to promoted types) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T9632 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => dependent/should_compile/T9632 * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 22:25:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 22:25:31 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.a0183e73cab859f26b31b35a872ce172@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm a bit out of my depth here but an immediate problem is that it's not possible to write down the correct type signature for `PRead`. I think it should be `pattern PRead :: Read a => a -> String` which GHC rejects because the required constraints mention the existentially quantified `a`. It is even more baffling though that with this type signature that GHC still fails to typecheck the code, it only typechecks with the inferred type. I'm doing a bit more investigating now but I think only Richard or Simon will be able to give a better account. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 22:32:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 22:32:06 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.17a5ab2e0aad108a24fecacc49d6a99f@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is the result of the trace statement `tc_patsyn_finish`. {{{ tc_patsyn_finish { PRead (readMaybe -> Just a_aqs) ([a_a2aU[sk]], [Read a_a2aU[sk]], EvBindsVar, [$dRead_a2FA]) ([], [], [], EvBinds{}, []) [(a_aqs, <>)] String }}} which is from {{{ traceTc "tc_patsyn_finish {" $ ppr (unLoc lname) $$ ppr (unLoc lpat') $$ ppr (univ_tvs, req_theta, req_ev_binds, req_dicts) $$ ppr (ex_tvs, subst, prov_theta, prov_ev_binds, prov_dicts) $$ ppr wrapped_args $$ ppr pat_ty }}} So here, the `a` is inferred to be *universally* quantified even though it doesn't appear in the result type. Which explains why adding a type signature which says that `a` is existentially quantified causes the program to fail to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 22:44:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 22:44:12 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.963cfcc238d89e06a21343fae3cd05c4@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think the problem is in this part of `tcTySig` {{{ ; let (_, pat_ty) = tcSplitFunTys ty' univ_set = tyCoVarsOfType pat_ty (univ_tvs, ex_tvs) = partition (`elemVarSet` univ_set) qtvs' }}} Maybe the correct solution is to avoid splitting tyvars into ex/univ at this stage as it's impossible to tell which they are without looking at the pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 22:47:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 22:47:23 -0000 Subject: [GHC] #11225: Unable to provide type signature for pattern synonym Message-ID: <049.425cd27fc02a0721cea74f731d7a6321@haskell.org> #11225: Unable to provide type signature for pattern synonym -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: patsyn/T11224 | Blocked By: Blocking: | Related Tickets: #11224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# language PatternSynonyms , ViewPatterns #-} import Text.Read pattern PRead a <- (readMaybe -> Just a) }}} GHC infers the type correctly for `PRead` but it is impossible provide a signature. See #11224 for more discussion about why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 22:47:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 22:47:56 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.b4d50ba4ea3bdf0805099d49e4a540ed@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11225 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 14 23:46:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Dec 2015 23:46:56 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.5abdca8ce491225e584a4af45faa175c@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #11221: Remove -fwarn-context-quantification In-Reply-To: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> References: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> Message-ID: <061.0b2332f71d41334c0c27df1a7e170030@haskell.org> #11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ddde542dbcb088e0a10aa3cdc3e0aef0a1c4a9b7/ghc" ddde542d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ddde542dbcb088e0a10aa3cdc3e0aef0a1c4a9b7" DynFlags Remove -fwarn-context-quantification flag As mentioned in #4426 these warnings are now errors since the Great Wildcards Refactor of 2015 (1e041b7382b6aa329e4ad9625439f811e0f27232). I've opened #11221 to ensure we remove the last traces of the option in 8.2. Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1615 GHC Trac Issues: #4426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.64e885fe324e6f4030dd9caeabf2cc8d@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 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: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ddde542dbcb088e0a10aa3cdc3e0aef0a1c4a9b7/ghc" ddde542d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ddde542dbcb088e0a10aa3cdc3e0aef0a1c4a9b7" DynFlags Remove -fwarn-context-quantification flag As mentioned in #4426 these warnings are now errors since the Great Wildcards Refactor of 2015 (1e041b7382b6aa329e4ad9625439f811e0f27232). I've opened #11221 to ensure we remove the last traces of the option in 8.2. Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1615 GHC Trac Issues: #4426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X In-Reply-To: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> References: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> Message-ID: <059.a7962a3cb5afcd937fc84ec669819d82@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | 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): Phab:D1607 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6d9c18cb43c1fda95932ef0f640dcf41906a2773/ghc" 6d9c18cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d9c18cb43c1fda95932ef0f640dcf41906a2773" DynFlags: remove Opt_Static There are currently 2 different ways to test for a static or dynamic build: * Test if WayDyn is in ways * Test if Opt_Static is set The problem is that these can easily go out of sync, especially when using the GHC API. This commit replaces all queries of Opt_Static with an equivalent query of WayDyn. This would have prevented bug #8294 and fixes #11154. Reviewers: hvr, austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1607 GHC Trac Issues: #10636 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #11185: runghc can't find ghc-stage2 on a Windows build In-Reply-To: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> References: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> Message-ID: <065.6521bbb8a63d5facdf793d177e89e3a0@haskell.org> #11185: runghc can't find ghc-stage2 on a Windows build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.11 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): Phab:D1621 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"05a5ebed916dc00bc5761224047440fefe10485e/ghc" 05a5ebed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="05a5ebed916dc00bc5761224047440fefe10485e" Fix runghc when $1_$2_SHELL_WRAPPER = NO When that variable isn't on (which is always the case on Windows), `runghc` naively attempts to invoke `ghc` by finding an executable simply named `ghc`. This won't work if `ghc` doesn't exist (e.g., if we're building GHC and using `ghc-stage2` instead). A simple fix is to test for the existence of `ghc` beforehand, and if that fails, fall back on `ghc-stage2`. Fixes #11185. Test Plan: ./validate Reviewers: austin, hvr, thomie, bgamari Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1621 GHC Trac Issues: #11185 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static` In-Reply-To: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> References: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> Message-ID: <060.e62c263282808dbeea9639358425617b@haskell.org> #10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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 Ben Gamari ): In [changeset:"6d9c18cb43c1fda95932ef0f640dcf41906a2773/ghc" 6d9c18cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d9c18cb43c1fda95932ef0f640dcf41906a2773" DynFlags: remove Opt_Static There are currently 2 different ways to test for a static or dynamic build: * Test if WayDyn is in ways * Test if Opt_Static is set The problem is that these can easily go out of sync, especially when using the GHC API. This commit replaces all queries of Opt_Static with an equivalent query of WayDyn. This would have prevented bug #8294 and fixes #11154. Reviewers: hvr, austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1607 GHC Trac Issues: #10636 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:37:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:37:39 -0000 Subject: [GHC] #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld In-Reply-To: <045.23eeb39c8ca5a8c2bf9f89559cb4fa68@haskell.org> References: <045.23eeb39c8ca5a8c2bf9f89559cb4fa68@haskell.org> Message-ID: <060.34861dc5dbfb181525b6e1dbf500bf9a@haskell.org> #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.7 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T7478 Blocked By: | Blocking: Related Tickets: #7478 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6d9c18cb43c1fda95932ef0f640dcf41906a2773/ghc" 6d9c18cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d9c18cb43c1fda95932ef0f640dcf41906a2773" DynFlags: remove Opt_Static There are currently 2 different ways to test for a static or dynamic build: * Test if WayDyn is in ways * Test if Opt_Static is set The problem is that these can easily go out of sync, especially when using the GHC API. This commit replaces all queries of Opt_Static with an equivalent query of WayDyn. This would have prevented bug #8294 and fixes #11154. Reviewers: hvr, austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1607 GHC Trac Issues: #10636 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:39:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:39:39 -0000 Subject: [GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static` In-Reply-To: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> References: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> Message-ID: <060.f0ae18a56c9879cf51b4611407a2af22@haskell.org> #10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:39:59 -0000 Subject: [GHC] #11185: runghc can't find ghc-stage2 on a Windows build In-Reply-To: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> References: <050.530e19a831526298fb2bbf61e8d32e02@haskell.org> Message-ID: <065.05f333e9ebef4e4613948594f272f559@haskell.org> #11185: runghc can't find ghc-stage2 on a Windows build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1621 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:41:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:41:12 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.4f4133fd8a63bd848584ccbea92c59a3@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I've opened #11221 to ensure that the last traces of this flag are removed next release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:43:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:43:28 -0000 Subject: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD In-Reply-To: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> References: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> Message-ID: <062.0808fa92b2139261fa2f3b9361e68a93@haskell.org> #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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 bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: Lowering in priority and bumping to 8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:45:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:45:04 -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.6051802fdfe6787824a35864ee57a894@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: upstream Priority: high | Milestone: 8.2.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: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: infoneeded => upstream * milestone: 8.0.1 => 8.2.1 Comment: Looks like we we can't do much other than wait for the binutils people. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 00:46:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 00:46:50 -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.8016ebc89b3c8336849bac3fa842d7b0@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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 01:16:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 01:16:17 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.cb87c2983714b134e956af40a69cef55@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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 01:33:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 01:33:33 -0000 Subject: [GHC] #11196: TypeInType performance regressions In-Reply-To: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> References: <047.3c2d83be09c012b5e401a7d1fd92ec75@haskell.org> Message-ID: <062.1d1d422b4b993ec17d1e9a94d14f7ac5@haskell.org> #11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Also: {{{ buildtime/make 1222 + 13.67% 1389 seconds }}} Source: https://perf.haskell.org/ghc/#revision/b5d5d83122c93c2a25839127edfd6b2df7ed6928 (if that link doesn't include the commit "Add kind equalities to GHC.", try https://perf.haskell.org/ghc/#revision/6746549772c5cc0ac66c0fce562f297f4d4b80a2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 01:43:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 01:43:38 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.68ac6800966fcfef42ac80beddf511be@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:11 simonpj]: > Can I ask: does `wip/T11067` make it easier? > It's pretty simple: with `UndecidableSuperClasses` the whole superclass restriction is lifted. From reading the notes, that sounds promising (although I think I found an error, will try to comment on that in Phab). I do have a hunch there's a bit of a potential annoyance, though: With something like `UndecidableInstances`, only the module ''declaring'' the instance needs to enable the extension. But the cycle check for superclasses is not locally restricted to the declaration "responsible" for the rule violation. If I'm understanding the notes correctly, if a class requires the extension, then any other class using it as a superclass also will. So a module such as `Data.Constraint.Forall` cannot just ''itself'' use `UndecidableSuperClasses` and thereby free the users from having to mention it. E.g. I suspect users would have to enable the extension explicitly in their own code to use a `ForallV` superclass (because `ForallV` has a type family superclass) or a nested `ForallF` superclass (because that ''would'' recurse on the `ForallF`, although in this case the "blame" might be more shared.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 02:50:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 02:50:16 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.ea87617a9cbeb68efa66e67ee9cd78bd@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: | -------------------------------------+------------------------------------- Comment (by osa1): If we could come up with a nice syntax for function definitions with or- patterns this would be really useful for GHC's own code too. Often we have to re-compile GHC many times and test on some programs to discover all the places we need to update after adding a new data constructor, because of "catch-all" code like this: {{{#!haskell f A = ... f B = ... f unexpected = pprTrace "f" (ppr unexpected) }}} With or patterns, we could do this instead: {{{#!haskell f A = ... f B = ... f unexpected@(C{} | D{} | E{}) = pprTrace "f" (ppr unexpected) }}} (just made up a syntax) This would be very convenient, because now I get a warning after adding data constructor D - instead of discovering this code after a runtime failure. And what happens if I couldn't discover this code because I couldn't come up with an example program that makes GHC run this function? So it's a bit tricky and annoying right now, and it's costing us time because of recompilations and tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 02:57:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 02:57:06 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.2e8bdb85f7698dc06dab57f6a7f3a0e5@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 duairc): Could it not be possible to introduce some way of pattern-matching on {{{GHC.TypeLits}}}'s {{{Nat}}}s independently of generalised injectivity? Maybe it's a question that would involve a lot of bikeshedding... but surely the compiler ultimately has enough information to prove that {{{Replicate}}} is injective, I just can't destructure type-level {{{Nat}}}s. Could there be a magic built-in pattern synonym {{{Succ}}} for {{{Nat}}}s? Can pattern synonyms work on the type level? I don't really know much about the internals to know how to implement that, but there must be a way. Like if full generalised injectivity is just around the corner, then maybe we should just wait for that, but from what I've read it sounds like there are still a lot of kinks that need to be worked out first and it might turn out to be too difficult altogether? Right now pretty much every package that does type-level stuff defines its own {{{Nat}}} type, and I'd imagine the lack of the ability to pattern match on {{{GHC.TypeLits}}}'s {{{Nat}}} is a big part of the reason for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 03:40:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 03:40:30 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.fd37b78d5317c5be4c895a6643ff2a26@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Type-level pattern synonyms would be great. But no one is working on that, I'm afraid. The way that type patterns are implemented now would make this difficult, but I'm planning on refactoring it in the near future (next month, probably). Once that is done, I don't imagine it would be hard to have type-level pattern synonyms. And then we might be able to provide the pattern-matching on `TypeLits` that we all want. I do think that generalized injectivity is the fastest way toward what you want, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 03:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 03:42:39 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.9699d928e2ed3c8938c067e173ef6b24@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: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes yes yes this would be wonderful. Would you like to design and implement it? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 03:44:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 03:44:17 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.df56ae35d75065b5090cbd52d50a7e8a@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g 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 duairc): Sure. I've added one here: https://phabricator.haskell.org/D1626 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 03:54:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 03:54:29 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.f5f272fe990ff911222a755db5b00446@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1626 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 03:56:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 03:56:10 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.9f2570005653c6da3006325d803d9546@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh dear. This example illustrates that I, for one, don't have a grasp on pattern synonym signatures. I had assumed that the universals were precisely those variables mentioned in the result. But that's not true here, because `a` really is a universal, not an existential. So I'm clearly confused. And that sad state of affairs isn't going to be fixed at 11pm at night, so perhaps I'll return to this tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 04:23:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 04:23:15 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.6d01cbabde197e9ea288a40a3eb01948@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: feature request | Status: new 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I've added Joachim's description and an implementation sketch to the original [https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations#Extension:GroomingtheCallStack ImplicitLocations wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 05:48:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 05:48:49 -0000 Subject: [GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind In-Reply-To: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> References: <045.65e5a7ce9685c1ae4f9e878a03f7bb04@haskell.org> Message-ID: <060.597469d310b56ea00ba4d974da668da2@haskell.org> #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 jstolarek): Replying to [comment:6 goldfire]: > I do think that generalized injectivity is the fastest way toward what you want, though. Note however, that generalized injectivity will not make it into 8.0 (unless miracle happens), which means over a year of waiting until it makes it into next stable release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 06:01:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 06:01:01 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.de960ba5086d2e569f8ec7be60c84451@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: msosn Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * owner: => msosn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 06:29:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 06:29:09 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) Message-ID: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 program's performance suffers when compiled with 7.10, compared to 7.8: {{{ main = print $ sum $ map bitcount [0, 4 .. 2^24-1 ] bitcount :: Int -> Int bitcount x = if x > 0 then let (d,m) = divMod x 2 in bitcount d + m else 0 }}} See discussion in this thread: https://mail.haskell.org/pipermail/haskell- cafe/2015-December/122485.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:09:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:09:16 -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.6be4bfb5228c96fb3b72ff21ee2264e3@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: upstream Priority: high | Milestone: 8.2.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): In fact, GHC HEAD with LLVM 3.7 doesn't have this bug and works without any modifications. OTOH, 7.10.x with LLVM 3.5 still doesn't work and requires something like the patch I've put here. Perhaps, we can close this ticket as fixed for GHC 8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:22:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:22:27 -0000 Subject: [GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static` In-Reply-To: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> References: <045.a1abb18f844e8c03a0e9193959190437@haskell.org> Message-ID: <060.81ab5929e1e3160f0a67ea09eac384ec@haskell.org> #10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonmar): > Simon, perhaps you could shed some light why these two exist? I would imagine it is a historical accident but it would be good to know this for certain. I'm pretty sure it's a historical accident -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:39:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:39:04 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.1a0bf5e906b67c2ae66a568a7916eeed@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) Comment: No time to look deeply, but: Does the problem go away if the list is not statically known and thus prevented from floated out, e.g.: {{{#!hs main = print $ foo (2^24-1) foo n = sum $ map bitcount [0, 4 .. n] {-# NOINLINE foo #-} bitcount :: Int -> Int bitcount x = if x > 0 then let (d,m) = divMod x 2 in bitcount d + m else 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:42:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:42:25 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.93101b8d14040d011c27e22d7f251bb5@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: nomeata (removed) Comment: @nomeata: no, does not go away -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:43:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:43:09 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.23e2862faf87f274d41a8875395c5713@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): I found that this works fine with 7.10: {{{ main = print $ sum $ map bitcount $ takeWhile (< 2^24) [0, 4 .. ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 08:51:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 08:51:38 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.20db179c763f4d80ab76686f3a797644@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 09:40:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 09:40:51 -0000 Subject: [GHC] #11227: Interaction between ORF and record pattern synonyms needs to be resolved. Message-ID: <049.cfd6fb61faaf681c28544a5bb3e31ee1@haskell.org> #11227: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, orf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 09:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 09:41:01 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. Message-ID: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, orf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:01:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:01:33 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.90054140b263534c95ec5b86ccd2a93d@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): possibly related: https://ghc.haskell.org/trac/ghc/ticket/10992 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:11:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:11:02 -0000 Subject: [GHC] #11227: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.cfd6fb61faaf681c28544a5bb3e31ee1@haskell.org> References: <049.cfd6fb61faaf681c28544a5bb3e31ee1@haskell.org> Message-ID: <064.7ea3942ce97ce55ca5b6b74e835bee14@haskell.org> #11227: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: | PatternSynonyms, orf 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: => invalid Comment: Closing in favor of #11228, which is identical to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:11:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:11:21 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.0412218989beb543d3a949e479b2b475@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf 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: 7.10.3 => 7.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:11:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:11:26 -0000 Subject: [GHC] #11226: Performance regression (involving sum, map, enumFromThenTo) In-Reply-To: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> References: <049.6309da9f9961e93d429b3ce9d614401e@haskell.org> Message-ID: <064.f2f2a1425acf2a2bf97261d8d08108b4@haskell.org> #11226: Performance regression (involving sum, map, enumFromThenTo) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:31:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:31:51 -0000 Subject: [GHC] #11154: Problems using GHC-API on MacOS X In-Reply-To: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> References: <044.f71ce763d307a64989a408aa09bf11b6@haskell.org> Message-ID: <059.4cf83e4d29a8b2f7fbcec0b83a3b9da2@haskell.org> #11154: Problems using GHC-API on MacOS X -------------------------------------+------------------------------------- Reporter: svenk | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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): Phab:D1607 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This is fixed in GHC 8 with the above patch. No need to call `updateWays` explicitly. Since you mention `ghc -dynamic test.hs` already worked, I'm closing this ticket. Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 10:46:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 10:46:03 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.197b558862ac518b27dd40878fea0e8e@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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): I'd say at a minimum we should translate CRLF to LF on Windows. I'm surprised the underlying file IO doesn't do this already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 11:03:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 11:03:59 -0000 Subject: [GHC] #10812: High memory usage after performing GC In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.195cb73ff7768a6f98dd6b7b1600c247@haskell.org> #10812: High memory usage after performing GC ---------------------------------+-------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by kazu-yamamoto): Even on Linux, I saw: https://github.com/yesodweb/wai/issues/488 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 11:12:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 11:12:35 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.1f3cc2009d45ec8738f835b352920153@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8424 Comment: #8424 is related (or duplicate?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 11:46:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 11:46:32 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.a57fd138a28d4cf09d32f7ca9e765859@haskell.org> #8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11215 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gintas (removed) * related: => #11215 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 11:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 11:48:01 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.e48957944ffd6119e443aa50dd260a40@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Yes, #8424 seems to be the same issue. Another example of this behaviour causing problems in real code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 11:57:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 11:57:59 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.8cb5729510953377006120b6ddf23513@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems like this might be worth trying to fix for 8.0. > Perhaps I'm being dense, but why is this problematic? What panic or other undesirable situation will arise? To be clear: I'm proposing to keep `TyCon` and `Module` and such in `GHC.Types`. But also to put the representations for things defined in `GHC.Types` in `GHC.Types`. I can't think of any reason why this should be tricky. Simon, perhaps you could elaborate on the reasons for this being so tricky? > But isn't the fingerprint Very Important? As in: don't we rely critically on fingerprints being unique when doing type comparison? If I understand this correctly, the current implementation means that `-dsuppress-uniques` makes the whole Typeable story unsound. And `-dsuppress-uniques` is meant to be a pretty-printing flag. Indeed this is quite an unexpected effect for what ought to be a debugging flag. I've opened Phab:D1629 replacing the bogus fingerprint logic with a testsuite normaliser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 12:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 12:56:15 -0000 Subject: [GHC] #9996: Support symbols in GHCi tab completion In-Reply-To: <046.22bb07e462ddbba0f2716d525f66f3af@haskell.org> References: <046.22bb07e462ddbba0f2716d525f66f3af@haskell.org> Message-ID: <061.c457ef56285fffded084773b4599ecf4@haskell.org> #9996: Support symbols in GHCi tab completion -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10576 Comment: Geraldus is working on this in #10576. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:04:30 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.45819436c8c77c3bf9efc8598c381c09@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | 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 thomie): * priority: normal => low * failure: GHC rejects valid program => Incorrect warning at compile-time * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:07:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:07:26 -0000 Subject: [GHC] #9974: Allow more general structural recursion without UndecidableInstances In-Reply-To: <045.b388614289e2dfd61f708eef2be07eb0@haskell.org> References: <045.b388614289e2dfd61f708eef2be07eb0@haskell.org> Message-ID: <060.865123348131b3e219b40712d8e58547@haskell.org> #9974: Allow more general structural recursion without UndecidableInstances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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: | -------------------------------------+------------------------------------- Old description: > I bet this is a duplicate, but I couldn't find it. > > A simple example from the `HList` package: > > {{{#!hs > type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k] > type instance HRevApp '[] l = l > type instance HRevApp (e ': l) l' = HRevApp l (e ': l') > }}} > > GHC 7.8.3 and 7.11 both complain about the second instance if > `UndecidableInstances` is turned off, because the application is no > smaller than the index head. Moreover, the same error occurs when the > type family is closed. However, GHC already knows how to separate term- > level definitions into recursive groups; applying this same analysis to > the type family above would reveal that `HRevApp` is structurally > recursive, and therefore decidable. It is key, in this case, that the > instance for `[]` is visible from the instance declaration for `e ': l`, > so such an analysis could only be done in module dependency order for > open type families. > > Side note: there is a (nasty) workaround available for the problem in > this case: > > {{{#!hs > type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k] > type instance HRevApp' t '[] l = l > type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'') > > type HRevApp l1 l2 = HRevApp' l1 l1 l2 > }}} New description: I bet this is a duplicate, but I couldn't find it. A simple example from the `HList` package: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, TypeOperators, TypeFamilies #-} type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k] type instance HRevApp '[] l = l type instance HRevApp (e ': l) l' = HRevApp l (e ': l') }}} GHC 7.8.3 and 7.11 both complain about the second instance if `UndecidableInstances` is turned off, because the application is no smaller than the index head. Moreover, the same error occurs when the type family is closed. However, GHC already knows how to separate term-level definitions into recursive groups; applying this same analysis to the type family above would reveal that `HRevApp` is structurally recursive, and therefore decidable. It is key, in this case, that the instance for `[]` is visible from the instance declaration for `e ': l`, so such an analysis could only be done in module dependency order for open type families. Side note: there is a (nasty) workaround available for the problem in this case: {{{#!hs type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k] type instance HRevApp' t '[] l = l type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'') type HRevApp l1 l2 = HRevApp' l1 l1 l2 }}} -- Comment (by thomie): Added language pragma to example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:09:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:09:05 -0000 Subject: [GHC] #11229: splitLHsForAllTy not exported from HsTypes Message-ID: <046.624b073c8cd31d66a3833165e0389f8f@haskell.org> #11229: splitLHsForAllTy not exported from HsTypes -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 7.10.3 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 if one wants to get the contextless instance declaration type, needs to call splitLHsInstDeclTy_maybe, then undo some of the splitting it did. If splitLHsForAllTy were exported, it could be used directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:10:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:10:20 -0000 Subject: [GHC] #9952: Add -g In-Reply-To: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> References: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> Message-ID: <059.8a335670726a6b1d77cff8a3f0eb03ea@haskell.org> #9952: Add -g -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 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 thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This is done I think. Please reopen if I misunderstood. commit 7aaeaf81ea95c36fe1dc4da449cf6092a792fd09: {{{ Author: Ben Gamari Date: Fri Sep 25 18:00:19 2015 +0200 Support multiple debug output levels We now only strip block information from DebugBlocks when compiling with `-g1`, intended to be used when only minimal debug information is desired. `-g2` is assumed when `-g` is passed without any integer argument. Differential Revision: https://phabricator.haskell.org/D1281 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:22:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:22:09 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.760f489f1b14a6e9781a01fff746ae73@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: For a newcomer: the description basically tells you what to do. So this is more an exercise in getting to know the GHC patch submission process. Don't forget an explanation, as mentioned in comment:7. And a test, see [wiki:Building/RunningTests/Adding] (or look at some examples in `libraries/base/tests`). Read [wiki:WorkingConventions/FixingBugs] and submit a patch to [wiki:Phabricator]. Good luck! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:29:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:29:55 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.8ce931463c24834b550cab9dce15b9aa@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK good. I think I'll commit as-is (time is pressing), and leave a potential relaxation along the lines of comment:13 for later. By all means make a concrete proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:39:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:39:55 -0000 Subject: [GHC] #11193: Strict extension does not make monadic bindings strict In-Reply-To: <051.563028756f74e7233040685912e51248@haskell.org> References: <051.563028756f74e7233040685912e51248@haskell.org> Message-ID: <066.0e401bf478e5707afc06ab4babd1c3f3@haskell.org> #11193: Strict extension does not make monadic bindings strict -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: adamse Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_run/T11193 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1612 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deSugar/should_run/T11193 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 13:41:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 13:41:34 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.e697ef062676720fb2ada5a779c622b6@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | 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:D1617 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Done. Thanks for doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:14:03 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.07213290356b9e767c6378d1a9139c5a@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. So here's my current stream of thought: * The universals are those variables that appear in either the result or in the required context. Except that's not quite right in pathological cases, like this: {{{ data Ex = forall a. Ex a magic :: Ex -> a magic _ = undefined pattern Silly x <- (magic -> x) }}} As I understand it, the signature for `Silly` should be {{{ pattern type Silly :: a -> Ex }}} Here, `a` is universal. But `a` is mentioned neither in the result nor in the required context. Compare to {{{ pattern type Sensible :: a -> Ex pattern Sensible x = Ex x }}} Here, `a` is existential. But the pattern signature is otherwise identical! So we can't infer the universal/existential decision from the signature. I thus propose the following revision to pattern signatures: * Allow explicit quantification in two places, according to this schema: {{{ pattern type Syn :: forall <>. <> => forall <>. <> => <> -> <> }}} * In the absence of explicit quantification, universals are inferred to be the variables mentioned in either the result or the required context. Existentials are the remaining variables. * It is against the rules for existentials to shadow universals. According to these rules, the signature given for `Silly` above would be rejected, as `a` is inferred to be existential, but in the pattern synonym, it really is universal. Instead, the user would have to write {{{ pattern type Silly :: forall a. a -> Ex }}} What's terribly unfortunate here is that this new, revised signature for `Silly` seems to add simply a redundant `forall`... the sort of thing Haskell infers all the time. Except here it says "`a` is universal". Contrast to the explicit form of `Sensible`'s signature: {{{ pattern type Sensible :: () => forall a. a -> Ex }}} which is quite ugly. This all makes me want the incredibly verbose syntax in comment:5:ticket:10928, repeated here for convenience: {{{ pattern type P :: { universals = ... , existentials = ... , provided = ... , required = ... , arguments = ... , result = ... } }}} A worked out example appears in that comment. We would allow a short-hand in common cases (yet to be worked out). This syntax is annoying to write, but surely a pleasure to read. And it reminds readers that the thing to the right of `pattern type Blah ::` is '''not''' a type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:15:05 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.8b898d33e06f73a45ec1deb32073a207@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => highest Comment: Bumping priority as whatever our decision is, we should make it and implement it soon, as it will likely not be fully backward compatible, and I don't want this sand shifting between 7.10 and 8.0 and then again between 8.0 and 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:22:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:22:31 -0000 Subject: [GHC] #11147: GHC 7.10.3 does not compile on NixOS (was: Linker errors related to response files change) In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.a0082070d019caad226ff185e3ca9bb2@haskell.org> #11147: GHC 7.10.3 does not compile on NixOS ----------------------------------------+---------------------------------- Reporter: waern | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by simons): * version: 7.11 => 7.10.3 Old description: > Hi, > > Building GHC HEAD in Nix on Linux currently fails with linker errors. See > https://github.com/NixOS/nixpkgs/issues/10752 > > The problem goes away if one reverts GHC commit > 296bc70b5ff6c853f2782e9ec5aa47a52110345e. > > I don't know what the issue is, and I can't be 100% sure it's really a > GHC problem and not a Nix one, but I thought it best to record this here. New description: Building GHC 7.10.3 in Nix on Linux currently fails with linker errors. https://github.com/NixOS/nixpkgs/issues/10752 has further details. The problem goes away if one reverts GHC commit 296bc70b5ff6c853f2782e9ec5aa47a52110345e. I don't know what the issue is, and I can't be 100% sure it's really a GHC problem and not a Nix one, but I thought it best to record this here. -- Comment: It seems like ./configure detects the presence of librt, so features that depend on it are enabled, but the library is never actually linked. This issue is rather serious for us, because it prevents us from updating to GHC 7.10.3 on NixOS, i.e. we can no longer support upcoming versions of LTS Haskell without a fix for this problem. Any suggestions how to fix or work aroung this phenomenon are very welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:25:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:25:57 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.d72a828d6fe7a7900a66dfe8b59e758f@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): That sounds right Richard but there is also another bug here that inlining the synonym changes the semantics. That shouldn't get lost either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:29:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:29:06 -0000 Subject: [GHC] #9931: Option to truncate Show output in ghci REPL In-Reply-To: <046.6d68de86d6a269e0a0cd4e73235bebfc@haskell.org> References: <046.6d68de86d6a269e0a0cd4e73235bebfc@haskell.org> Message-ID: <061.df4609fbf94bd2e97e23ba161bcf1014@haskell.org> #9931: Option to truncate Show output in ghci REPL -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 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 thomie): * component: Compiler => GHCi Comment: What is the use case? Printing infinite data structures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:30:04 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays In-Reply-To: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> References: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> Message-ID: <060.33256f1818eac88ebb0a25ff324535f1@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 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 thomie): * owner: simonmar => * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:33:34 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.8063b611db16d583fc794e778e94aa90@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6eabb6ddb7c53784792ee26b1e0657bde7eee7fb/ghc" 6eabb6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eabb6ddb7c53784792ee26b1e0657bde7eee7fb" Allow recursive (undecidable) superclasses This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It?s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:33:34 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.8b3a39801bc32fac6a0ea906746b5c31@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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 Simon Peyton Jones ): In [changeset:"6eabb6ddb7c53784792ee26b1e0657bde7eee7fb/ghc" 6eabb6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eabb6ddb7c53784792ee26b1e0657bde7eee7fb" Allow recursive (undecidable) superclasses This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It?s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:33:34 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.1cc0ce6da05dc8282b040559307ccfab@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6eabb6ddb7c53784792ee26b1e0657bde7eee7fb/ghc" 6eabb6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eabb6ddb7c53784792ee26b1e0657bde7eee7fb" Allow recursive (undecidable) superclasses This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It?s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:33:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:33:57 -0000 Subject: [GHC] #9911: Pattern synonyms with no signatures should yield warnings In-Reply-To: <045.fb316f949e47be5eb8be009f5ae43102@haskell.org> References: <045.fb316f949e47be5eb8be009f5ae43102@haskell.org> Message-ID: <060.0be05d36513bd248dbf691d9a7f6d37f@haskell.org> #9911: Pattern synonyms with no signatures should yield warnings -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: duplicate | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11053 Comment: commit 1883afb2eee88c828adf6aa8014bab64dd6e8096 {{{ Author: Matthew Pickering Date: Sat Dec 12 16:38:07 2015 +0000 Implement -fwarn-missing-pat-syn-sigs This adds a warning when a pattern synonym is not accompanied by a signature in the style of `-fwarn-missing-sigs`. It is turned on by -Wall. If the user specifies, `-fwarn-missing-exported-signatures` with `-fwarn-missing-pat-syn-sigs` then it will only warn when the pattern synonym is exported. Test Plan: ./validate Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1596 GHC Trac Issues: #11053 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:37:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:37:23 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB In-Reply-To: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> References: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> Message-ID: <059.cbd89b5aec0ee68587993e2d4c0a42db@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ---------------------------------+-------------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10601 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10601 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:38:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:38:08 -0000 Subject: [GHC] #10601: GHC should be distributed with debug symbols In-Reply-To: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> References: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> Message-ID: <061.e9e700d551521de70abbdcfb60d4a10c@haskell.org> #10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9894 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:39:43 -0000 Subject: [GHC] #9887: No message when GCHI reusing compiled code In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.7177d209c7eab9085f3b8fc1f3c77131@haskell.org> #9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer 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 thomie): * keywords: => newcomer Comment: That shouldn't be too hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:45:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:45:08 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.f37985fdd98a6315276b704dbf4f1233@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is the situation on this ticket? Should it be on the list at [wiki:DependentTypes/Phase1]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:45:55 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.0b12fe1a9870f767f502997c49103fd6@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 14:57:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 14:57:39 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position Message-ID: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: deferred, | Operating System: Unknown/Multiple roles | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code: {{{#!hs {-# LANGUAGE RoleAnnotations #-} {-# OPTIONS_GHC -fdefer-type-errors #-} import Control.Exception newtype Representational a = Representational () type role Representational representational newtype Phantom a = Phantom () type role Phantom phantom testRepresentational :: Representational Char -> Representational Bool testRepresentational = id {-# NOINLINE testRepresentational #-} testPhantom :: Phantom Char -> Phantom Bool testPhantom = id {-# NOINLINE testPhantom #-} throwsException :: String -> a -> IO () throwsException c v = do result <- try (evaluate v) case result of Right _ -> error (c ++ " (Failure): No exception!") -- #if MIN_VERSION_base(4,9,0) Left (TypeError msg) -> putStrLn (c ++ "(Succes): exception found") -- #else -- Left (ErrorCall _) -> putStrLn "Succes: exception found" -- #endif main = do throwsException "representational" testRepresentational throwsException "phantom" testPhantom }}} Produces the following result in HEAD: {{{ representational(Succes): exception found *** Exception: phantom (Failure): No exception! CallStack (from ImplicitParams): error, called at Main.hs:24:16 in main:Main }}} In 7.10.2 (after commenting the `TypeError` line, and uncommenting the `ErrorCall` line), we get the following output: {{{ Succes: exception found Succes: exception found }}} I think the HEAD result is wrong: deferred type errors should always result in a run-time exception when their associated value is evaluated, regardless of whether the error occurred in a phantom role position or not. Looking at the core (`ghc -O0 -ddump-simpl`) in HEAD is see: {{{ -- RHS size: {terms: 3, types: 15, coercions: 0} testRepresentational_rqP :: Representational Char -> Representational Bool [GblId, Str=DmdType b] testRepresentational_rqP = case typeError @ 'Unlifted @ (Char ~# Bool) "Main.hs:13:24: error:\n\ \ \\226\\128\\162 Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Representational Char -> Representational Bool\n\ \ Actual type: Representational Bool -> Representational Bool\n\ \ \\226\\128\\162 In the expression: id\n\ \ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\ \ testRepresentational = id\n\ \(deferred type error)"# of wild0_00 { } -- RHS size: {terms: 1, types: 2, coercions: 10} testPhantom_rqQ :: Phantom Char -> Phantom Bool [GblId, Str=DmdType] testPhantom_rqQ = (id @ (Phantom Bool)) `cast` ((Phantom _P{<*>_N})_R -> _R :: (Phantom Bool -> Phantom Bool) ~R# (Phantom Char -> Phantom Bool)) }}} while in 7.10.2 I see: {{{ testRepresentational_rnc :: Representational Char -> Representational Bool [GblId, Str=DmdType b] testRepresentational_rnc = case Control.Exception.Base.runtimeError @ (Char ~ Bool) "Main.hs:13:24:\n\ \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Representational Char -> Representational Bool\n\ \ Actual type: Representational Bool -> Representational Bool\n\ \ In the expression: id\n\ \ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\ \ testRepresentational = id\n\ \(deferred type error)"# of wild_00 { } testPhantom_rnd :: Phantom Char -> Phantom Bool [GblId, Str=DmdType b] testPhantom_rnd = case Control.Exception.Base.runtimeError @ (Char ~ Bool) "Main.hs:17:15:\n\ \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Phantom Char -> Phantom Bool\n\ \ Actual type: Phantom Bool -> Phantom Bool\n\ \ In the expression: id\n\ \ In an equation for \\226\\128\\152testPhantom\\226\\128\\153: testPhantom = id\n\ \(deferred type error)"# of wild_00 { } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:01:05 -0000 Subject: [GHC] #9877: ForeignImport coercion evaluated before typechecking In-Reply-To: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> References: <045.98c4bf8afa11b5771190e9909bffe695@haskell.org> Message-ID: <060.f2bb40ad6ffec89d9797cc6c93c17981@haskell.org> #9877: ForeignImport coercion evaluated before typechecking -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | 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 thomie): * status: new => infoneeded * component: Compiler => GHC API * related: => #8588 Comment: > When I build it directly from Cabal it does not crash. So this is most likely a bug in the GHC API. Perhaps Windows only. Perhaps already fixed, but we can't be sure without a way to reproduce (without relying on Eclipse FP or BuildWrapper). As mentioned by the BuildWrapper author in https://github.com/JPMoresmau/BuildWrapper/issues/49#issuecomment-67013339: What you should do is try to narrow the bug down by writing directly the GHC code. In https://ghc.haskell.org/trac/ghc/ticket/9845#no1 you can see I did that to expose another bug. The code buildwrapper used to invoke GHC is in the GHC module. Also note that the BuildWrapper Github page currently says: BuildWrapper is currently NOT maintained anymore. Feel free to fork and take up maintainership! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:01:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:01:42 -0000 Subject: [GHC] #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers In-Reply-To: <049.3ecf497466e0b6871bd293a116f06c8c@haskell.org> References: <049.3ecf497466e0b6871bd293a116f06c8c@haskell.org> Message-ID: <064.3696cd74d0ee6283dbdab97d97d6ba15@haskell.org> #7621: Cross-build for QNX ARM smashes stack when using FunPtr wrappers -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: ? Component: Compiler (FFI) | Version: 7.7 Resolution: | Keywords: qnx | unregisterised cross-compile Operating System: QNX | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 7610 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => ? Comment: This seems to have lost momentum. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:01:58 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.33dcb2cce365baabc0d927160281c730@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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 darchon: Old description: > The following code: > > {{{#!hs > {-# LANGUAGE RoleAnnotations #-} > {-# OPTIONS_GHC -fdefer-type-errors #-} > > import Control.Exception > > newtype Representational a = Representational () > type role Representational representational > > newtype Phantom a = Phantom () > type role Phantom phantom > > testRepresentational :: Representational Char -> Representational Bool > testRepresentational = id > {-# NOINLINE testRepresentational #-} > > testPhantom :: Phantom Char -> Phantom Bool > testPhantom = id > {-# NOINLINE testPhantom #-} > > throwsException :: String -> a -> IO () > throwsException c v = do > result <- try (evaluate v) > case result of > Right _ -> error (c ++ " (Failure): No exception!") > -- #if MIN_VERSION_base(4,9,0) > Left (TypeError msg) -> putStrLn (c ++ "(Succes): exception found") > -- #else > -- Left (ErrorCall _) -> putStrLn "Succes: exception found" > -- #endif > > main = do > throwsException "representational" testRepresentational > throwsException "phantom" testPhantom > }}} > > Produces the following result in HEAD: > > {{{ > representational(Succes): exception found > *** Exception: phantom (Failure): No exception! > CallStack (from ImplicitParams): > error, called at Main.hs:24:16 in main:Main > }}} > > In 7.10.2 (after commenting the `TypeError` line, and uncommenting the > `ErrorCall` line), we get the following output: > > {{{ > Succes: exception found > Succes: exception found > }}} > > I think the HEAD result is wrong: deferred type errors should always > result in a run-time exception when their associated value is evaluated, > regardless of whether the error occurred in a phantom role position or > not. > > Looking at the core (`ghc -O0 -ddump-simpl`) in HEAD is see: > > {{{ > -- RHS size: {terms: 3, types: 15, coercions: 0} > testRepresentational_rqP > :: Representational Char -> Representational Bool > [GblId, Str=DmdType b] > testRepresentational_rqP = > case typeError > @ 'Unlifted > @ (Char ~# Bool) > "Main.hs:13:24: error:\n\ > \ \\226\\128\\162 Couldn't match type > \\226\\128\\152Char\\226\\128\\153 with > \\226\\128\\152Bool\\226\\128\\153\n\ > \ Expected type: Representational Char -> Representational > Bool\n\ > \ Actual type: Representational Bool -> Representational > Bool\n\ > \ \\226\\128\\162 In the expression: id\n\ > \ In an equation for > \\226\\128\\152testRepresentational\\226\\128\\153:\n\ > \ testRepresentational = id\n\ > \(deferred type error)"# > of wild0_00 { > } > > -- RHS size: {terms: 1, types: 2, coercions: 10} > testPhantom_rqQ :: Phantom Char -> Phantom Bool > [GblId, Str=DmdType] > testPhantom_rqQ = > (id @ (Phantom Bool)) > `cast` ((Phantom _P{<*>_N})_R -> _R > :: (Phantom Bool -> Phantom Bool) > ~R# (Phantom Char -> Phantom Bool)) > }}} > > while in 7.10.2 I see: > > {{{ > testRepresentational_rnc > :: Representational Char -> Representational Bool > [GblId, Str=DmdType b] > testRepresentational_rnc = > case Control.Exception.Base.runtimeError > @ (Char ~ Bool) > "Main.hs:13:24:\n\ > \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with > \\226\\128\\152Bool\\226\\128\\153\n\ > \ Expected type: Representational Char -> Representational > Bool\n\ > \ Actual type: Representational Bool -> Representational > Bool\n\ > \ In the expression: id\n\ > \ In an equation for > \\226\\128\\152testRepresentational\\226\\128\\153:\n\ > \ testRepresentational = id\n\ > \(deferred type error)"# > of wild_00 { > } > > testPhantom_rnd :: Phantom Char -> Phantom Bool > [GblId, Str=DmdType b] > testPhantom_rnd = > case Control.Exception.Base.runtimeError > @ (Char ~ Bool) > "Main.hs:17:15:\n\ > \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with > \\226\\128\\152Bool\\226\\128\\153\n\ > \ Expected type: Phantom Char -> Phantom Bool\n\ > \ Actual type: Phantom Bool -> Phantom Bool\n\ > \ In the expression: id\n\ > \ In an equation for > \\226\\128\\152testPhantom\\226\\128\\153: testPhantom = id\n\ > \(deferred type error)"# > of wild_00 { > } > }}} New description: The following code: {{{#!hs {-# LANGUAGE RoleAnnotations #-} {-# OPTIONS_GHC -fdefer-type-errors #-} import Control.Exception newtype Representational a = Representational () type role Representational representational newtype Phantom a = Phantom () type role Phantom phantom testRepresentational :: Representational Char -> Representational Bool testRepresentational = id {-# NOINLINE testRepresentational #-} testPhantom :: Phantom Char -> Phantom Bool testPhantom = id {-# NOINLINE testPhantom #-} throwsException :: String -> a -> IO () throwsException c v = do result <- try (evaluate v) case result of Right _ -> error (c ++ " (Failure): No exception!") -- #if MIN_VERSION_base(4,9,0) Left (TypeError _) -> putStrLn (c ++ "(Succes): exception found") -- #else -- Left (ErrorCall _) -> putStrLn (c ++ " (Succes): exception found") -- #endif main = do throwsException "representational" testRepresentational throwsException "phantom" testPhantom }}} Produces the following result in HEAD: {{{ representational(Succes): exception found *** Exception: phantom (Failure): No exception! CallStack (from ImplicitParams): error, called at Main.hs:24:16 in main:Main }}} In 7.10.2 (after commenting the `TypeError` line, and uncommenting the `ErrorCall` line), we get the following output: {{{ representational (Succes): exception found phantom (Succes): exception found }}} I think the HEAD result is wrong: deferred type errors should always result in a run-time exception when their associated value is evaluated, regardless of whether the error occurred in a phantom role position or not. Looking at the core (`ghc -O0 -ddump-simpl`) in HEAD is see: {{{ -- RHS size: {terms: 3, types: 15, coercions: 0} testRepresentational_rqP :: Representational Char -> Representational Bool [GblId, Str=DmdType b] testRepresentational_rqP = case typeError @ 'Unlifted @ (Char ~# Bool) "Main.hs:13:24: error:\n\ \ \\226\\128\\162 Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Representational Char -> Representational Bool\n\ \ Actual type: Representational Bool -> Representational Bool\n\ \ \\226\\128\\162 In the expression: id\n\ \ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\ \ testRepresentational = id\n\ \(deferred type error)"# of wild0_00 { } -- RHS size: {terms: 1, types: 2, coercions: 10} testPhantom_rqQ :: Phantom Char -> Phantom Bool [GblId, Str=DmdType] testPhantom_rqQ = (id @ (Phantom Bool)) `cast` ((Phantom _P{<*>_N})_R -> _R :: (Phantom Bool -> Phantom Bool) ~R# (Phantom Char -> Phantom Bool)) }}} while in 7.10.2 I see: {{{ testRepresentational_rnc :: Representational Char -> Representational Bool [GblId, Str=DmdType b] testRepresentational_rnc = case Control.Exception.Base.runtimeError @ (Char ~ Bool) "Main.hs:13:24:\n\ \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Representational Char -> Representational Bool\n\ \ Actual type: Representational Bool -> Representational Bool\n\ \ In the expression: id\n\ \ In an equation for \\226\\128\\152testRepresentational\\226\\128\\153:\n\ \ testRepresentational = id\n\ \(deferred type error)"# of wild_00 { } testPhantom_rnd :: Phantom Char -> Phantom Bool [GblId, Str=DmdType b] testPhantom_rnd = case Control.Exception.Base.runtimeError @ (Char ~ Bool) "Main.hs:17:15:\n\ \ Couldn't match type \\226\\128\\152Char\\226\\128\\153 with \\226\\128\\152Bool\\226\\128\\153\n\ \ Expected type: Phantom Char -> Phantom Bool\n\ \ Actual type: Phantom Bool -> Phantom Bool\n\ \ In the expression: id\n\ \ In an equation for \\226\\128\\152testPhantom\\226\\128\\153: testPhantom = id\n\ \(deferred type error)"# of wild_00 { } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:04:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:04:43 -0000 Subject: [GHC] #9865: Comonads in base library In-Reply-To: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> References: <050.1aeed8f93bd414fa38dcb5213e8076cb@haskell.org> Message-ID: <065.e6ffc0fe0e4e163c1b457fc8f8fbe33a@haskell.org> #9865: Comonads in base library -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 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 thomie): * status: new => closed * resolution: => invalid Comment: Please submit a libraries proposal first, as mentioned in comment:1, and then reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:07:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:07:09 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.8eadacf072b11c6a0578e7c0cdc10015@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, but test `deriving/should_compile/T10561` still fails: {{{ newtype Compose f g a = Compose (f (g a)) deriving Functor }}} (with `-XPolyKinds`) produces {{{ T10561.hs:10:52: error: ? Couldn't match kind ?k? with ?*? arising from the first field of ?Compose? (type ?f (g a)?) ? When deriving the instance for (Functor (Compose f g)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:08:30 -0000 Subject: [GHC] #9862: defined but not used errors on Solaris/SPARC In-Reply-To: <045.7d63ce3f461ee96da7f3904fb48b75b1@haskell.org> References: <045.7d63ce3f461ee96da7f3904fb48b75b1@haskell.org> Message-ID: <060.7fedac2dbfaa214caa326904aee87768@haskell.org> #9862: defined but not used errors on Solaris/SPARC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix * milestone: => 8.0.1 Comment: Warnings during the stage1 build aren't treated as errors anymore (31bcf9b62ceaed98bdd3b7605e68d315bcff0c8a). Hopefully nobody complains if I close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:10:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:10:54 -0000 Subject: [GHC] #9846: GHC --make should also look for .hi, not only for .hs In-Reply-To: <045.3794dccbd8106489034cfa5bf262c765@haskell.org> References: <045.3794dccbd8106489034cfa5bf262c765@haskell.org> Message-ID: <060.ff77bbb15f2d7b7890e5bb4802ef4a9f@haskell.org> #9846: GHC --make should also look for .hi, not only for .hs -------------------------------------+------------------------------------- Reporter: larsrh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | 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 thomie): * component: Compiler => Driver * milestone: ? => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:11:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:11:43 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.2574af77c73a4a16c169e3a7e0163f1d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The issue came up in [http://www.haskell.org/pipermail/glasgow-haskell- > users/2012-November/023027.html this thread on glasgow-haskell-users]. > > == Steps to reproduce: == > > {{{ > -- file Foo.hs > import Control.Exception > import Control.DeepSeq > main = evaluate (('a' : undefined) `deepseq` return () :: IO ()) > }}} > {{{ > $ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs > }}} > > === Expected result: === > The program should fail with: > {{{ > Foo: Prelude.undefined > }}} > > === Actual result: === > > The program succeeds. > > Compiling the program with {{{-fno-state-hack}}} helps. New description: The issue came up in [http://www.haskell.org/pipermail/glasgow-haskell- users/2012-November/023027.html this thread on glasgow-haskell-users]. == Steps to reproduce: == {{{#!hs -- file Foo.hs import Control.Exception import Control.DeepSeq main = evaluate (('a' : undefined) `deepseq` return () :: IO ()) }}} {{{ $ ghc -fforce-recomp -fpedantic-bottoms -O Foo.hs }}} === Expected result: === The program should fail with: {{{ Foo: Prelude.undefined }}} === Actual result: === The program succeeds. Compiling the program with {{{-fno-state-hack}}} helps. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:15:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:15:40 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.9c29b24e92397700dfcf718447b48bf6@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The runtime linker seems to be re-exporting some of the symbols of > `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very > small subset of symbols are re-exporting. > > If a symbol is needed that isn't re-exported (e.g. `log1p`) then this > code can't be run in GHCi because it will result in a duplicate symbols > error. > > A workaround > > The `rts` seems to be a special case again. The linker seems to ignore > the `extra-libraries` from the `package.conf`, which explains why you can > put anything you want in there and it'll still compile. > > {{{ > 128 emptyPLS :: DynFlags -> PersistentLinkerState > 129 emptyPLS _ = PersistentLinkerState { > 130 closure_env = emptyNameEnv, > 131 itbl_env = emptyNameEnv, > 132 pkgs_loaded = init_pkgs, > 133 bcos_loaded = [], > 134 objs_loaded = [], > 135 temp_sos = [] } > 136 > > 137 -- Packages that don't need loading, because the compiler > 138 -- shares them with the interpreted program. > 139 -- > 140 -- The linker's symbol table is populated with RTS symbols using an > 141 -- explicit list. See rts/Linker.c for details. > 142 where init_pkgs = [rtsUnitId] > }}} > > I've tried 2 approaches which haven't worked completely: > > 1. I tried removing the symbols from the export list and adding > `libmingwex` to the rts's `package.conf`and have it just link against it. > But turns out the `rts`'s `package.conf` is ignored on all platforms. I > didn't want to have to make an exception for Windows here and I don't > know why the other platforms also ignore it so I abandoned this approach. > > 2. I tried marking the symbols we're re-exporting as weak symbols, so > there wouldn't be a change to existing code and would allow you to link > against `libmingwex`. But unfortunately because of when the other > libraries specified by `-l` are linked in, some of the symbols have > already been used and thus aren't weak anymore. So I still get duplicate > link errors. > > What I want to try now is leaving them as weak symbols, but loading > `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is > loaded. This is hopefully early enough that the symbols haven't been used > yet. > > Example (LogFloat.hs file): > > {{{#!hs > module Main (main) where > > import Data.Number.LogFloat (log1p) > > main :: IO () > main = print $ log1p 1.0 > }}} > > `runGhc LogFloat.hs` will fail: > {{{ > Loading package logfloat-0.13.3.3 ... > linking ... > LogFloat.hs: ...\x86_64-windows- > ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: > unknown symbol `log1p' > > LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3' > }}} New description: The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting. If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error. === A workaround === The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile. {{{ 128 emptyPLS :: DynFlags -> PersistentLinkerState 129 emptyPLS _ = PersistentLinkerState { 130 closure_env = emptyNameEnv, 131 itbl_env = emptyNameEnv, 132 pkgs_loaded = init_pkgs, 133 bcos_loaded = [], 134 objs_loaded = [], 135 temp_sos = [] } 136 137 -- Packages that don't need loading, because the compiler 138 -- shares them with the interpreted program. 139 -- 140 -- The linker's symbol table is populated with RTS symbols using an 141 -- explicit list. See rts/Linker.c for details. 142 where init_pkgs = [rtsUnitId] }}} I've tried 2 approaches which haven't worked completely: 1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach. 2. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors. What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet. === Example === {{{#!hs -- LogFloat.hs module Main (main) where import Data.Number.LogFloat (log1p) main :: IO () main = print $ log1p 1.0 }}} `runGhc LogFloat.hs` will fail: {{{ Loading package logfloat-0.13.3.3 ... linking ... LogFloat.hs: ...\x86_64-windows- ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p' LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:17:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:17:12 -0000 Subject: [GHC] #9821: DeriveAnyClass support for higher-kinded classes + some more comments In-Reply-To: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> References: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> Message-ID: <061.82efe3c37dea76e34ee2bd4f6e703fc3@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5462, #9968 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: What is the status here? Note that #9968 was fixed recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:22:16 -0000 Subject: [GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances In-Reply-To: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> References: <047.146348de4d2b18e1ad0360b7562542c2@haskell.org> Message-ID: <062.0669d6cdcecd88267009472267075642@haskell.org> #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7296 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: Replying to [comment:3 goldfire]: > This is by design, for better or worse. See #7296 for an explanation. I'm sure the fix -- that is, redesign -- for that ticket and this one will be the same, but I think it's worth leaving both tickets open, as the examples are slightly different. Duplicates tickets slow down sweeps of the bug tracker. Since #7296 references this ticket, I think it's safe to close this one. Yell if you disagree! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:28:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:28:47 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym In-Reply-To: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> References: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> Message-ID: <062.96d3974bad464f28516c25252630ad4b@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | PatternSynonyms 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 thomie): * keywords: => PatternSynonyms * failure: None/Unknown => Incorrect warning at compile-time * cc: cactus (removed) * cc: mpickering (added) * related: #8841 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:35:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:35:35 -0000 Subject: [GHC] #9784: Improve error message for misplaced quote inside promoted qualified type In-Reply-To: <047.546c05d155a967089478b2cd78e20337@haskell.org> References: <047.546c05d155a967089478b2cd78e20337@haskell.org> Message-ID: <062.91a3d3855c41079b4a63f41bb1d16f71@haskell.org> #9784: Improve error message for misplaced quote inside promoted qualified type -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (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: #3155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: GHC rejects valid program => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:35:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:35:47 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.492d25b7d4f418721bfbc9bc9954aa38@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): MikeIzbicki: OK so this is implemented! Could you give a test case, perhaps that can run? Simply accepting the above code isn't really a good test :-). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:36:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:36:42 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.01bd979469017300bfa7e347763c915b@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11067 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T11067 Comment: Ok this is done! I'd love you to try it out to check that it works. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:37:27 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.6c9fd634d890b14184f97c41bb6a2e64@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T10318 Comment: OK, this is done! Edward: can you try it out? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:42:52 -0000 Subject: [GHC] #9735: Template Haskell for cross compilers (port from GHCJS) In-Reply-To: <044.571ab421ac035967d7e54249bed99e9a@haskell.org> References: <044.571ab421ac035967d7e54249bed99e9a@haskell.org> Message-ID: <059.7103c1f374b7355e1395296708d4968b@haskell.org> #9735: Template Haskell for cross compilers (port from GHCJS) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 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: wiki:RemoteGHCi | -------------------------------------+------------------------------------- Changes (by thomie): * wikipage: => wiki:RemoteGHCi Comment: Is this covered by Phab:D1562? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 15:44:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 15:44:52 -0000 Subject: [GHC] #9731: Inductive type definitions on Nat In-Reply-To: <045.ee757b86fa097a15d7c9fc18dbdaf548@haskell.org> References: <045.ee757b86fa097a15d7c9fc18dbdaf548@haskell.org> Message-ID: <060.cb0f42d11f6017a4b7670df2c4c9105b@haskell.org> #9731: Inductive type definitions on Nat -------------------------------------+------------------------------------- Reporter: barney | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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 thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 16:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 16:26:14 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var Message-ID: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 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: -------------------------------------+------------------------------------- `./configure --help` tells us that: {{{ ... Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory LIBS libraries to pass to the linker, e.g. -l CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if you have headers in a nonstandard directory CPP C preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. Report bugs to . }}} However, neither - `CC=clang-3.8 ./configure`, nor - `./configure CC=clang-3.8` has any effect. `./configure` keeps using the `/usr/bin/gcc` in `$PATH`. The only invocation that has the desired effect is - `./configure --with-gcc=clang-3.8` However, this is utterly surprising and confusing to experienced developers who are used to Autoconf `./configure` scripts adhering to the conventions regarding `CC`, and contradicts the `--help` message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 16:32:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 16:32:01 -0000 Subject: [GHC] #9983: configure script invokes ghc with LDFLAGS during cross-builds In-Reply-To: <046.b6e30fde76aad3b0396b4bd16d470332@haskell.org> References: <046.b6e30fde76aad3b0396b4bd16d470332@haskell.org> Message-ID: <061.b8fb725f36d87dde4dfed36da8203202@haskell.org> #9983: configure script invokes ghc with LDFLAGS during cross-builds -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11231 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #11231 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 16:32:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 16:32:24 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.4c577fbff6c80dd563839dd28ad98305@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9983 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 16:56:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 16:56:38 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.4804fb76605a767c6aa35bb9db884efd@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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:D1625 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D1625 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:05:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:05:44 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.16142f8ee0cfad29170be1f6ce403acb@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: > Also, there is a safe foreign import of `rtsSupportsBoundThreads` in GHC.IO.FD (and also some other module(s) in base), which seems quite unnecessary considering `rtsSupportsBoundThreads` simply returns a constant. For a newcomer, to get acquainted with the patch submission process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:05:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:05:57 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.bae39be178bfcc4e8363a7229f488b8a@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 refold]: > I'll summarise/reiterate my arguments for doing this in GHC: > These are convincing arguments. Especially the point about a bug being found in the wild, and the fact that there are two tickets about this issue. Go for it: it's quite easy. I think just adding a processing pass on [https://github.com/ghc/ghc/blob/master/compiler/rename/RnSplice.hs#L344 line 344] (beginning `quoteExpr =`) of !RnSplice should do it. And we'll need a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:09:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:09:36 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.1d4be0a30ff70f14afe3f7370c80e28e@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1630 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duairc): * differential: => Phab:D1630 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:10:59 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.bf7ae38d79959caa4b381b766d9b1ab0@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1630 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duairc): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:11:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:11:12 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.ddc2892910e5cb49f0ffe41a2c9052e7@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the high-priority bits here are `-dsuppress-uniques` issue (already ably addressed in Phab:D1629) and the missing definitions in `Data.Typeable.Internal`. I'm a little worried about `mkGhcTypesTyCon` using the wrong module name for the `GHC.Prim` stuff, but I don't actually think anyone will trip over it. I think removing the `GHC.Types` special case would be great, but that's merely a refactoring and need not be done for 8.0. So, TODO: Make sure all types (and data constructors) exported from `GHC.Types` have representations in `Data.Typeable.Internal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:12:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:12:11 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.b6cfd146fef0e074e8cb27a919b5c7fc@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 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 thomie): * priority: normal => high Comment: Still reproducible with HEAD. The first error (that you should ignore) is now: {{{ thbug.hs:4:1: error: Same exact name in multiple name-spaces: type constructor or class ?X?, declared at: thbug.hs:4:1 data constructor ?X?, declared at: thbug.hs:4:1 Probable cause: you bound a unique Template Haskell name (NameU), perhaps via newName, in different name-spaces. If that's it, then -ddump-splices might be useful }}} And the panic: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20151213 for x86_64-unknown-linux): kcLookupKind APromotionErr RecDataConPE }}} Panics are bad, raising priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:18:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:18:28 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.ce343bfe1a536146777091e523085435@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Not quite. This problem existed before `TypeInType` and continues to exist. It's just that my (new) implementation of `tcTyClTyVars` gets thrown off the scent by the `SigTv`s. But I'm pretty sure I have a fix for that, totally orthogonal to any fix for this ticket. I'll get the (quite local) fix in soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:20:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:20:59 -0000 Subject: [GHC] #11232: Panic whilst compiling syb due to OptCoercion Message-ID: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> #11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 minimised test case with most definitions inlined. {{{ module Data.Generics.Aliases where import Control.Monad import Data.Data mkMp :: ( MonadPlus m , Typeable a , Typeable b ) => (b -> m b) -> a -> m a mkMp ext = unM (maybe (M (const mzero)) id (gcast (M ext))) newtype M m x = M { unM :: x -> m x } }}} Panics with `-O2` as follows, {{{ ~/Documents/haskell/syb-0.6:ghc-7.11.20151214 Aliases.hs -O2 [1 of 1] Compiling Data.Generics.Aliases ( Aliases.hs, Aliases.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.11.20151214 for x86_64-apple-darwin): ASSERT failed! file compiler/types/OptCoercion.hs, line 234 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 Dec 15 17:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:21:24 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.3f22908bd85864acd385fc7c1ace7f60@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:10 mpickering]: > That sounds right Richard but there is also another bug here that inlining the synonym changes the semantics. That shouldn't get lost either. Yes. We need to test that. But I think the problem is due to universal/existential confusion when implementing pattern synonyms, and that sorting it out will fix the original bug. This assumption could very well be wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:22:40 -0000 Subject: [GHC] #11232: Panic whilst compiling syb due to OptCoercion In-Reply-To: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> References: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> Message-ID: <064.a89ac705be03a6f0d26107a9b5f3dcbe@haskell.org> #11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): In fact it fails core lint. {{{ *** Core Lint errors : in result of Simplifier *** : warning: In a case alternative: (True) Role incompatibility: expected representational, got nominal in UnsafeCo nominal b_a1me a_a1md *** Offending Program *** a_s1F4 :: TrName [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] a_s1F4 = TrNameS "main"# a_s1F5 :: TrName [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 80 20}] a_s1F5 = TrNameS "Data.Generics.Aliases"# $trModule :: Module [LclIdX[ReflectionId], Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module a_s1F4 a_s1F5 a_s1F6 :: TrName [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] a_s1F6 = TrNameS "'M"# $tc'M :: TyCon [LclIdX[ReflectionId], Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tc'M = TyCon 372692395467894104## 3145297546256518361## $trModule a_s1F6 a_s1F7 :: TrName [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 20}] a_s1F7 = TrNameS "M"# $tcM :: TyCon [LclIdX[ReflectionId], Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 50}] $tcM = TyCon 12760297783238653818## 4193448421405137177## $trModule a_s1F7 a_s1F8 :: forall (m_a1kx :: * -> *) x_a1ky. M m_a1kx x_a1ky -> M m_a1kx x_a1ky [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] a_s1F8 = \ (@ (m_a1kx :: * -> *)) (@ x_a1ky) (ds_d1nw :: M m_a1kx x_a1ky) -> ds_d1nw unM :: forall (m_a1gf :: * -> *) x_a1gg. M m_a1gf x_a1gg -> x_a1gg -> m_a1gf x_a1gg [LclIdX[[RecSel]], Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] unM = a_s1F8 `cast` (forall (m_a1kx :: <* -> *>_N). forall (x_a1ky :: <*>_N). _R -> NTCo:M[0] _R _N :: (forall (m_a1kx :: * -> *) x_a1ky. M m_a1kx x_a1ky -> M m_a1kx x_a1ky) ~R# (forall (m_a1kx :: * -> *) x_a1ky. M m_a1kx x_a1ky -> x_a1ky -> m_a1kx x_a1ky)) mkMp :: forall (m_a1gh :: * -> *) a_a1gi b_a1gj. (MonadPlus m_a1gh, Typeable a_a1gi, Typeable b_a1gj) => (b_a1gj -> m_a1gh b_a1gj) -> a_a1gi -> m_a1gh a_a1gi [LclIdX, Arity=4, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [60 0 0 0] 146 120}] mkMp = \ (@ (m_a1mc :: * -> *)) (@ a_a1md) (@ b_a1me) ($dMonadPlus_a1mf :: MonadPlus m_a1mc) ($dTypeable_a1mg :: Typeable a_a1md) ($dTypeable_a1mh :: Typeable b_a1me) (ext_a1jq :: b_a1me -> m_a1mc b_a1me) -> case ($dTypeable_a1mh `cast` (NTCo:Typeable[0] <*>_N _N :: Typeable b_a1me ~R# (Proxy# b_a1me -> TypeRep))) (proxy# @ * @ b_a1me) of _ [Occ=Dead] { TypeRep dt_a1ED dt1_a1EE ds2_a1EF ds3_a1EG ds4_a1EH -> case ($dTypeable_a1mg `cast` (NTCo:Typeable[0] <*>_N _N :: Typeable a_a1md ~R# (Proxy# a_a1md -> TypeRep))) (proxy# @ * @ a_a1md) of _ [Occ=Dead] { TypeRep dt2_a1EL dt3_a1EM ds5_a1EN ds6_a1EO ds7_a1EP -> case tagToEnum# @ Bool (eqWord# dt_a1ED dt2_a1EL) of _ [Occ=Dead] { False -> let { x_a1nN :: m_a1mc a_a1md [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] x_a1nN = mzero @ m_a1mc $dMonadPlus_a1mf @ a_a1md } in \ _ [Occ=Dead] -> x_a1nN; True -> case tagToEnum# @ Bool (eqWord# dt1_a1EE dt3_a1EM) of _ [Occ=Dead] { False -> let { x_a1nN :: m_a1mc a_a1md [LclId, Str=DmdType, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] x_a1nN = mzero @ m_a1mc $dMonadPlus_a1mf @ a_a1md } in \ _ [Occ=Dead] -> x_a1nN; True -> ext_a1jq `cast` (UnsafeCo nominal b_a1me a_a1md -> _R (UnsafeCo nominal b_a1me a_a1md) :: (b_a1me -> m_a1mc b_a1me) ~R# (a_a1md -> m_a1mc a_a1md)) } } } } *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:46:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:46:16 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.23839e160cdc949bed170759a293ecd4@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Thanks for the pointer. I'll try to come up with a patch, though I think that the right place to fix this is the lexer (like suggested in #8424). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:48:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:48:29 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.78a33a364446719dbdeb6c01fd4abe75@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T9687 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: `typeOf (1,2,3,4,5,6,7,8)` (up to 62) works in 7.10.3 and HEAD, probably as a result of #9858 ("Generate Typeable info at definition sites"). #10451 also dealt with the tuple size limitations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:51:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:51:53 -0000 Subject: [GHC] #9677: "operation not permitted" when running tests on Windows In-Reply-To: <045.5475ee1151ed504243ac223a5c5055f5@haskell.org> References: <045.5475ee1151ed504243ac223a5c5055f5@haskell.org> Message-ID: <060.a4c556eb4e707539beb3a4f0fbee2daa@haskell.org> #9677: "operation not permitted" when running tests on Windows ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: worksforme | 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 thomie): * status: new => closed * resolution: => worksforme Comment: Since we don't any other reports like this, I'm going to assume it was a fluke. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 17:58:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 17:58:24 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.38d4229b49e58dd6531043f822c13c07@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by ross): I've made the necessary changes to transformers in my repo, and can push them when base is changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 18:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 18:12:38 -0000 Subject: [GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied In-Reply-To: <047.eea63fe88376c060310ab582974460c3@haskell.org> References: <047.eea63fe88376c060310ab582974460c3@haskell.org> Message-ID: <062.1a3629bfbb62c410210a6a9ed59a53b6@haskell.org> #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | 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 thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 18:17:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 18:17: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.581f9a9e695c084346384cb37db195b9@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | 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: | -------------------------------+---------------------------------------- Changes (by trommler): * status: new => patch * failure: None/Unknown => GHCi crash * differential: => Phab:D1631 * architecture: x86_64 (amd64) => Unknown/Multiple Comment: I uploaded a fix to Phabricator. I need some help with writing a regression test. For the test we need a C shared library that is not part of GHCi and that is available on all operating systems. Alternatively we could create our own little shared library. Does the testsuite have support to portably create a shared library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 18:17:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 18:17:48 -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.4c56235becfd955258fbafcd0eb595b7@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | 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: | -------------------------------+---------------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 18:35:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 18:35:32 -0000 Subject: [GHC] #9573: Add warning for invalid digits in integer literals In-Reply-To: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> References: <045.6745c955d16114a85008c81a7aea2c4a@haskell.org> Message-ID: <060.d13e446f8d42708ff169e3a7de1125b0@haskell.org> #9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: vlopez Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 (Parser) | Keywords: report- Resolution: | impact, parsing, integer, octal, | binary, hexadecimal, 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): * keywords: parsing, integer, octal, binary, hexadecimal, => report- impact, parsing, integer, octal, binary, hexadecimal, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 18:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 18:37:38 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.1f1e580de6c404f14da6ba7d3c5f1698@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ross: I would like to see this change get into GHC 8.0, time permitting. There's one thing that bothers me about the most recent changes to `transformers`, however. After [http://hub.darcs.net/ross/transformers/patch/55d242cc15cb91c32a28433eff1e928cf113454e introducing] `Show1`/`Show2`/et al, you changed the `Show` instances to use them. For instance, the `Show` instance for `Backwards` [http://hackage.haskell.org/package/transformers-0.4.3.0/docs/src/Control- Applicative-Backwards.html#line-49 was]: {{{#!hs instance (Show1 f, Show a) => Show (Backwards f a) where showsPrec d (Backwards x) = showsUnary1 "Backwards" d x }}} But [http://hub.darcs.net/ross/transformers/browse/Control/Applicative/Backwards.hs#57 now] it's: {{{#!hs instance (Show1 f, Show a) => Show (Backwards f a) where showsPrec = showsPrec1 }}} The result is that the output of `show` changes. Before, the output of `show (Backwards "hello")` would be `"Backwards \"hello\""`, but with the latest changes, it's `"Backwards ['h','e','l','l','o']"`! This is because the `Show1 []` instance has to be parametric over its argument, so it can't tell that `Char` has a special `Show` instance that causes it to be shown differently. I feel like we should revert all the `Eq`/`Ord`/`Read`/`Show` instance in `transformers` back to the way they were (and keep the `Show1`/`Show2`/etc. instances separate) to prevent subtle changes like this. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:15:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:15:29 -0000 Subject: [GHC] #9499: Add -prelude-is flag In-Reply-To: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> References: <049.36f3129050b0840a8fd1551a23c65166@haskell.org> Message-ID: <064.a81d9935dd591652ff5bf5626a38818a@haskell.org> #9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: wontfix | Keywords: flag Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9590 | Differential Rev(s): Phab:D171 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: Closing, since the Diff is abandoned, and an alternative prelude can already be specified without compiler modifications (see comment:8 and comment:9). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:26:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:26:28 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.f3c1d315d6f7b1a1e1227ec49b241566@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: 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 thomie): This is fixed in HEAD. {{{ $ ghc-7.11.20151213 Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:4:8: error: ? Ambiguous type variable ?a0? arising from a use of ?show? prevents the constraint ?(Show a0)? from being solved. Probable fix: use a type annotation to specify what ?a0? should be. These potential instances exist: instance Show Module -- Defined in ?GHC.Show? instance Show Ordering -- Defined in ?GHC.Show? instance Show TrName -- Defined in ?GHC.Show? ...plus 25 others (use -fprint-potential-instances to see them all) ? In the expression: show _h In an equation for ?test?: test = show _h Test.hs:4:13: error: ? Found hole: _h :: a0 Where: ?a0? is an ambiguous type variable Or perhaps ?_h? is mis-spelled, or not in scope ? In the first argument of ?show?, namely ?_h? In the expression: show _h In an equation for ?test?: test = show _h ? Relevant bindings include test :: String (bound at Test.hs:4:1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:26:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:26:35 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.9de6852f29352406ec396ae16b5b0627@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:29:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:29:40 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.13f76e6ce4dc401b54e44f41132bb564@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Changes (by mfdyck.google): * Attachment "transformers.diff" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:30:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:30:27 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.09d8ad9e0869256bc07643911eaa0416@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by mfdyck.google): I have a patch, now enclosed, to move these to legacy in transformers, but some difficulty deriving Data and Typeable instances so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:31:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:31:52 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.31546d5dca292b56f5c0f563da532c90@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think the solution you propose is very confusing to users. I think we should be able to do better inferring whether a type variable univ/ex especially as GHC already manages to infer the correct signature. Doing so would require looking at the pattern synonym itself but I don't think this is too bad? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:31:54 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.e8717f45856df8c5b47716e12f3bbb99@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by mfdyck.google): ...and i ought to read prior comments first ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:35:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:35:47 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.f903e31b6f1f7a78791989d05b6bf6da@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by ross): Replying to [comment:8 RyanGlScott]: > Ross: I would like to see this change get into GHC 8.0, time permitting. > > There's one thing that bothers me about the most recent changes to `transformers`, however. After [http://hub.darcs.net/ross/transformers/patch/55d242cc15cb91c32a28433eff1e928cf113454e introducing] `Show1`/`Show2`/et al, you changed the `Show` instances to use them. For instance, the `Show` instance for `Backwards` [http://hackage.haskell.org/package/transformers-0.4.3.0/docs/src/Control- Applicative-Backwards.html#line-49 was]: > > {{{#!hs > instance (Show1 f, Show a) => Show (Backwards f a) where > showsPrec d (Backwards x) = showsUnary1 "Backwards" d x > }}} > > But [http://hub.darcs.net/ross/transformers/browse/Control/Applicative/Backwards.hs#57 now] it's: > > {{{#!hs > instance (Show1 f, Show a) => Show (Backwards f a) where showsPrec = showsPrec1 > }}} > > The result is that the output of `show` changes. Before, the output of `show (Backwards "hello")` would be `"Backwards \"hello\""`, but with the latest changes, it's `"Backwards ['h','e','l','l','o']"`! This is because the `Show1 []` instance has to be parametric over its argument, so it can't tell that `Char` has a special `Show` instance that causes it to be shown differently. > > I feel like we should revert all the `Eq`/`Ord`/`Read`/`Show` instance in `transformers` back to the way they were (and keep the `Show1`/`Show2`/etc. instances separate) to prevent subtle changes like this. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:39:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:39:14 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.3865b4658e7cf7c3702a4d16e9d442c6@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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: Old description: > In particular, I would like to have a class hierarchy that looks like: > > {{{ > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE FlexibleContexts #-} > > type family Scalar x > > class Field (Scalar x) => Vector x > > class Vector x => Field x > }}} > > It is the case that every field is a vector, and the scalar associated > with every vector is a field. But we can't currently enforce that. New description: In particular, I would like to have a class hierarchy that looks like: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} type family Scalar x class Field (Scalar x) => Vector x class Vector x => Field x }}} It is the case that every field is a vector, and the scalar associated with every vector is a field. But we can't currently enforce that. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:41:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:41:36 -0000 Subject: [GHC] #9952: Add -g In-Reply-To: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> References: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> Message-ID: <059.eb1b3e84b8007b455405f229653bf2ea@haskell.org> #9952: Add -g -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 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 bgamari): Indeed. Thanks thomie! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:41:40 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.47c974218532c3a0d3a0fa16a80832c1@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5539 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple * related: 5539 => #5539 Comment: I didn't try to reproduce, but I don't think it is Mac specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:54:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:54:22 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.6bc58c7d6a89103d6642b18bd6b0036f@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'll see what I can do before I head out for the holidays. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:54:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:54:56 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags In-Reply-To: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> References: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> Message-ID: <057.418ffaab4a2a198f10e0440549cc5703@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 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:D1613 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > TODO: description New description: Move warning options out of the `-f` namespace and into `-W` where they belong. See [[Design/Warnings]] for details. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:55:43 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.5a393902b920958b87fcedff82f9fdc0@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The original report triggers a core lint error. {{{ *** Core Lint errors : in result of Desugar (before optimization) *** T11224.hs:12:12: warning: [RHS of xs_aqv :: [Int]] The type of this binder doesn't match the type of its RHS: xs_aqv Binder's type: [Int] Rhs type: Int *** Offending Program *** Rec { $dRead_a2FJ :: Read Int [LclId, Str=DmdType] $dRead_a2FJ = $dRead_a148 $dRead_a2FO :: Read [Int] [LclId, Str=DmdType] $dRead_a2FO = $dRead_a14j $dRead_a14j :: Read [Int] [LclId, Str=DmdType] $dRead_a14j = $fRead[] @ Int $dRead_a148 $dRead_a148 :: Read Int [LclId, Str=DmdType] $dRead_a148 = $fReadInt $dFoldable_a2FR :: Foldable [] [LclId, Str=DmdType] $dFoldable_a2FR = $dFoldable_a21o $dFoldable_a21o :: Foldable [] [LclId, Str=DmdType] $dFoldable_a21o = $fFoldable[] $dNum_a2FV :: Num Int [LclId, Str=DmdType] $dNum_a2FV = $dNum_a2aM $dNum_a2aM :: Num Int [LclId, Str=DmdType] $dNum_a2aM = $fNumInt $dMonad_a2QC :: Monad IO [LclId, Str=DmdType] $dMonad_a2QC = $dMonad_a2Gj $dMonad_a2Ql :: Monad IO [LclId, Str=DmdType] $dMonad_a2Ql = $dMonad_a2Gj $dMonad_a2Q4 :: Monad IO [LclId, Str=DmdType] $dMonad_a2Q4 = $dMonad_a2Gj $dMonad_a2PN :: Monad IO [LclId, Str=DmdType] $dMonad_a2PN = $dMonad_a2Gj $dMonad_a2Gj :: Monad IO [LclId, Str=DmdType] $dMonad_a2Gj = $fMonadIO $dShow_a2QT :: Show Int [LclId, Str=DmdType] $dShow_a2QT = $dShow_a2PG $dShow_a2QM :: Show Int [LclId, Str=DmdType] $dShow_a2QM = $dShow_a2PG $dShow_a2Qv :: Show Int [LclId, Str=DmdType] $dShow_a2Qv = $dShow_a2PG $dShow_a2Qe :: Show Int [LclId, Str=DmdType] $dShow_a2Qe = $dShow_a2PG $dShow_a2PX :: Show Int [LclId, Str=DmdType] $dShow_a2PX = $dShow_a2PG $dShow_a2PG :: Show Int [LclId, Str=DmdType] $dShow_a2PG = $fShowInt bar :: String -> Int [LclId, Str=DmdType] bar = letrec { bar_aLd :: String -> Int [LclId, Str=DmdType] bar_aLd = \ (ds_d3jj :: String) -> let { fail_d3kF :: Void# -> Int [LclId, Str=DmdType] fail_d3kF = \ (ds_d3kG [OS=OneShot] :: Void#) -> let { fail_d3kD :: Void# -> Int [LclId, Str=DmdType] fail_d3kD = \ (ds_d3kE [OS=OneShot] :: Void#) -> I# 666# } in let { ds_d3kC :: Maybe [Int] [LclId, Str=DmdType] ds_d3kC = readMaybe @ [Int] $dRead_a14j ds_d3jj } in case ds_d3kC of wild_00 { __DEFAULT -> fail_d3kD void#; Just xs_azI -> sum @ [] $dFoldable_a21o @ Int $dNum_a2aM xs_azI } } in let { ds_d3kB :: Maybe Int [LclId, Str=DmdType] ds_d3kB = readMaybe @ Int $dRead_a148 ds_d3jj } in case ds_d3kB of wild_00 { __DEFAULT -> fail_d3kF void#; Just x_azH -> x_azH }; } in bar_aLd $mPRead :: forall (rlev_a2FC :: Levity) (r_a2FD :: TYPE rlev_a2FC) a_a2aV. Read a_a2aV => String -> (a_a2aV -> r_a2FD) -> (Void# -> r_a2FD) -> r_a2FD [LclIdX[PatSynId], Str=DmdType] $mPRead = \ (@ (rlev_a2FC :: Levity)) (@ (r_a2FD :: TYPE rlev_a2FC)) (@ a_a2aV) ($dRead_a2FB :: Read a_a2aV) (scrut_a2FE :: String) (cont_a2FF :: a_a2aV -> r_a2FD) (fail_a2FG :: Void# -> r_a2FD) -> let { $dRead_a2aX :: Read a_a2aV [LclId, Str=DmdType] $dRead_a2aX = $dRead_a2FB } in let { ds_d3kH :: String [LclId, Str=DmdType] ds_d3kH = scrut_a2FE } in let { fail_d3kL :: Void# -> r_a2FD [LclId, Str=DmdType] fail_d3kL = \ (ds_d3kM [OS=OneShot] :: Void#) -> fail_a2FG void# } in let { ds_d3kK :: Maybe a_a2aV [LclId, Str=DmdType] ds_d3kK = readMaybe @ a_a2aV $dRead_a2aX ds_d3kH } in case ds_d3kK of wild_00 { __DEFAULT -> fail_d3kL void#; Just a_aqt -> cont_a2FF a_aqt } foo :: String -> Int [LclId, Str=DmdType] foo = letrec { foo_a2FH :: String -> Int [LclId, Str=DmdType] foo_a2FH = \ (ds_d3kN :: String) -> let { fail_d3m5 :: Void# -> Int [LclId, Str=DmdType] fail_d3m5 = \ (ds_d3m6 [OS=OneShot] :: Void#) -> I# 666# } in $mPRead @ 'Lifted @ Int @ Int $dRead_a2FJ ds_d3kN (\ (x_aqu :: Int) -> let { xs_aqv :: [Int] [LclId, Str=DmdType] xs_aqv = x_aqu } in x_aqu) (\ (void_0E :: Void#) -> fail_d3m5 void#); } in foo_a2FH main :: IO () [LclIdX, Str=DmdType] main = letrec { main_a2G0 :: IO () [LclId, Str=DmdType] main_a2G0 = >> @ IO $dMonad_a2Gj @ () @ () ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2PG) (foo (unpackCString# "1"#))) (>> @ IO $dMonad_a2PN @ () @ () ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2PX) (foo (unpackCString# "[1,2,3]"#))) (>> @ IO $dMonad_a2Q4 @ () @ () ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2Qe) (foo (unpackCString# "xxx"#))) (>> @ IO $dMonad_a2Ql @ () @ () ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2Qv) (bar (unpackCString# "1"#))) (>> @ IO $dMonad_a2QC @ () @ () ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2QM) (bar (unpackCString# "[1,2,3]"#))) ($ @ 'Lifted @ Int @ (IO ()) (print @ Int $dShow_a2QT) (bar (unpackCString# "xxx"#))))))); } in main_a2G0 $trModule :: Module [LclIdX[ReflectionId], Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) main :: IO () [LclIdX, Str=DmdType] main = runMainIO @ () main end Rec } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 19:58:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 19:58:29 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.4de162527319599eb4eb5dfdf191f76e@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: javran Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: ghci 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 thomie): javran: did you make any progress with this ticket? Maybe just some notes that you could contribute, such that someone else can take over? Come over to the #ghc irc channel if you need help, there are usually people around all day there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:00:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:00:47 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.194c40e4f70c0a7fbd476a6b2643f100@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The relevant function which is definitely wrong.. {{{ foo :: String -> Int [LclId, Str=DmdType] foo = letrec { foo_a2FH :: String -> Int [LclId, Str=DmdType] foo_a2FH = \ (ds_d3kN :: String) -> let { fail_d3m5 :: Void# -> Int [LclId, Str=DmdType] fail_d3m5 = \ (ds_d3m6 [OS=OneShot] :: Void#) -> I# 666# } in $mPRead @ 'Lifted @ Int @ Int $dRead_a2FJ ds_d3kN (\ (x_aqu :: Int) -> let { xs_aqv :: [Int] [LclId, Str=DmdType] xs_aqv = x_aqu } in x_aqu) (\ (void_0E :: Void#) -> fail_d3m5 void#); } in foo_a2FH }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:05:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:05:40 -0000 Subject: [GHC] #7723: iOS patch no 12: Itimer.c doesn't work on iOS In-Reply-To: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> References: <056.9767e70565312fbbb95062bfdcdf193a@haskell.org> Message-ID: <071.2b6f30a03587ed3d223b79a7e8e4d72c@haskell.org> #7723: iOS patch no 12: Itimer.c doesn't work on iOS --------------------------------------+---------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Other | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+---------------------------------- Changes (by bgamari): * priority: normal => low * milestone: 8.0.1 => 8.2.1 Old description: > As it stands, rts/posix/Itimer.c dies at runtime on iOS. > > I am in the process of tidying up a solution for this. New description: As it stands, `rts/posix/Itimer.c` dies at runtime on iOS. I am in the process of tidying up a solution for this. -- Comment: Bumping to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:06:17 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.435ad13dc6d5178035acb2515a6e3a6b@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: regression 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:"e2c917381ff099820b1ee30fcfa8bc0c20cf5c1f/ghc" e2c91738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2c917381ff099820b1ee30fcfa8bc0c20cf5c1f" Narrow scope of special-case for unqualified printing of names in core libraries Commit 547c597112954353cef7157cb0a389bc4f6303eb modifies the pretty-printer to render names from a set of core packages (`base`, `ghc-prim`, `template-haskell`) as unqualified. The idea here was that many of these names typically are not in scope but are well-known by the user and therefore qualification merely introduces noise. This, however, is a very large hammer and potentially breaks any consumer who relies on parsing GHC output (hence #11208). This commit partially reverts this change, now only printing `Constraint` (which appears quite often in errors) as unqualified. Fixes #11208. Updates tests in `array` submodule. Test Plan: validate Reviewers: hvr, thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1619 GHC Trac Issues: #11208 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:06:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:06:49 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.63d6426f757d4c74273221ad5682410f@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Loading the symbols earlier seems like it will work. The issue now is that a horrible design decision with `libmingwex` is causing us to have to link in far more than expected. [http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4FDD7839.7080803 at gmail.com/ libmingwex] has a depencency on the symbol `__mingw_raise_matherr`. This symbol is defined in `libmingw32` which is where the fun begins.. We also end up needing the `ld` symbol `__image_base__` because of these dependencies and ultimately `libmingw32` also requires `wWinMain` which is the only symbol I don't know what to do about. The list of needed libraries: * libgcc.a * libws2_32.a * libmingw32.a * user32.dll * Advapi32.dll I'll keep looking, but we may want to consider re-distributing `msvcrt120.dll` which would also have all the symbols we need. It seems like the license for `Visual Studio 2013 C++ Redistributables` might [https://msdn.microsoft.com/en-us/vstudio/dn501987 allow] this now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:08:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:08:24 -0000 Subject: [GHC] #10029: ARM: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.8cfd868f138004c252353a231ba85f05@haskell.org> #10029: ARM: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: I'm afraid 7.8 is known to have a variety of issues on ARM. Marking at wontfix. We would love to hear about issues with newer releases, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:14:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:14:36 -0000 Subject: [GHC] #10368: STM test failing on Armhf/Linux In-Reply-To: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> References: <044.6c875c75185feb19cd9d136bb8014898@haskell.org> Message-ID: <059.e9d80a204f73ed66f441bbdc19c4bd83@haskell.org> #10368: STM test failing on Armhf/Linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #7815 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => worksforme Comment: I also failed to reproduce this with a four-core A15 box with 7.11. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:15:27 -0000 Subject: [GHC] #7988: Big integers crashing integer-simple on qnxnto-arm with unregisterised build (was: Big integers crashing integer-simple on qnxnto-arm) In-Reply-To: <049.7e25cab1852e69b7f9c237cdefeb4eb3@haskell.org> References: <049.7e25cab1852e69b7f9c237cdefeb4eb3@haskell.org> Message-ID: <064.dd911b93dca739b26237b2d7282c01f7@haskell.org> #7988: Big integers crashing integer-simple on qnxnto-arm with unregisterised build ----------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: QNX | Architecture: arm Type of failure: Runtime crash | 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 Dec 15 20:16:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:16:56 -0000 Subject: [GHC] #1978: Error message: Undefined reference to `XXX_closure' In-Reply-To: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> References: <045.20d18fd66d659649248435a8e2071ba7@haskell.org> Message-ID: <060.a8809d525f0d846faa539372044e6618@haskell.org> #1978: Error message: Undefined reference to `XXX_closure' -------------------------------------+------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => worksforme Comment: I have been able to build Pandoc with 7.10. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:18:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:18:10 -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.53b2a6dcb686e552415dc93b91829230@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | 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 Phyx-): Hi trommler, do you need a static or dynamic lib for the regression test? I built a few dynamic ones myself in `testsuite\tests\ghci\linking\dyn` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:24:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:24:59 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.78948411389983554555c2c4fde7cfd0@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+---------------------------------- Reporter: Chobbes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 951, #9920 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded * related: 951 => 951, #9920 Comment: I believe I encountered the same issue not so long ago when using Debian's LLVM 3.5 version, which is unfortunately missing some rather critical fixes (see #9920 for details). Can you reproduce this with LLVM 3.5.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:27:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:27:05 -0000 Subject: [GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error In-Reply-To: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> References: <047.bceeb896163ce5c5b456acc4c61124e2@haskell.org> Message-ID: <062.2d11c4248dd63dbd5e95e08dfbdefef7@haskell.org> #9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 thomie): * status: new => closed * resolution: => wontfix Comment: Replying to [comment:4 goldfire]: > Perhaps we could have a `-fallow-unrecognized-extensions`, or perhaps it's not worth the bother. Such a flag wouldn't help with the scenario given in the description, since it would be disabled by default, and CPP would still be necessary. Given that there hasn't been much interest in this ticket, I'm closing as wontfix. Please reopen and change the title if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:42:39 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.c0abd703340df87d1b328ba5f06dfc97@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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 bgamari): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:50:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:50:28 -0000 Subject: [GHC] #11178: Documentation bug in Data.List.NonEmpty In-Reply-To: <047.366d4367ffa92509b4848ace839d952a@haskell.org> References: <047.366d4367ffa92509b4848ace839d952a@haskell.org> Message-ID: <062.8d0b2c77887b27f5077b326351b5d5f4@haskell.org> #11178: Documentation bug in Data.List.NonEmpty -------------------------------------+------------------------------------- Reporter: audunska | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"758e6b3a935242acacfa5f1c23ecd1b0e9310e28/ghc" 758e6b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="758e6b3a935242acacfa5f1c23ecd1b0e9310e28" base: NonEmpty: Fix documentation example Fixes #11178. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:50:42 -0000 Subject: [GHC] #11178: Documentation bug in Data.List.NonEmpty In-Reply-To: <047.366d4367ffa92509b4848ace839d952a@haskell.org> References: <047.366d4367ffa92509b4848ace839d952a@haskell.org> Message-ID: <062.797d8a831a0402f9f03bb00bb94f8121@haskell.org> #11178: Documentation bug in Data.List.NonEmpty -------------------------------------+------------------------------------- Reporter: audunska | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: 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: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:50:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:50:52 -0000 Subject: [GHC] #11178: Documentation bug in Data.List.NonEmpty In-Reply-To: <047.366d4367ffa92509b4848ace839d952a@haskell.org> References: <047.366d4367ffa92509b4848ace839d952a@haskell.org> Message-ID: <062.cc274cd8da96438c87172687c8091659@haskell.org> #11178: Documentation bug in Data.List.NonEmpty -------------------------------------+------------------------------------- Reporter: audunska | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.2 Resolution: fixed | Keywords: 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): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:51:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:51:39 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.aeda4330dfa353efddec39382574283a@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"a701694b27143d094f9de0a78757bbdeaa07daa6/ghc" a701694b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a701694b27143d094f9de0a78757bbdeaa07daa6" Add testcase for #11224 Test Plan: Validate Reviewers: austin, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1622 GHC Trac Issues: #11224 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:54:51 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.c0f06fea8d4ab0cbcabab0a7ffc5f8b6@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D1632 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 20:58:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 20:58:23 -0000 Subject: [GHC] #11208: GHCi doesn't qualify types anymore In-Reply-To: <042.585a8985b5aba877c56b474078648ae0@haskell.org> References: <042.585a8985b5aba877c56b474078648ae0@haskell.org> Message-ID: <057.74b2eaa8a9e552c421f9ac0fe179b86b@haskell.org> #11208: GHCi doesn't qualify types anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: regression 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 => closed * resolution: => fixed Comment: The above commit drastically reduced the scope of the special-casing. Hopefully this should help make the output a bit more predictable. For the list of names that will be unconditionally printed as unqualified see `forceUnqualNames` in `mkPrintUnqualified`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:13:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:13:10 -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.4cb3caa8159d3616d6cfade933af63c1@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | 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: | -------------------------------+---------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:16:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:16:43 -0000 Subject: [GHC] #11233: Improve optimisation of pattern synonym matching Message-ID: <049.c3c9bdcea20f761bdc3df1ecf3f93c02@haskell.org> #11233: Improve optimisation of pattern synonym matching -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: newcomer, | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHC does a very poor job of optimising pattern matches which include pattern synonyms. It would be good to modify `sameGroup` in `compiler/deSugar/Match.hs` to be a lot smarter about when it is safe to group two pattern matches together. Grouping was originally disabled as it is a bit trickier than originally thought. See #11224 for details. The rule was originally to group two pattern matches together `PgSyn p1` and `PgSyn p2` when `p1 == p2`. This rule wasn't safe when `p1` had a polymorphic return type and thus could have a different type on each branch even though syntactically identical. A good solution to this ticket would come up with a smarter rule about when it is and isn't safe to group two together in the same spirit as the more complicated rules for view patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:17:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:17:56 -0000 Subject: [GHC] #11199: Outdated documentation for type operators In-Reply-To: <047.bc69110f06c37418a05cf5b426cd2efe@haskell.org> References: <047.bc69110f06c37418a05cf5b426cd2efe@haskell.org> Message-ID: <062.81e189b4c8b6fd4464c604d9e3cf27a7@haskell.org> #11199: Outdated documentation for type operators -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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: I believe this is fixed in the documentation for [[http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #infix-type-constructors-classes-and-type-variables|GHC 8.0]]. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:20:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:20:06 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.388b1e31c1306ec96c0f43306262b751@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 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 bgamari): * cc: goldfire (added) Comment: Cc'ing Richard, who is our (very busy) Template Haskell czar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:22:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:22:41 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.34323a715fa501939debcee6621ad7c0@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28638dfe79e915f33d75a1b22c5adce9e2b62b97/ghc" 28638df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28638dfe79e915f33d75a1b22c5adce9e2b62b97" primops: Mark actions evaluated by `catch*` as lazy There is something very peculiar about the `catch` family of operations with respect to strictness analysis: they turn divergence into non-divergence. For this reason, it isn't safe to mark them as strict in the expression whose exceptions they are catching. The reason is this: Consider, let r = \st -> raiseIO# blah st in catch (\st -> ...(r st)..) handler st If we give the first argument of catch a strict signature, we'll get a demand 'C(S)' for 'r'; that is, 'r' is definitely called with one argument, which indeed it is. The trouble comes when we feed 'C(S)' into 'r's RHS as the demand of the body as this will lead us to conclude that the whole 'let' will diverge; clearly this isn't right. This is essentially the problem in #10712, which arose when 7c0fff41789669450b02dc1db7f5d7babba5dee6 marked the `catch*` primops as being strict in the thing to be evaluated. Here I've partially reverted this commit, again marking the first argument of these primops as lazy. Fixes #10712. Test Plan: Validate checking `exceptionsrun001` Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1616 GHC Trac Issues: #10712, #11222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:22:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:22:41 -0000 Subject: [GHC] #11222: Teach strictness analysis about `catch`-like operations In-Reply-To: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> References: <046.f647d66e4bef0e997f39475296853bd7@haskell.org> Message-ID: <061.710227def4b3d203d0931027945d3fd0@haskell.org> #11222: Teach strictness analysis about `catch`-like operations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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 Ben Gamari ): In [changeset:"28638dfe79e915f33d75a1b22c5adce9e2b62b97/ghc" 28638df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28638dfe79e915f33d75a1b22c5adce9e2b62b97" primops: Mark actions evaluated by `catch*` as lazy There is something very peculiar about the `catch` family of operations with respect to strictness analysis: they turn divergence into non-divergence. For this reason, it isn't safe to mark them as strict in the expression whose exceptions they are catching. The reason is this: Consider, let r = \st -> raiseIO# blah st in catch (\st -> ...(r st)..) handler st If we give the first argument of catch a strict signature, we'll get a demand 'C(S)' for 'r'; that is, 'r' is definitely called with one argument, which indeed it is. The trouble comes when we feed 'C(S)' into 'r's RHS as the demand of the body as this will lead us to conclude that the whole 'let' will diverge; clearly this isn't right. This is essentially the problem in #10712, which arose when 7c0fff41789669450b02dc1db7f5d7babba5dee6 marked the `catch*` primops as being strict in the thing to be evaluated. Here I've partially reverted this commit, again marking the first argument of these primops as lazy. Fixes #10712. Test Plan: Validate checking `exceptionsrun001` Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1616 GHC Trac Issues: #10712, #11222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:24:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:24:15 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.0e6daa0d52c6e2cfc2a9ce58619a5bbd@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:35:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:35:56 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.e501a51b6ab500bb77c4c76afd8680cb@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by ekmett): Ryan: I'm really very negative on the idea of reverting to the old approach. We rather deliberately changed them in HEAD months ago to make it so that they can be used in more situations without requiring the `Functor` constraint a few months back, the old approach had rendered these classes useless for a lot of real world situations around GADTs and the like, in a way that simultaneously made implementations inefficient and less often applicable. The old transformers approach winds up requiring {{{#!hs instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) }}} while the current approach lets you use {{{#!hs instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) }}} and the code works in one pass regardless of whether or not f and g are known. The price of admission is a manual implementation. The current compromise Ross has implemented gets a design that is readily implemented and implementable for a wide arrange of things. Now, we could modify the way we pass in the "manual dictionary" version of 'Show/Read' to allow the `showList`/`readList` trick to work. It'd admittedly make the classes harder to implement and use. I could get behind an alternative API that passed in more stuff to `readsPrecWith` and `showsPrecWith`, or one that added a second combinator so that most people didn't have to deal with the noise. I'd be okay with either proceeding with the status quo, or even more comfortable proceeding with a fix that modifies the methods in the `Show1` and `Read1` classes to pass more information, but it'd take a lot of convincing to bring me around to the old version in transformers, especially when we very consciously changed to get away from it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:48:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:48:06 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.9729e1feb66a8f8a82356f54ba9045a3@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 -------------------------------------+------------------------------------- Comment (by ross): Replying to [comment:11 ekmett]: > Ryan: I'm really very negative on the idea of reverting to the old approach. > > We rather deliberately changed them in HEAD months ago to make it so that they can be used in more situations without requiring the `Functor` constraint a few months back, the old approach had rendered these classes useless for a lot of real world situations around GADTs and the like, in a way that simultaneously made implementations inefficient and less often applicable. > > The old transformers approach winds up requiring > > {{{#!hs > instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) > }}} > > while the current approach lets you use > > {{{#!hs > instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) > }}} > > and the code works in one pass regardless of whether or not f and g are known. > > The price of admission is a manual implementation. The current compromise Ross has implemented gets a design that is readily implemented and implementable for a wide arrange of things. > > Now, we could modify the way we pass in the "manual dictionary" version of 'Show/Read' to allow the `showList`/`readList` trick to work. It'd admittedly make the classes harder to implement and use. I could get behind an alternative API that passed in more stuff to `readsPrecWith` and `showsPrecWith`, or one that added a second combinator so that most people didn't have to deal with the noise. > > I'd be okay with either proceeding with the status quo, or even more comfortable proceeding with a fix that modifies the methods in the `Show1` and `Read1` classes to pass more information, but it'd take a lot of convincing to bring me around to the old version in transformers, especially when we very consciously changed to get away from it! Yes, I'd come to the same conclusion, and have already made the necessary changes for `Show1`, and am now working through `Read1`. Note that the version before the changes also gave the wrong output on `show (Compose (Just "abc"))`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:50:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:50:41 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.4c2aab23d278af7ecc7c0ee258d5e464@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rvion): Hello, will expressions like: {{{ module Data.Aeson.Types.AsJs where import qualified Data.Aeson.Types as I pattern JsOptions a b c d e <- I.Options a b c d e }}} keep working correctly after this fix ? I use patterns a lot to automatically reexport "qualified" modules. (WIP project) see example here: https://github.com/rvion/ride/blob/94767d043b33fa5702852fba384b4e6dcf4007a5/jetpack/src/Data/Aeson/Types/AsJs.hs#L38 or here: https://github.com/rvion/ride/blob/94767d043b33fa5702852fba384b4e6dcf4007a5/jetpack/src/Codec/Archive/Tar/AsTar.hs#L44 Otherwise, according to http://mpickering.github.io/posts/2015-12-12 -pattern-synonyms-8.html, most of my remaining issues seems to be solved in HEAD, thanks very much for all those great enhancements! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 21:55:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 21:55:19 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.ff1c3b05c7a3fa5e740df2499ddc00c3@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Which fix are you talking about? This ticket is quite muddled, we have mainly discussed #11225 but I have now fixed this ticket. However, your usecase looks quite simple and I suspect unrelated to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:03:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:03:51 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.e9263d3895efd7162010cc96b85abdc3@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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 goldfire): Yes -- I'm pretty sure I know exactly what's going on here. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:11:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:11:23 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.426dde995a32c30f21731bc5d4c5f012@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rvion): Replying to [comment:19 mpickering]: > Which fix are you talking about? This ticket is quite muddled, we have mainly discussed #11225 but I have now fixed this ticket. Sorry, I didn't read this ticket correctly. Don't mind my previous message. > However, your usecase looks quite simple and I suspect unrelated to this ticket. Yes, you're right, my bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:26:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:26:33 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults Message-ID: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> #11234: GHCi on Windows segfaults ----------------------------------------+------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- GHCi on Windows has had a segfault for while now on `x86_64`. During the upgrade of `GCC` in Phab:D1123 I noticed that test `prog003` was failing with a segfault. Currently the segfault exist in both versions but on `x86` it's particularly easy to trigger. In my case I can't even start ghci. {{{ $ inplace/bin/GHC-stage2.exe --interactive GHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help Segmentation fault/access violation in generated code }}} The segfault does not seem to happen when linked to the debug rts, and running with `+RTS -Ds -RTS` doesn't report anything special. Compiling with `devel2` so the rts gets compiled with `-g` the stack trace is not very useful. {{{ (gdb) run --interactive Starting program: /home/Tamar/ghc/inplace/bin/ghc-stage2 --interactive [New Thread 108480.0x1960c] [New Thread 108480.0x19b2c] [New Thread 108480.0x19c30] [New Thread 108480.0x1a0a8] [New Thread 108480.0x1a93c] [New Thread 108480.0x13954] [New Thread 108480.0x14440] GHCi, version 7.11.20151213: http://www.haskell.org/ghc/ :? for help Program received signal SIGSEGV, Segmentation fault. 0x06843aa5 in ?? () (gdb) bt #0 0x06843aa5 in ?? () #1 0x04b82cfc in ?? () #2 0x8d078902 in ?? () #3 0xc689fd47 in ?? () #4 0xff04c583 in ?? () #5 0x83c70065 in ?? () #6 0x0000033c in ?? () #7 0x00000008 in ?? () #8 0x04e9c689 in ?? () Backtrace stopped: Cannot access memory at address 0x47c70cc8 }}} And the output of `p4` {{{ (gdb) p4 0x06843aa5 0x6843ab0: 0x330073 0x6843aac: 0x790073 0x6843aa8: 0x6d005c 0x6843aa4: 0x3a0045 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:42:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:42:34 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.774ee2bc1a8e1b6837031114d8b84b87@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: thomie correctly pointed out that this patch did not actually fix the four failing testcases marked in 3b233793. Looks like I'll need to dive a bit deeper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:46:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:46:53 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.5ee02202017e661d4c4de20a166dc44d@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Changes (by duairc): * differential: Phab:D1543 Phab:D1544 => Phab:D1543 Phab:D1544 Phab:D1630 Comment: I've made a [https://phabricator.haskell.org/D1630 patch] for splitting `Data.Functor.Const` into its own module, which is more or less orthogonal to migrating the functors from `transformers` into `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 22:56:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 22:56:44 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.4d70dd42dae5ff82977da2cbc92ddbca@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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): Terrific. Do leave `Note`s in your wake! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:03:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:03:19 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.f5dfad6e46dba9dff0255b9022eb3342@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T18020.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1200 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c1e25536d67fba33ad6ddae5556115340d99000a/ghc" c1e2553/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1e25536d67fba33ad6ddae5556115340d99000a" Expose enabled language extensions to TH This exposes `template-haskell` functions for querying the language extensions which are enabled when compiling a module, - an `isExtEnabled` function to check whether an extension is enabled - an `extsEnabled` function to obtain a full list of enabled extensions To avoid code duplication this adds a `GHC.LanguageExtensions` module to `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy consequence of this is that the ungainly `DynFlags` lost around 500 lines. Moreover, flags corresponding to language extensions are now clearly distinguished from other flags due to the `LangExt.*` prefix. Updates haddock submodule. This fixes #10820. Test Plan: validate Reviewers: austin, spinda, hvr, goldfire, alanz Reviewed By: goldfire Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1200 GHC Trac Issues: #10820 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:05:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:05:06 -0000 Subject: [GHC] #9348: "Symbol not found" when using a shared library In-Reply-To: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> References: <049.505411c990d6efe7c6bbe51db4210fb4@haskell.org> Message-ID: <064.befed7148fe3fef6d911ca07f28effc4@haskell.org> #9348: "Symbol not found" when using a shared library --------------------------------------+-------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+-------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: After reading the documentation again, I don't think there is a bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:10:04 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.e7243c9f2fb46ba3a0adb574c725d0bc@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): rvion: if there's an issue, and it's not the issue in this ticket, would you like to open a ticket of your own? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:10:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:10:51 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.caea5b26d374bea1320c2802be5e9c96@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T18020.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1200 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:11:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:11:01 -0000 Subject: [GHC] #10820: Provide a way to detect what extensions are enabled via TH In-Reply-To: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> References: <045.fdd68b124ff34a39c484baed79715ead@haskell.org> Message-ID: <060.bde605a2c00f3d83f920ade3842f9fa1@haskell.org> #10820: Provide a way to detect what extensions are enabled via TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: spinda Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T18020.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1200 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > This would be helpful for providing users with intuitive/explanatory > error messages if generated code relies on an extension that the user may > not have enabled. > > Sample specification, to get things started: > > {{{ > enabledExts :: Q [Extension] > isExtEnabled :: Extension -> Q Bool > data Extension = LiberalTypeSynonyms | RankNTypes | ... > -- mirroring ExtensionFlag in DynFlags > }}} > > See #10819 for an example case where this could be of use. New description: This would be helpful for providing users with intuitive/explanatory error messages if generated code relies on an extension that the user may not have enabled. Sample specification, to get things started: {{{#!hs enabledExts :: Q [Extension] isExtEnabled :: Extension -> Q Bool data Extension = LiberalTypeSynonyms | RankNTypes | ... -- mirroring ExtensionFlag in DynFlags }}} See #10819 for an example case where this could be of use. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 15 23:20:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Dec 2015 23:20:15 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.1f84956470ceab2f51939c5d835ac2f2@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, back to this ticket. I think we were just getting ourselves confused. * The type of `PRead` is definitely {{{ pattern PRead :: Read a => () => a -> String }}} That is, `(Read a)` is required (to perform the match), not provided (by being bound by the match). And `a` is certainly not existential. * The existential type variables are simply the ones bound existentially by the actual pattern. As Matthew says, we can't work out which ones they are by looking at the type (that was a hefalump trap, which I fell into). In this example, there are no existential variables. * We have a perfectly good function that discovers which the existential variables are, called `tcCollectEx`. It's used in the inference case and we can certainly use it in the checking case too. * Since we can't tell which is which before `tcCheckPatSyn`, we should not split them up in `TcBinds.tcTySig`. They can all be in one list in the `TPSI` record. * Looking at `tcCheckPatSyn` it's a good deal more complicated than necessary. I'll fix that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 00:07:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 00:07:01 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.02c29db6173504d41017af7b044533e0@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by ross): I believe I've fixed the Show1/Read1 issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 00:13:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 00:13:18 -0000 Subject: [GHC] #11235: Haddock shows no class members Message-ID: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- At least since Haddock commit 0fc8cfd532f5dfd12b5504f44a2b3c9fb659cd87 on the `ghc-head` branch Haddock's HTML output has shown no class members. I'll need to work out why this is before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 00:19:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 00:19:28 -0000 Subject: [GHC] #11065: Outdated documentation for foldl and friends In-Reply-To: <047.712921fa5a5588273b6341e2632eef73@haskell.org> References: <047.712921fa5a5588273b6341e2632eef73@haskell.org> Message-ID: <062.22f3755365673c896b2d6a6e21ff8dd0@haskell.org> #11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Documentation | 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:D1617 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [ticket:11065 goldfire]: > I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. This video by Tony Morris is great: [http://vimeo.com/64673035 Explain List Folds to Yourself]. It's 48 minutes, but you'll never mix `foldl` and `foldr` up again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 02:10:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 02:10:52 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.3fd28fe63d87fb441bbbc054428a1de0@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like Haddock as GHC commit cd2840a784f4136a8cfdb704124e892430ad9ead works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 02:29:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 02:29:40 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.360c9755e0e3ef1fa139031067b70c03@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): 1e041b7382b6aa329e4ad9625439f811e0f27232 is bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 02:49:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 02:49:04 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.f5836af68cec8026fa50098c893e1350@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): bbaf76f949426c91d6abbbc5eced1f705530087b appears to be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 03:06:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 03:06:44 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.6f72cc64fff31f0fe1d272dcb59a155a@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): 96621b1b4979f449e873513e9de8d806257c9493 is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 04:22:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 04:22:14 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.935e360e4ec339597dd11ac44ed23c3c@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+---------------------------------- Reporter: Chobbes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 951, #9920 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by Chobbes): Replying to [comment:1 bgamari]: > I believe I encountered the same issue not so long ago when using Debian's LLVM 3.5 version, which is unfortunately missing some rather critical fixes (see #9920 for details). > > Can you reproduce this with LLVM 3.5.2? I have been trying a [https://haskellembedded.github.io/posts/2015-12-15-arm.html number of things desperately (don't judge)], so I am a bit turned around as to what I have tried. I might not have done this on the Pi yet. I noticed this issue in trac as well, so I have been trying higher LLVM versions where possible. It did seem like a different error, however. Do you have a program which can reproduce the results in #9920? Currently I have tested with Gentoo LLVM versions 3.5.0, 3.5.2, and 3.6.2 which have all had the same problem. This is in a fresh qemu-user-arm chroot (as described in the above post). This is also using the ARMv7 binaries provided for GHC 7.10.3. I will try to get LLVM 3.5.2 on my pi tomorrow to confirm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 04:22:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 04:22:39 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.fa7b2c22c2d0a451d78ec9d0b9617af7@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+---------------------------------- Reporter: Chobbes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #951, #9920 | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by Chobbes): * related: 951, #9920 => #951, #9920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 04:52:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 04:52:29 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.5c39284e298c1086059a417100c97ebb@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But how should we tell universals from existentials? If I say {{{ pattern type P :: a -> String }}} is `a` universal or existential? It seems mpickering wants the answer to be "it depends on the definition for `P`". That may well be implementable, but it negates a critical property of type signatures: that they give a specification of how a pattern synonym behaves absent its definition. We somehow have to be able to specify this in the signature itself. I don't have much perspective on Simon's comment:22. It's about implementation, and I'm still stuck on design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 08:28:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 08:28:38 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.03162fee0fd0188b1af628b8439513da@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * priority: high => highest Comment: I guess we should consider this a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 08:35:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 08:35:17 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.bc0ef42ffcdab62b5aaae0b1f5545c76@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): ac1a379363618a6f2f17fff65ce9129164b6ef30 is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 08:49:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 08:49:12 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.1c171be42a31ce52b81bdfec279460ce@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Elieux): I don't know much real-world code in GHC on Windows, so this may be a moot point, but please consider compatibility with existing libraries before going for the numbered CRTs. See https://msdn.microsoft.com/en- us/library/ms235460(v=vs.100).aspx for possible issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 08:54:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 08:54:38 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.21db9787c21c4163c2f89cf32e3f4510@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yeah, It's not on the top of the list of possible solutions for sure. I have another thing I want to try next, instead of linking in `libmingw32.a` to get `__mingw_raise_matherr` I can just inline the definition of `__mingw_raise_matherr` in the `rts` and export the symbol as a **weak** symbol. That way you can still link to `libmingw32` if you want to and thus override it, but I don't need to link in everything else including the kitchen sink to use `libmingwex`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 09:14:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 09:14:44 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.ce9d28201d7d39efe346d9bc67936861@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): {{{ 1e041b7382b6aa329e4ad9625439f811e0f27232 is the first bad commit commit 1e041b7382b6aa329e4ad9625439f811e0f27232 Author: Simon Peyton Jones Date: Tue Dec 1 17:38:23 2015 +0100 Refactor treatment of wildcards This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 09:47:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 09:47:16 -0000 Subject: [GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) Message-ID: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: ARMv7 | Operating System: Linux Architecture: arm | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On IMX53 Quick Start board http://www.nxp.com/products/interface-and-connectivity/interface-and- system-management/switch-monitoring-ics/i.mx53-quick-start-board:IMX53QSB With Debian Jessie I'm installing: https://www.haskell.org/ghc/download_ghc_7_10_2#linux_armv7 ghc-7.10.2-arm-unknown-linux.tar.xz (108 MB) When I compile simple program as: import System.IO main = putStrLn "Hello World in ARM!" and then compile and run I got: "Illegal instruction" message When we debug it it seems that there is missing end of function and going straight into main function without changing to ARM Thumb instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 10:46:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 10:46:40 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.cfca95f917129d4205029ce80a68abd9@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) Comment: Simon, I believe this may be the result of your wildcards rework. The issues appears to be that classes' `tcdSigs` have no useful signatures by the time it gets to Haddock (namely `ppClassDecl`). If my debug output is to be believed `tcdSigs` contains only `MinimalSig`s., -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 10:50:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 10:50:18 -0000 Subject: [GHC] #11191: provide `make uninstall` In-Reply-To: <042.5746e3abd3ed92aad05386db98c39033@haskell.org> References: <042.5746e3abd3ed92aad05386db98c39033@haskell.org> Message-ID: <057.141f32f70d57c2a510be4c199db8f3c6@haskell.org> #11191: provide `make uninstall` -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: Resolution: | Keywords: installation 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): * priority: normal => low * component: Compiler => Build System Comment: This better wait till after the Shake rewrite of the build system, so we don't have to port it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 10:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 10:52:26 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.95489cf801a524d25ce376189036cffd@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems the relevant signatures are being dropped by `Haddock.Interface.Create.filterClasses` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 10:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 10:57:09 -0000 Subject: [GHC] #11204: Recompilation checking stochastically broken on Darwin In-Reply-To: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> References: <046.1f7a377d03b083204ea2de0ffed0ea61@haskell.org> Message-ID: <061.a4bc3050a750c5c8023269007b55170c@haskell.org> #11204: Recompilation checking stochastically broken on Darwin ----------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+---------------------------------------- Changes (by thomie): * component: Compiler => Driver Comment: If it is stochastically broken, marking it `expect_broken` will only help to pass validate some of the time. Better skip it altogether on OS X, with a comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:03:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:03:04 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind Message-ID: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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: -------------------------------------+------------------------------------- I was playing around with the cool new `-XTypeInType` stuff when I encountered the following issue: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE GADTs #-} module TypeInTypeBug where import qualified Data.Kind -- This works, using Data.Kind.Type as return kind --------------vvvvvvvvvvvvvv data Works :: Data.Kind.Type where WorksConstr :: Works type Set = Data.Kind.Type -- This doesn't work, using a type synonym for Data.Kind.Type as return kind ---------------vvv data Doesnt :: Set where DoesntConstr :: Doesnt }}} {{{ TypeInTypeBug.hs:17:1: error: ? Kind signature on data type declaration has non-* return kind Set ? In the data declaration for ?Doesnt? }}} I suppose type synonyms should be expanded in the return kind of a data type declaration before checking it is `*`. I also think the error message is not totally correct, take the following '''valid''' data declaration: {{{#!hs data Foo :: Bool -> Data.Kind.Type where Tru :: Foo True Fal :: Foo False }}} The return kind of the data declaration is actually `Bool -> Data.Kind.Type` (or `Bool -> *`), which is not `*`. I assume the error message is talking about the return kind (`*`) of the return kind (`Bool -> *`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:10:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:10:25 -0000 Subject: [GHC] #11205: Validation on ARM fails to due Corex-A8 erratum check In-Reply-To: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> References: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> Message-ID: <061.f35f225fcc2ca2d941b360ae346b2e94@haskell.org> #11205: Validation on ARM fails to due Corex-A8 erratum check ---------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1599 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by thomie): bindist preparation does not strip binaries. If you find that it does, then that is a bug, and I'd like to know which file in `bindistprep/` is stripped. validate also tries to **install** the binary distribution, by running 'make install'. Since it doesn't run 'make install-strip', it won't strip the installed executables (ghc, ghc-pkg, haddock, etc.). Whether it strips libraries (.a and .so files) should depend on the setting of STRIP_CMD. There could be a bug here, maybe in Cabal. It would help to know which file in `bindisttest/` is stripped after running `./validate`, when `STRIP_CMD=:`. Make sure you're using HEAD, not ghc-7.10. Stripping was broken before (see ticket:1851#comment:16). ticket:10601#comment:4 is also relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:18:50 -0000 Subject: [GHC] #8424: quasi-quotes have carriage returns on Windows In-Reply-To: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> References: <048.22a0e52e93667b75ca5f688b556e6150@haskell.org> Message-ID: <063.fe8202bfd32080a98460932b98d0274d@haskell.org> #8424: quasi-quotes have carriage returns on Windows -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11215 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate Comment: refold says in #11215: Yes, #8424 seems to be the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:27:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:27:14 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.a03b587d1c78134df49a95d883c87c92@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Right. To typecheck a program involving `P` we absolutely need to know the universal/existential split. Above, I was thinking that we could use the pattern type signature to specify the "shape" of the type, but work out the univ/existential split from the definition itself. A bit like a type with wildcards. But that would mean that you could not typecheck uses of a pattern synonym solely from its signature; because the signature does not say enough. Like wildcards, inference would be involved. But that's obviously unsatisfactory; for example, you could not put a pattern synonym signature in a hs-boot file. So, if we want signatures to be fully precise (i.e. say everything), and I think that is a solidly good goal, we'd need to require the user to specify the required/provided split for type variables too. Terminology: * "Universal" for type variables lines up with "required" for the constraints * "Existential" for type variables lines up with "provided" for the constraints Now, we need syntax for expressing the split. I suppose we can use the same nested structure as we do for required/provided, like this: {{{ pattern type P1 :: forall a. a -> T a -- a is universal pattern type P2 :: forall a. Eq a => a -> T -- a is universal, (Eq a) is required pattern type P3 :: forall a. Eq a => -- a is universal, (Eq a) is required forall b. a -> b -> T a -- b is existential pattern type P3 :: forall a. Eq a => -- a is universal, (Eq a) is required forall b. Ord b => -- b is existential, (Ord b) is provided a -> b -> T a }}} Note: * I think we could safely leave out the leading (universal) `forall`, in the usual way. That is, the free vars of the entire type are considered universal. * You can never leave out the existential forall, if it binds any variables. * How can you distinguish the existential forall if the universal forall and context are absent? Only by putting in the universal forall or the required context; e.g. {{{ pattern type P5 :: forall. forall b. b -> T pattern type P6 :: () => forall b. b -> T }}} The only downside of this is that you might say that given {{{ pattern type P :: a -> (a->Int) -> T }}} the `a` is almost certain to be existential. After all this is the type we'd give to a data constructor: {{{ data T where MkT :: (a->Int) -> a -> T }}} So why do we need explicitly-specified existentials in a pattern synonym, but not in a data constructor? Because a view pattern could make it universal. Degenerately in this case: {{{ pattern Q :: a -> (a->Int) -> String pattern Q x y <- (odd_fun -> (x,y)) odd_fun :: String -> (a, a->Int) odd_fun _ = (undefined, const 2) }}} Conclusion: we need the possibility of explicitly-specified existentials. However, rather than insisting that you always specify the existential forall, here is a rule that would catch the common cases: if you don't specify the existential `forall`, you get: * the free vars of the arg-tys * plus the free vars of the provided constraints (if any), * minus * the universal forall'd vars, if there is a universal `forall` * or the free vars of the result ty, plus required constraints (if any), otherwise If neither `forall` is given, we compute the existential variables using the above rule; then the universals are the remaining free variables. So in the signatures that started this ticket {{{ pattern Q1 :: () => Read a => a -> String pattern Q2 :: Read a => a -> String }}} would behave as if you had written {{{ pattern Q1 :: () => forall a. Read a => a -> String pattern Q2 :: forall a. Read a => a -> String }}} The advantage of this rule is that is allows you to omit both `forall`s in all but the most degenerate cases like `Q` above. How does that sound? I think it is more or less what Richard was proposing in comment:8, but it's taken me a while to catch up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:31:19 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags In-Reply-To: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> References: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> Message-ID: <057.8664c1c5b375814af9f81f9de6aa0ffc@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 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:D1613 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"2206fa8cdb1209320f3690690b610320b4810de6/ghc" 2206fa8c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2206fa8cdb1209320f3690690b610320b4810de6" Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags This also updates the user's guide to refer to the `-W`-based warning flags by default. Quoting the release note entry: | Warnings can now be controlled with `-W(no-)...` flags in addition to | the old `-f(no-)warn...` ones. This was done as the first part of a | rewrite of the warning system to provide better control over warnings, | better warning messages, and more common syntax compared to other | compilers. The old `-fwarn...`-based warning flags will remain | functional for the forseeable future. This is part of https://ghc.haskell.org/wiki/Design/Warnings and addresses #11218 Reviewed By: hvr, bgamari Differential Revision: https://phabricator.haskell.org/D1613 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:32:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:32:51 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.184b4d496c2c9e702b56c66b9bdbc577@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:36:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:36:58 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags In-Reply-To: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> References: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> Message-ID: <057.c1c14c412892cbb432242711adf3d6c6@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 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:D1613 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:37:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:37:58 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.2e3a7f4668947bcd53d3497670dadfcf@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In particular I believe the issue is `isVanillaLSig`, which returns `False` for `ClassOpSig`s. Unfortunately doing the obvious thing and letting it return `True` reveals further issues which I am gradually working through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:39:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:39:08 -0000 Subject: [GHC] #11229: splitLHsForAllTy not exported from HsTypes In-Reply-To: <046.624b073c8cd31d66a3833165e0389f8f@haskell.org> References: <046.624b073c8cd31d66a3833165e0389f8f@haskell.org> Message-ID: <061.91da6df33c41f481d277bdae3bd7eab1@haskell.org> #11229: splitLHsForAllTy not exported from HsTypes -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHC API | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: splitLHsInstDeclTy_maybe doesn't exist anymore. compiler/hsSyn/HsTypes.hs does export `splitLHsForAllTy`. Change was made in 1e041b7382b6aa329e4ad9625439f811e0f27232. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:46:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:46:30 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.11e779368f6f4dba8f0692a4e326c7de@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is mysterious indeed. If the other sigs were really getting dropped, ''nothing'' would work. Ah, here's a possibility. The `tcdSigs` for classes used to contain a `TypeSig` for each method, but now it contains a `ClassOpSig`. Maybe Haddock is expecting the former but only finding the latter? In `Haddock.Interface.Create` I see `typeDocs` which might be lacking a `ClassOpSig` case. Possibly also elsewhere in Haddock? Does that give you enough to go on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:49:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:49:45 -0000 Subject: [GHC] #10639: Tight (non-allocating) loop freezes the scheduler In-Reply-To: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> References: <048.3130b8c9dae40d4cc95f52d78c185152@haskell.org> Message-ID: <063.c1f777423feb48f555ffd1ed8cba092b@haskell.org> #10639: Tight (non-allocating) loop freezes the scheduler -------------------------------------+------------------------------------- Reporter: gizmo.mk0 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #367 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * differential: Phab:D1127 => * resolution: => duplicate * related: => #367 Comment: The documentation has been improved. #367 is still open, with milestone bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:57:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:57:32 -0000 Subject: [GHC] #5775: Inconsistency in demand analysis In-Reply-To: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> References: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> Message-ID: <056.6bfb7a528dd9d0acd9cd5ab09f63ce9f@haskell.org> #5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.5 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 bgamari): * priority: normal => high * owner: => bgamari * milestone: 8.0.1 => 8.2.1 Old description: > A small program: > > {{{ > {-# LANGUAGE MagicHash, UnboxedTuples #-} > module U where > import GHC.Prim > import GHC.Types > > idx :: Addr# -> Int -> Int > {-# INLINE idx #-} > idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y > > f :: Int -> Int -> Int > {-# INLINE f #-} > f x y = y + x > > foo :: Addr# -> Int -> Int > foo a n = n `seq` loop (idx a 0) 1 > where > loop x i = case i >= n of > False -> loop (f x (idx a i)) (i+1) > True -> x > }}} > > GHC infers the demand `LU(L)` for `loop`, only unboxes the second > argument, ultimately generates a loop of type `Int -> Int# -> Int` and > always allocates a thunk for the first argument: > > {{{ > $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int > [LclId, Arity=2, Str=DmdType LL] > $wloop_si9 = > \ (w1_shU :: Int) (ww1_shX :: Int#) -> > case >=# ww1_shX ww_si5 of _ { > False -> > $wloop_si9 > (case readIntOffAddr# @ RealWorld w_si2 ww1_shX > realWorld# > of _ { (# _, y_a9S #) -> > case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) } > }) > (+# ww1_shX 1); > True -> w1_shU > }; } > }}} > > But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` > gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as > well as the result, producing a nice tight loop: > > {{{ > $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int# > [LclId, Arity=2, Str=DmdType LL] > $wloop_sii = > \ (ww1_shW :: Int#) (ww2_si0 :: Int#) -> > case >=# ww2_si0 ww_sib of _ { > False -> > case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld# > of _ { (# _, y1_Xac #) -> > case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin -> > $wloop_sii ww3_Xin (+# ww2_si0 1) > } > }; > True -> ww1_shW > }; } > }}} > > It would be nice if this happened in both cases. New description: A small program: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} module U where import GHC.Prim import GHC.Types idx :: Addr# -> Int -> Int {-# INLINE idx #-} idx a (I# i) = case readIntOffAddr# a i realWorld# of (# _, y #) -> I# y f :: Int -> Int -> Int {-# INLINE f #-} f x y = y + x foo :: Addr# -> Int -> Int foo a n = n `seq` loop (idx a 0) 1 where loop x i = case i >= n of False -> loop (f x (idx a i)) (i+1) True -> x }}} GHC infers the demand `LU(L)` for `loop`, only unboxes the second argument, ultimately generates a loop of type `Int -> Int# -> Int` and always allocates a thunk for the first argument: {{{#!hs $wloop_si9 [Occ=LoopBreaker] :: Int -> Int# -> Int [LclId, Arity=2, Str=DmdType LL] $wloop_si9 = \ (w1_shU :: Int) (ww1_shX :: Int#) -> case >=# ww1_shX ww_si5 of _ { False -> $wloop_si9 (case readIntOffAddr# @ RealWorld w_si2 ww1_shX realWorld# of _ { (# _, y_a9S #) -> case w1_shU of _ { I# y1_ahb -> I# (+# y_a9S y1_ahb) } }) (+# ww1_shX 1); True -> w1_shU }; } }}} But if I change the pragma on `f` from `INLINE` to `NOINLINE`, `loop` gets the demand `U(L)U(L)m` and GHC manages to unbox both arguments as well as the result, producing a nice tight loop: {{{#!hs $wloop_sii [Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId, Arity=2, Str=DmdType LL] $wloop_sii = \ (ww1_shW :: Int#) (ww2_si0 :: Int#) -> case >=# ww2_si0 ww_sib of _ { False -> case readIntOffAddr# @ RealWorld w_si8 ww2_si0 realWorld# of _ { (# _, y1_Xac #) -> case f (I# ww1_shW) (I# y1_Xac) of _ { I# ww3_Xin -> $wloop_sii ww3_Xin (+# ww2_si0 1) } }; True -> ww1_shW }; } }}} It would be nice if this happened in both cases. -- Comment: For the record this is still reproducible with GHC 7.10.3. It sounds like this ought to be revisited (if for no other reason than to ensure that the fragility really is only exposed with `unsafePerformIO`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 11:59:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 11:59:50 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.05bb992e0935a19669ff619c6514cbe0@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: jstolarek Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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): Phab:D1636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: goldfire => jstolarek * differential: => Phab:D1636 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 12:12:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 12:12:04 -0000 Subject: [GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input In-Reply-To: <045.aefffb38475deae13a93b03d7772087f@haskell.org> References: <045.aefffb38475deae13a93b03d7772087f@haskell.org> Message-ID: <060.054d58814f054c3da79151c8f7a17fcf@haskell.org> #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): What is the suggested alternative behavior? Fail when detecting that two output filenames would be the same, or just warn that something looks fishy? Presumably handling the situation gracefully (e.g. linking the two object files together, or choosing a different output file name) is out of the question. This is just one of a number of ways to shoot oneself in the foot with poorly named input files (try compiling both `Foo.hs` and `Foo.lhs` in the same command for a good time), so I don't think it is worth investing much complexity here. The more important issue is to keep the compiler's behavior (i.e. "`Foo.hs` gets compiled to `Foo.o` and `Foo.hi`, clobbering the existing files) predictable enough that the user can be expected to reason about it and not get themselves into situations such as this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 12:21:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 12:21:11 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.1aecdd6d6143ebed57d436ed2024f381@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:10 simonpj]: > Ah, here's a possibility. The `tcdSigs` for classes used to contain a `TypeSig` for each method, but now it contains a `ClassOpSig`. Maybe Haddock is expecting the former but only finding the latter? Indeed, I've worked that much out and I've found all of the obvious places where this needs to be accounted for. Unfortunately it seems I'm missing one of the non-obvious ones. For those playing along at home I'm working [[http://github.com/bgamari/haddock/tree/work|here]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 12:37:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 12:37:44 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.62a54da03c5dca75f64a39f7f2c48050@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Found it. Patches coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 12:48:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 12:48:31 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.68cd807c9bd42da93fb90afe4da8ef4a@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): simonpj, could you comment on the intended purpose of `isVanillaLSig`? It seems that it is only used by Haddock and is terribly named. I was thinking of either moving it to Haddock, renaming it to `isUserLSig` (e.g. "did the user provide this signature?") or both. Comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 12:55:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 12:55:01 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.99e2e86f78b60679ccf697957e247674@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If I understand correctly, Simon's comment:24 proposes precisely this, copied from comment:8: * Allow explicit quantification in two places, according to this schema: {{{ pattern type Syn :: forall <>. <> => forall <>. <> => <> -> <> }}} * In the absence of explicit quantification, universals are inferred to be the variables mentioned in either the result or the required context. Existentials are the remaining variables. * It is against the rules for existentials to shadow universals. Simon, do you agree that we're saying the same thing? If so, then let's do it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:12:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:12:40 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.e7bd4b16fe84d9babdb63f56f8454af6@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:13 bgamari]: > simonpj, could you comment on the intended purpose of `isVanillaLSig`? It seems that it is only used by Haddock and is terribly named. I was thinking of either moving it to Haddock, renaming it to `isUserLSig` (e.g. "did the user provide this signature?") or both. It is ''only'' used in Haddock. I have no idea what it's for. By all means move it, rename it, whatever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:39:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:39:02 -0000 Subject: [GHC] #8347: Add a Strict LANGUAGE pragma In-Reply-To: <044.d01bb368b2606104539d1aa05530b018@haskell.org> References: <044.d01bb368b2606104539d1aa05530b018@haskell.org> Message-ID: <059.5cafdc615b283989c2452c7d9b8a82ed@haskell.org> #8347: Add a Strict LANGUAGE pragma -------------------------------------+------------------------------------- Reporter: tibbe | Owner: adamse Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: DsStrictData, | DsStrictLet, DsStrictFail, | DsStrictWarn Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1033, Wiki Page: | Phab:D1142 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: DsStrictData => DsStrictData, DsStrictLet, DsStrictFail, DsStrictWarn * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:40:40 -0000 Subject: [GHC] #11083: Documentation clarification for Data.List.isSubsequenceOf In-Reply-To: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> References: <043.e69eb5fdb16ef2a225fec4c141703786@haskell.org> Message-ID: <058.ff4d85dcbb65fd5c90abf6bfdf4e99b9@haskell.org> #11083: Documentation clarification for Data.List.isSubsequenceOf -------------------------------------+------------------------------------- Reporter: jura | Owner: jura Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.2 Resolution: fixed | Keywords: Data.List, | isSubsequenceOf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1477 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Thanks Justin! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:41:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:41:27 -0000 Subject: [GHC] #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported In-Reply-To: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> References: <042.75105e05b4b7229d1c36f2c44b9a694f@haskell.org> Message-ID: <057.543b18325606752c29eef1d255777790@haskell.org> #11102: `ghc --supported-extension` shall not list `TemplateHaskell` when unsupported -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | 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): phab:D1484 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:44:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:44:50 -0000 Subject: [GHC] #11164: No way to import a data instance In-Reply-To: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> References: <048.66bb5a0592ca502eaab5a966947bb882@haskell.org> Message-ID: <063.f0fc6e3a5e82555748cad73c82e36c1c@haskell.org> #11164: No way to import a data instance -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: kanetw Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T11164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D1573, Wiki Page: | phab:D1587 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => rename/should_compile/T11164 * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 Comment: KaneTW wrote the patch and the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 13:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 13:51:28 -0000 Subject: [GHC] #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags In-Reply-To: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> References: <042.5138e0455eb0351e3f3bc2c4f57c2ed1@haskell.org> Message-ID: <057.6a7de01d09e0b519000b482b9e895a80@haskell.org> #11218: Provide `-W(no-)` aliases for `-f(no-)warn` warning flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 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:D1613 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"437ebdda48e7a32fe1bea49cb503f456a0152a36/ghc" 437ebdd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="437ebdda48e7a32fe1bea49cb503f456a0152a36" Start using `-W` instead of `-f(no-)warn` in some places This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases introduced via 2206fa8cdb120932 / #11218, in cases which are guaranteed to be invoked with recent enough GHC (i.e. the stage1+ GHC). After this commit, mostly the compiler and the testsuite remain using `-f(wo-)warn...` because the compiler needs to be bootstrappable with older GHCs, while for the testsuite it's convenient to be able to quickly compare the behavior to older GHCs (which may not support the new flags yet). The compiler-part can be updated to use the new flags once GHC 8.3 development starts. Reviewed By: quchen Differential Revision: https://phabricator.haskell.org/D1637 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:01:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:01:06 -0000 Subject: [GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) In-Reply-To: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> References: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> Message-ID: <060.30f649e5d8d40936d5e212cc03ba53bf@haskell.org> #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: ARMv7 Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What version of LLVM are you using? You definitely need 3.5.2 as there were GHC calling convention-related bug fixes in that version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:18:37 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems Message-ID: <047.b64204058d590ba33e44f36f6140b2e6@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 | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Linux Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to follow up on my comment on #11042. Let's give dynamic linking on ELF systems a second chance. I propose the following steps: 1. Collect required features 1. Write up and discuss and agree on a specification 1. Create regression tests for all features 1. Design and implement a new dynamic linker for GHCi 1. (optional) Make it work on Mac OS X too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:18:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:18:41 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.31a7a8ad6263074871f28ec9820d2486@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:19:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:19:00 -0000 Subject: [GHC] #10927: IndexError: pop from empty list In-Reply-To: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> References: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> Message-ID: <060.5ff55872cdfe872087591ac40c6fbdd8@haskell.org> #10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 thomie): To reproduce: * go to preferences, and change the language to German: https://ghc.haskell.org/trac/ghc/prefs * try to attach an attachment to a ticket * You will get the 'IndexError: pop from empty list' error Workaround: keep the default language. Upstream ticket: http://trac.edgewall.org/ticket/11184 Cause: bug in Genshi library, versions 0.6.1 and 0.7.0 (they are maintaining 0.6.x and 0.7.x release lines in parallel). Solution: downgrade to Genshi version 0.6 (versions 0.6.2 and 0.7.1 are not released yet) How: `sudo easy_install Genshi==0.6` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:39:28 -0000 Subject: [GHC] #11147: GHC 7.10.3 does not compile on NixOS In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.a5f2f84e755b7d9deac813fd6f2ffc24@haskell.org> #11147: GHC 7.10.3 does not compile on NixOS ----------------------------------------+---------------------------------- Reporter: waern | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by rwbarton): It's not librt that isn't being linked, it's libpthread. The eventual issue is here: {{{ "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist- install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -package-key conta_2C3ZI8RgPO2LBMidXKTvIU -package-key direc_0hFG6ZxK1nk4zsyOqbNHfm -package-key filep_Ey7a1in9roBAE8bUFJ5R9m -package-key proce_52AgREEfSrnJLlkGV9YZZJ -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist- install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs /dist-install/build -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/process/dist-install/build' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/directory /dist-install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/unix/dist-install/build' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/time/dist- install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/filepath/dist-install/build' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/containers /dist-install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/bytestring/dist-install/build' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/deepseq/dist- install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/array/dist-install/build' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/base/dist- install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/libraries/integer-gmp2/dist-install/build' -optl-L'/nix/store/blp0hymd8i8m1v4cjcrkacbh6cw6ia8d-gmp-5.1.3/lib' -optl-L'/tmp/nix-build-ghc-7.10.3.drv-0/ghc-7.10.3/libraries/ghc-prim /dist-install/build' -optl-L'/tmp/nix-build- ghc-7.10.3.drv-0/ghc-7.10.3/rts/dist/build' -optl-lrt -optl-lutil -optl- ldl -optl-lgmp -optl-lm -optl-lrt -optl-ldl -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist- install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package-key base_HQfYBxpPvuw8OunzQu6JGM -package-key conta_2C3ZI8RgPO2LBMidXKTvIU -package-key direc_0hFG6ZxK1nk4zsyOqbNHfm -package-key filep_Ey7a1in9roBAE8bUFJ5R9m -package-key proce_52AgREEfSrnJLlkGV9YZZJ -XHaskell2010 -no-user-package-db -rtsopts -fno-use-rpaths -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../proce_52AgREEfSrnJLlkGV9YZZJ' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../direc_0hFG6ZxK1nk4zsyOqbNHfm' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../unix_KZL8h98IqDM57kQSPo1mKx' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../time_FTheb6LSxyX1UABIbBXRfn' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../filep_Ey7a1in9roBAE8bUFJ5R9m' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../conta_2C3ZI8RgPO2LBMidXKTvIU' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../bytes_6VWy06pWzJq9evDvK2d4w6' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../deeps_6vMKxt5sPFR0XsbRWvvq59' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../array_67iodizgJQIIxYVTp4emlA' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../base_HQfYBxpPvuw8OunzQu6JGM' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../integ_2aU3IZNMF9a7mQ0OzsZ0dS' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../ghcpr_8TmvWUcS1U1IKHT0levwg3' -optl- Wl,-rpath -optl-Wl,'$ORIGIN/../rts' -optl-Wl,-zorigin utils/hsc2hs/dist- install/build/Main.dyn_o utils/hsc2hs/dist-install/build/C.dyn_o utils/hsc2hs/dist-install/build/Common.dyn_o utils/hsc2hs/dist- install/build/CrossCodegen.dyn_o utils/hsc2hs/dist- install/build/DirectCodegen.dyn_o utils/hsc2hs/dist- install/build/Flags.dyn_o utils/hsc2hs/dist-install/build/HSCParser.dyn_o utils/hsc2hs/dist-install/build/UtilsCodegen.dyn_o utils/hsc2hs/dist- install/build/Paths_hsc2hs.dyn_o /nix/store/5kdjp8200hazaydx0dmwn5qghqkyi3py-binutils-2.23.1/bin/ld: warning: libpthread.so.0, needed by /nix/store /483br9kb3f5igsgmb6aqsjhl2ipj2bxr-glibc-2.21/lib/librt.so, not found (try using -rpath or -rpath-link) }}} On my working system, `utils/hsc2hs/dist-install/build/tmp/hsc2hs` is built with the option `-optl-lpthread` also, which is missing from the above command line. This flag comes from the `extra-libraries` field of the `unix` package, which is populated from the configure variable `EXTRA_LIBS` via `libraries/unix/unix.buildinfo.in`. On my system `pthread` is added to that variable by this from `configure.ac`: {{{ AC_SEARCH_LIBS(sem_close, pthread, [EXTRA_LIBS="$EXTRA_LIBS $ac_lib"], [AC_MSG_NOTICE([Not found])]) }}} but in your `libraries/unix` configure output I see {{{ checking for library containing sem_close... none required }}} so that explains why later `-optl-pthread` is not provided when building `utils/hsc2hs/dist-install/build/tmp/hsc2hs`. I don't understand why on your Nix system configure apparently detected that `-lpthread` is not needed for the symbol `sem_close`. Apparently it was wrong about that. I also have no idea what this has to do with the commit that apparently broke things for you. (I am building the tip of the ghc-7.10 branch, so I also have that commit.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 14:43:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 14:43:55 -0000 Subject: [GHC] #9306: Crash when shifting Integers too far left In-Reply-To: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> References: <045.adea722a17a4f73cbf1c7383cbcb4d04@haskell.org> Message-ID: <060.ee418df751e3381b69faeeebac17584f@haskell.org> #9306: Crash when shifting Integers too far left -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #10571 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10571 Comment: Fixed in #10571. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:00:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:00:17 -0000 Subject: [GHC] #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 In-Reply-To: <045.d05a83ce5d196096a6368324dde68686@haskell.org> References: <045.d05a83ce5d196096a6368324dde68686@haskell.org> Message-ID: <060.c0c8dda193dbc61733e620360bdb770a@haskell.org> #9304: Floating point woes; Different behavior on 32- vs 64-bit x86 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: floating | point Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9276 * blockedby: 9276 => Comment: Replying to [comment:30 lerkok]: > Maybe it can be merged with @carter's ticket #9276, and addressed within that context. Ok. #9276 contains a link back to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:01:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:01:02 -0000 Subject: [GHC] #9276: audit ghc floating point support for IEEE (non)compliance In-Reply-To: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> References: <045.ad291164c8d6795bec19bab0953045e8@haskell.org> Message-ID: <060.a3ac8582638247d2fc6849e932a221aa@haskell.org> #9276: audit ghc floating point support for IEEE (non)compliance -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3070, 8364, | 9530 Related Tickets: #9304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9304 Comment: See also #9304. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:03:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:03:15 -0000 Subject: [GHC] #9298: ghc.exe: internal error: evacuate: strange closure type 365488164 In-Reply-To: <049.d765684266b06afdaa0f98beceafc02b@haskell.org> References: <049.d765684266b06afdaa0f98beceafc02b@haskell.org> Message-ID: <064.769145c63dafa327095bdec4ece42d87@haskell.org> #9298: ghc.exe: internal error: evacuate: strange closure type 365488164 ---------------------------------------+---------------------------------- Reporter: Tominator2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+---------------------------------- Changes (by thomie): * status: new => infoneeded * keywords: idris => Comment: Can you try again with ghc-7.10.3 or ghc-8 (as of yet, unreleased). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:07:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:07:49 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD Message-ID: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first invocation of a freshly built `inplace/bin/deriveConstants` hangs when I am bootstrapping HEAD with HEAD. Last proven good git revision: d25f3c076e6c47bc7c8d0d27e724a3ad2b7d7399 Broken revision: 0dd61fe72144a829a9e5bb87a1094244e53cdebb There are only a few revisions in between. Notably: {{{ commit 8a506104d5b5b71d5640afc69c992e0af40f2213 Author: George Karachalias Date: Thu Dec 3 12:57:19 2015 +0100 Major Overhaul of Pattern Match Checking (Fixes #595) ... }}} Incidentally there are a few known performance regressions from that commit, so maybe the bootstrap process is bitten by it. I am not sure whether `deriveConstants` really hangs or just takes ages to complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:14:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:14:59 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.33b3800f18313adf5458201ae6a483ae@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Seems related to #11195? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:27:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:27:42 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.226a36f9c7fce1273f1ccfd96d10cf89@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:1 mpickering]: > Seems related to #11195? From a quick glance that describes a compile-time regression, while my report seem to be a runtime regression (or miscompilation). But the two may well have the same root cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:34:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:34:41 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.362f4f3d8e96aa6835d343456aa8b51e@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): If it is related to #11195, I may have the solution real soon. Since the additional expressivity about guards came with a big price, we will have a flag (or more) for more precise control over how hard the checker tries to reason about pattern matching. At the moment, with `-Wall` we enable the whole check, no matter what the cost is. I expect to have the patch before the end of the week, and I hope it fixes this along with #11195. If you have any more information about the file that causes the problem please let me know! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 15:49:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 15:49:48 -0000 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> References: <044.a73c522b97030f99c5fa39d521657f06@haskell.org> Message-ID: <059.574c96c5b5b9a294ed481bf1bbdb8f2b@haskell.org> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.5 (Linker) | Keywords: Resolution: | getEnvironment Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: | getEnvironment01 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal Comment: Lowering priority, because this is only a problem when GHC is built with `DYNAMIC_GHC_PROGRAMS=NO` (the default is `YES`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:03:17 -0000 Subject: [GHC] #4945: Another SpecConstr infelicity In-Reply-To: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> References: <053.dd99f570cc6450886c16aa213467aa21@haskell.org> Message-ID: <068.ec799787c9d088c4bca6ce641187ba14@haskell.org> #4945: Another SpecConstr infelicity -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T4945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal Comment: To summarise: test T4945 is failing. Lowering priority, because it is just some (-O2) runtime performance issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:28:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:28:03 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.f8fefe56d96fb611965e95befb0d289d@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Rev(s): Phab:D1059, Wiki Page: | Phab:D1085 -------------------------------------+------------------------------------- Changes (by thomie): * priority: high => normal * component: Compiler => Test Suite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:29:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:29:47 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.73a809a943113c56fde1ba33512bc396@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries | Version: (other) | Resolution: | Keywords: stm 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): * priority: high => highest Comment: This should not be forgotten. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:40:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:40:44 -0000 Subject: [GHC] #11137: configure is broken for the unix package In-Reply-To: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> References: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> Message-ID: <057.1f7f16ac2868d511bf248c03adc6d0ab@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: libraries/unix | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ab79ed763cfbaa1b0d1f39ba5ed1cde7dffd4b87/ghc" ab79ed76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab79ed763cfbaa1b0d1f39ba5ed1cde7dffd4b87" Improve detection of `fdatasync(2)` (re #11137) This updates the `unix` submodule to pull in an improved Autoconf test for `fdatasync(2)` in cases where `` lacks a declaration, but linking against `fdatasync` works which led to a false positive previously. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:42:13 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.d0f8c9ea8bf497b1011265817a95f857@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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:D1641 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D1641 Comment: This one is fixed. Just validating on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 16:59:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 16:59:13 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.9f4db463ff4a42a7de3b1329125a6790@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11237 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * testcase: => typecheck/should_compile/T11237 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:07:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:07:15 -0000 Subject: [GHC] #10833: Use injective type families when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.86d2f0157f1ab10d0a4a0eaa025f26ab@haskell.org> #10833: Use injective type families when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => Comment: In the "Injective Type Families for Haskell" we did not present a full proof of soundness of injective type families. It might be the case that the proof requires solving [[http://www.win.tue.nl/rtaloop/problems/79.html|RTA #79]]. But we don't know for sure. Richard argues that for this reason we should not make these changes to Core - if our conjecture that our proof holds turns out to be incorrect Core will become inconsistent. So for the time being I am abandoning further work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:10:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:10:25 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.940474760783b2b05fb8cce2e34d71a7@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11237 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What commit fixed this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:11:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:11:12 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.47199b4eeda5ec6fbe0d1081d5fd54ca@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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 jstolarek): Richard, I believe you claimed this is fixed. But I don't see any assertions in [[GhcFile(compiler/prelude/THNames.hs)]]. Is the assertion somewhere else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:13:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:13:54 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.ce41bc8e869e91e6e386a08c2cd9b978@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11237 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"efaa51de15017b92618634898fc2c2aee2c5fd5b/ghc" efaa51de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efaa51de15017b92618634898fc2c2aee2c5fd5b" Look through type synonyms in GADT kind signatures Summary: Fixes #11237 Test Plan: ./validate Reviewers: goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1636 GHC Trac Issues: #11237 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:15:05 -0000 Subject: [GHC] #11237: Type synonyms are not expanded in the data type declaration return kind In-Reply-To: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> References: <046.35b35e6cfac78dcdb5c2049d1c4f7059@haskell.org> Message-ID: <061.deca3fd40131fd23b989a726982b3cf3@haskell.org> #11237: Type synonyms are not expanded in the data type declaration return kind -------------------------------------+------------------------------------- Reporter: thomasw | Owner: jstolarek Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11237 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:4 simonpj]: > What commit fixed this? Forgot to push :-) Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:22:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:22:43 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.03830be0b583628d33e9867691d99f87@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:23:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:23:09 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.a8f1cfea57da1c9ea1c9d1ff034dfdf9@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:23:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:23:31 -0000 Subject: [GHC] #11067: Spurious superclass cycle error with type equalities In-Reply-To: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> References: <045.f5d44ba3aad0bf1ca48ae450e6c33b15@haskell.org> Message-ID: <060.d83f6230d1295ac027667bea6adfb95d@haskell.org> #11067: Spurious superclass cycle error with type equalities -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11067 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1594 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:29:14 -0000 Subject: [GHC] #10833: Use injective type families when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.be092bf80dff3646f197ddb9c06eaed1@haskell.org> #10833: Use injective type families when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't think this relates to [[http://www.win.tue.nl/rtaloop/problems/79.html|RTA #79]]. (The soundness of type families + `UndecidableInstances` + non-linear patterns does.) Perhaps more sweat on the proof would yield fruit. But somehow it failed to succumb, and so I'm wary of putting it in Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:39:33 -0000 Subject: [GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input In-Reply-To: <045.aefffb38475deae13a93b03d7772087f@haskell.org> References: <045.aefffb38475deae13a93b03d7772087f@haskell.org> Message-ID: <060.5eb3a2b81d9f3aa543bcb553823a1272@haskell.org> #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 ezyang): GHC's behavior is deterministic, and to some degree makes sense, but I don't think it's very transparent to the user. It goes something like: * If hiDir is set, `A.hs` gets compiled to `$hiDir/B.hi` where `B` is the `module` declaration inside the file. * If hiDir is not set, `A.hs` gets compiled to `A.hi`. And then the `.o` files are handled separately (so if you say `ghc --make A.hs -odir foo` where `A.hs` defines `module B` then you'll get `foo/B.o` and `A.hi`). Non-Haskell files operate differently: * If oDir is set, `b/a.c` gets compiled to `$odir/b/a.o`. * If it is not set, `b/a.c` gets compiled to `$odir/b/a.c`. I don't know what the right alternate behavior is. Possibilities: 1. Simply warn when clobbering can occur 2. Designate some uses of the command line as "blessed" and give warnings if you use it otherwise. For example, it would warn if you specify `hiDir` but not `oDir`. Probably should be OK to specify both. I'd like to also warn if you use `outputDir` with a file whose filename doesn't match the module name, but I'm pretty sure Cabal uses this to build exectuables. 3. Interface/object files for Haskell should never be based off of the internal module name; they should always be based off of the source file name. But you have to munge prefixes because you can also have `ghc --make src1/Foo.hs src2/Bar.hs -isrc1 -isrc2`, ugh! Here is a suggested meta-rule: given an object/interface filename, it should be EASY to tell how to build it. I don't know how to achieve that and maintain BC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 17:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 17:41:40 -0000 Subject: [GHC] #10872: More informative assertion for non-unique TH names In-Reply-To: <048.31528093886b2ab66084097b2ba3a854@haskell.org> References: <048.31528093886b2ab66084097b2ba3a854@haskell.org> Message-ID: <063.6d738077be61668b62d9d1fa401dea1c@haskell.org> #10872: More informative assertion for non-unique TH names -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: goldfire Type: task | Status: new Priority: low | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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): It's good you asked. This check exists (in `PrelInfo.knownKeyNames`), but it actually doesn't snag problems in TH. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 18:57:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 18:57:09 -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.0bee351a4a5cfc3e4b6ffe562fdf3cdc@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | 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:25 Phyx-]: > Hi trommler, do you need a static or dynamic lib for the regression test? I built a few dynamic ones myself in `testsuite\tests\ghci\linking\dyn` Thank you very much @Phyx-! That is exactly what I was looking for. Regression test is coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 19:35:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 19:35:17 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.41fcd7b7e69f0997d5c22548fd4362e1@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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 MikeIzbicki): Awesome! I have two comments: 1. One of my use cases is very similar to the code attached below, which causes GHC to loop. The code provides an alternate class hierarchy for comparisons. One of the features of the hierarchy is that `(||)` and `(&&)` can be used directly on functions. Unfortunately, the instances for `(->)` cause GHC to loop. The instances seem like they should work to me. I'm not sure if my reasoning is faulty or if there's a bug in the implementation. 2. I believe there is an incorrect error message. If you take the code below and comment out the line `instance Boolean b => Boolean (a -> b)`, then GHC gives the error message: {{{ [1 of 1] Compiling ClassCycles ( ClassCycles.hs, ClassCycles.o ) ClassCycles.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Set limit with -fsolver-iterations=n; n=0 for no limit WC {wc_simple = [W] $dBoolean_a1KZ :: Boolean (a -> fsk_a1KH) (CDictCan) [D] _ :: Boolean (a -> fsk_a1Ll) (CDictCan)} }}} But when I try to set the limit to something different, GHC complains that the flag doesn't exist: {{{ $ ~/proj/ghc/inplace/bin/ghc-stage2 ClassCycles.hs -fsolver-iterations=10 ghc-stage2: unrecognised flag: -fsolver-iterations=10 Usage: For basic information, try the `--help' option }}} ---- {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableSuperClasses #-} module ClassCycles where import Prelude (Bool(True,False),Integer,Ordering) import qualified Prelude -------------------- -- class hierarchy class Boolean (Logic a) => Eq a where type Logic a :: * (==) :: a -> a -> Logic a class Eq a => POrd a where inf :: a -> a -> a class POrd a => MinBound a where minBound :: a class POrd a => Lattice a where sup :: a -> a -> a class (Lattice a, MinBound a) => Bounded a where maxBound :: a class Bounded a => Complemented a where not :: a -> a class Bounded a => Heyting a where infixr 3 ==> (==>) :: a -> a -> a class (Complemented a, Heyting a) => Boolean a (||) :: Boolean a => a -> a -> a (||) = sup (&&) :: Boolean a => a -> a -> a (&&) = inf -------------------- -- Bool instances -- (these work fine) instance Eq Bool where type Logic Bool = Bool (==) = (Prelude.==) instance POrd Bool where inf True True = True inf _ _ = False instance MinBound Bool where minBound = False instance Lattice Bool where sup False False = False sup _ _ = True instance Bounded Bool where maxBound = True instance Complemented Bool where not True = False not False = True instance Heyting Bool where False ==> _ = True True ==> a = a instance Boolean Bool -------------------- -- Integer instances -- (these work fine) instance Eq Integer where type Logic Integer = Bool (==) = (Prelude.==) instance POrd Integer where inf = Prelude.min instance Lattice Integer where sup = Prelude.max -------------------- -- function instances -- (these cause GHC to loop) instance Eq b => Eq (a -> b) where type Logic (a -> b) = a -> Logic b f==g = \a -> f a == g a instance POrd b => POrd (a -> b) where inf f g = \a -> inf (f a) (g a) instance MinBound b => MinBound (a -> b) where minBound = \_ -> minBound instance Lattice b => Lattice (a -> b) where sup f g = \a -> sup (f a) (g a) instance Bounded b => Bounded (a -> b) where maxBound = \_ -> maxBound instance Complemented b => Complemented (a -> b) where not f = \a -> not (f a) instance Heyting b => Heyting (a -> b) where f ==> g = \a -> f a ==> g a instance Boolean b => Boolean (a -> b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 19:35:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 19:35:29 -0000 Subject: [GHC] #11134: Limit frequency of idle GCs In-Reply-To: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> References: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> Message-ID: <062.324a2be9aca9f6e99d48c02bba55c35f@haskell.org> #11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 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 raichoo): That sounds really useful. I'm having a similar issue with a couple of Haskell processes on a production system. They are not draining that much CPU but they are increasing in numbers and "idling" more and more of the CPUs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 20:15:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 20:15:52 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.0d82218bff90aff108349e5d613ddbaf@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett (added) * status: new => closed * resolution: => invalid Comment: Closing as we don't have an example demonstrating the issue. David, feel free to reopen if you do come upon a testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 20:46:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 20:46:35 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.f4cb357c713488633e5ace595dcdad8b@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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 MikeIzbicki): I've found another suspicious edge case. GHC will loop if you use the same code above, but add the `(/=)` function to the `Eq` class as follows: {{{ class Boolean (Logic a) => Eq a where type Logic a :: * (==) :: a -> a -> Logic a (/=) :: a -> a -> Logic a a/=b = not (a==b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 21:45:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 21:45:59 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.4ebf790c7967ac2f6929f3192491257c@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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 hvr): I just stumbled over an annoying case due to our new `ErrorCall` in GHC 8.0: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Patterns where -- import Control.Exception (ErrorCall(..)) data ErrorCall = ErrorCallWithLocation String String deriving (Eq, Ord) pattern ErrorCall :: String -> ErrorCall pattern ErrorCall err <- ErrorCallWithLocation err _ where ErrorCall err = ErrorCallWithLocation err "" getMsg :: ErrorCall -> String getMsg (ErrorCall y) = y getMsg' :: ErrorCall -> String getMsg' (ErrorCallWithLocation y _) = y }}} With that, GHC HEAD currently warns {{{ patterns.hs:12:1: warning: Pattern match(es) are non-exhaustive In an equation for ?getMsg?: Patterns not matched: _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 21:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 21:58:09 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.cd3b5b6e7dbf6df256c97a6a8936cda7@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gkaracha (added) Comment: CCing George Karachalias, who is responsible for our greatly improved new exhaustiveness checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 21:58:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 21:58:31 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.36db68647c8902561eb48432d1a9fc5a@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Pattern synonyms are great, as they decouple interface from > implementation. Especially if #8581 is also implemented, it should be > possible to change a type completely while retaining the existing > interface. Exciting! > > Another missing piece is exhaustiveness checks. Given this pattern > {{{ > initLast [] = Nothing > initLast xs = Just (init xs, last xs) > pattern xs ::: x <- (initLast -> Just (xs,x)) > }}} > we want the compiler to tell the programmer that > {{{ > f [] = ... > f (xs ::: x) = ... > }}} > is complete, while > {{{ > g (xs ::: x) = ... > }}} > is not. > > With view pattern directly, this is impossible. But the programmer did > not write view patterns! > > So here is what I think might work well, inspired by the new `MINIMAL` > pragma: > > We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). > The syntax is essentially the same as for `MINIMAL`, i.e. a boolean > formula, with constructors and pattern synonyms as atoms. In this case. > > {{{ > {-# COMPLETE_PATTERNS [] && (:::) #-} > }}} > > Multiple pragmas are obviously combined with `||`, and there is an > implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data > constructors. > > When checking for exhaustiveness, this would be done before unfolding > view patterns, and for `g` above we get a warning that `[]` is not > matched. Again, the implementation is very much analogous to `MINIMAL`. > > Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` > pragmas. I think that is ok (like with `MINIMAL`), and generally an > improvement. New description: Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{#!hs initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{#!hs f [] = ... f (xs ::: x) = ... }}} is complete, while {{{#!hs g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{#!hs {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 23:16:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 23:16:48 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.cc4d6a037dc08316d143e118b10556ee@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"6c9258def53008f050e91e6d3e08c4c297392c00/ghc" 6c9258d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c9258def53008f050e91e6d3e08c4c297392c00" Add test for #10897 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 23:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 23:17:06 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.69cd41f31a69334d5b935ce70eb070da@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: patsyn/T10897 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: cactus => * testcase: => patsyn/T10897 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 23:27:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 23:27:30 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.b55e28c544915b8091315043fa6b9e81@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11039 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 23:28:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 23:28:54 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.6d39b90b26575b4da2da97e894961565@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): There is still some good stuff in here which would make tests. There is still the panic which is reported as #11039. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 16 23:42:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Dec 2015 23:42:26 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym In-Reply-To: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> References: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> Message-ID: <062.49848a7611a633a4a6eb85b4fad0e814@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | PatternSynonyms 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 mpickering): * owner: => mpickering Comment: I will do this. I should wait for Simon to finish on #11224. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 03:55:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 03:55:25 -0000 Subject: [GHC] #11190: Hello "schedule: re-entered unsafely." In-Reply-To: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> References: <046.b95fb11cf41c10514ffcaffa9c1d643e@haskell.org> Message-ID: <061.bffdc6c2ac9f1690c4c6e17d87c681f6@haskell.org> #11190: Hello "schedule: re-entered unsafely." ----------------------------------+------------------------------ Reporter: Chobbes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #951, #9920 | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by Chobbes): * status: infoneeded => closed * resolution: => fixed Comment: Replying to [comment:1 bgamari]: > I believe I encountered the same issue not so long ago when using Debian's LLVM 3.5 version, which is unfortunately missing some rather critical fixes (see #9920 for details). > > Can you reproduce this with LLVM 3.5.2? Turns out you were completely correct! I had mistakenly not cleaned object files left over from previous runs. This is now working with LLVM 3.5.2. My apologies for the mistake, and thank you very much for pointing out the issue. I can now generate executables in my QEMU environment for the RPI2, which work :). Thanks again, cheers! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 04:00:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 04:00:12 -0000 Subject: [GHC] #11215: Line endings in quasiquotations are not normalised In-Reply-To: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> References: <045.b79f40e76acb88d582b8991fba8918a1@haskell.org> Message-ID: <060.ee1fd405a9f1848bdc7f605e27a41e7f@haskell.org> #11215: Line endings in quasiquotations are not normalised -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #8424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps you're right that the lexer is a better place to address this. Up to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 04:16:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 04:16:21 -0000 Subject: [GHC] #11232: Panic whilst compiling syb due to OptCoercion In-Reply-To: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> References: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> Message-ID: <064.9bc2e75893a35ed8704bf3aa934d0c0d@haskell.org> #11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | 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:D1645 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * differential: => Phab:D1645 Comment: Fix in Phab:D1645. Very straightforward -- I don't know what I was thinking when I did it the wrong way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 06:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 06:53:59 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.cbc15a44c3d8585a94adf9a71219d801@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | 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:1646 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:1646 Comment: I've submitted Phab:D1646, which implements this idea. I included a sketch of my ideas in this [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Proposal:strictnessmetadata wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 08:31:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 08:31:42 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.9b7db25ab350e98bdc574012d415fe97@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:14 ross]: > I believe I've fixed the Show1/Read1 issue. Thanks, Ross! There may be time to make this in for GHC 8.0 after all. I've prepared a [http://hub.darcs.net/RyanGlScott/transformers/patch/6550957b47ffd09e5250a50712aac579d91b0184 patch] for `transformers` which does the appropriate `legacy711` migration of the `Data.Functor.*` modules, and backports `Typeable`/`Data`/`Generic`/`Generic1` instances that will be introduced in `base`. Note that there are some [https://ghc.haskell.org/trac/ghc/ticket/10524 bad interactions] between derived classes and `PolyKinds`, so I had to employ a few tricks to get the backported instances to work on old versions of GHC. Nevertheless, I tested my changes against every major version of GHC from 7.0?7.10, so this shouldn't break anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 09:46:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 09:46:46 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.c773a904bb0d6e15a64477db9bab6e0c@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 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 thomie): See also this email https://mail.haskell.org/pipermail/haskell- cafe/2008-January/038196.html (2008) and [wiki:ProjectSuggestions#TurningGHCintoaplatform]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 10:22:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 10:22:28 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.7d3ccec0b0e67387118ae89f348e9426@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 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 bgamari): * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 11:11:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 11:11:09 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.8297ad67f2df3587bfb04d007984a22b@haskell.org> #10376: arm/linux linking failure -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------- Comment (by Ben Gamari ): In [changeset:"786d528e8f949daeb62d34e0daa5e35f642065fc/ghc" 786d528e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="786d528e8f949daeb62d34e0daa5e35f642065fc" TcTypeable: Don't use bogus fingerprints when suppress-uniques is enabled Previously the Typeable implementation would intentionally create TyCon representations with bogus fingerprints to avoid fingerprints (which may change often) from leaking into test output. As pointed out by Richard in #10376 this is very bad as simply enabling a debug flag, `-dsuppress-uniques`, completely breaks the soundness of `Typeable`! This patch removes this behavior and replaces it with logic in the testsuite driver to filter out spurious changes due to Typeable representations. Test Plan: Validate Reviewers: austin, simonpj, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1629 GHC Trac Issues: #10376 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 11:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 11:38:24 -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.363086dfc8ebc11b1219e8801bd3180f@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: | Differential Rev(s): Phab:D652, Wiki Page: | Phab:D757 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D652 => Phab:D652, Phab:D757 Old description: > {{{ > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE AutoDeriveTypeable #-} > > import Data.Typeable > > data A = A > > main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) > }}} > > This returns `True`, but it should return `False`. New description: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A = A main = print $ typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy 'A) }}} This returns `True`, but it should return `False`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 11:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 11:54:15 -0000 Subject: [GHC] #11232: Panic whilst compiling syb due to OptCoercion In-Reply-To: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> References: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> Message-ID: <064.2b74b355112f94311151d9121e781711@haskell.org> #11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | 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:D1645 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cab131624ad0cdd54e2f3a70f93c1bd574ccf102/ghc" cab13162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cab131624ad0cdd54e2f3a70f93c1bd574ccf102" Fix #11232. I somehow forgot to propagate roles into UnivCos. Very simple fix, happily. Test Plan: simplCore/should_compile/T11232 Reviewers: bgamari, austin, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1645 GHC Trac Issues: #11232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 11:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 11:54:15 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.d4de21ee6a7e9a6fbe9cee2b61466651@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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:D1625 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d3dac4e3c8c7032151a8b89040f799cc5a9575d8/ghc" d3dac4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d3dac4e3c8c7032151a8b89040f799cc5a9575d8" Add -fprint-typechecker-elaboration flag (fixes #10662) Reviewers: thomie, austin, bgamari Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1625 GHC Trac Issues: #10662 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 11:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 11:54:15 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell In-Reply-To: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> References: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> Message-ID: <064.007aa38e72538a6a13cb56d6c5aa9411@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D1586 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4b161c93dba774cc8051cf40a2024ad86f3259f2/ghc" 4b161c93/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b161c93dba774cc8051cf40a2024ad86f3259f2" Reify DuplicateRecordFields by label, rather than by selector See `Note [Reifying field labels]` in `TcSplice`. This makes typical uses of TH work better with `DuplicateRecordFields`. If `reify` is called on the `Name` of a field label produced by the output of a previous `reify`, and there are multiple fields with that label defined in the same module, it may fail with an ambiguity error. Test Plan: Added tests, and manually tested that this makes Aeson's `deriveJSON` avoid the `$sel:` prefixes. Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1586 GHC Trac Issues: #11103 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:04:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:04:50 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.35c85fc9fd2e1262c765d646834a933f@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9137, #10804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #9137, #10804 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:07:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:07:22 -0000 Subject: [GHC] #11235: Haddock shows no class members In-Reply-To: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> References: <046.d18d9e000b3bcfa63bf9f94d143e960f@haskell.org> Message-ID: <061.4b9285130bad29589aeaa142fe2a64ae@haskell.org> #11235: Haddock shows no class members -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: 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: new => closed * failure: None/Unknown => Documentation bug * component: Compiler => Documentation * resolution: => fixed Comment: This was fixed in the Haddock merge in GHC commit 4c7da9c557ac5990fb4ccdd6145e0d2487a57219. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:10:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:10:36 -0000 Subject: [GHC] #11232: Panic whilst compiling syb due to OptCoercion In-Reply-To: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> References: <049.d2909770fc695ab458b5d62493fe5d45@haskell.org> Message-ID: <064.edbcf8c01245cbad2599938b06f42802@haskell.org> #11232: Panic whilst compiling syb due to OptCoercion -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: closed Priority: high | 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:D1645 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:11:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:11:39 -0000 Subject: [GHC] #11103: DuplicateRecordFields + TemplateHaskell In-Reply-To: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> References: <049.e67eee85f02bce8bad5417dcc1d4c2a8@haskell.org> Message-ID: <064.1c2a11156f0484a4f727746f74647ede@haskell.org> #11103: DuplicateRecordFields + TemplateHaskell -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D1586 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:12:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:12:13 -0000 Subject: [GHC] #10662: GHC warning shows technical summary of AST instead of the user's code In-Reply-To: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> References: <047.fe5b14891f46efc740c72fc5c88bcc32@haskell.org> Message-ID: <062.0713bcf63ccc33ffadf5894c79248d4c@haskell.org> #10662: GHC warning shows technical summary of AST instead of the user's code -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 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:D1625 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:14:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:14:56 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.97a2360819e50c695980f0aa0c248ae6@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The `-dsuppress-uniques` issue has been addressed by D1629, which was merged in 786d528e8f949daeb62d34e0daa5e35f642065fc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 12:15:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 12:15:50 -0000 Subject: [GHC] #11231: GHC's configure script does not honour CC env var In-Reply-To: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> References: <042.d7426d5dc7b5e5db91b935fc98bce267@haskell.org> Message-ID: <057.bcc243cc9fefd8b2a869ba42d394a273@haskell.org> #11231: GHC's configure script does not honour CC env var -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9983 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps Phab:D1356 is relevant here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 14:24:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 14:24:15 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.954d15a1a0e378f06cc9b3bbe7f1abb6@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Comment (by bgamari): I've also had to disable this test on ARM due to differences in the assembly syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 15:00:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 15:00:09 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.ffbbe9072d69a68d54610a6d0aa048e5@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"e2e24f2808561e5e6e1086e2ee15bf320d879e46/ghc" e2e24f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2e24f2808561e5e6e1086e2ee15bf320d879e46" Disable recomp015 on ARM Due to differences in assembly syntax. See #11022. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 15:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 15:26:29 -0000 Subject: [GHC] #11240: Simplifier ticks exhausted on Y combinator Message-ID: <047.e113184e41db9f201270a32e4e8055d2@haskell.org> #11240: Simplifier ticks exhausted on Y combinator -------------------------------------+------------------------------------- Reporter: sweirich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 code from this stackoverflow question: https://programmers.stackexchange.com/questions/215712/type-checking-and- recursive-types-writing-the-y-combinator-in-haskell-ocaml i.e. {{{#!hs newtype Mu a = Roll { unroll :: Mu a -> a } fix :: (a -> a) -> a fix = \f -> (\x -> f (unroll x x)) $ Roll (\x -> f (unroll x x)) }}} produces the following output when compiled with GHC 7.10.2 or 7.10.3: {{{ sweirich$ ghc --make Mu.hs [1 of 1] Compiling Mu ( Mu.hs, Mu.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone a_sml 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: 4962 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code compiles with newtype replaces by data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 15:29:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 15:29:15 -0000 Subject: [GHC] #11240: Simplifier ticks exhausted on Y combinator In-Reply-To: <047.e113184e41db9f201270a32e4e8055d2@haskell.org> References: <047.e113184e41db9f201270a32e4e8055d2@haskell.org> Message-ID: <062.6edde1b9858348fce61ec7b34009c412@haskell.org> #11240: Simplifier ticks exhausted on Y combinator -------------------------------------+------------------------------------- Reporter: sweirich | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Could this be related to the third bullet under [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html Sec 13.2.1] in the manual? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 16:19:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 16:19:51 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error Message-ID: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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: -------------------------------------+------------------------------------- Consider the following module: {{{#!hs {-# LANGUAGE ExplicitForAll, KindSignatures, PartialTypeSignatures #-} foo :: forall (a :: _) . a -> a foo = id }}} In HEAD, this fails with an internal errror: {{{ ? GHC internal error: ?_? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the kind ?_? In the type signature: foo :: forall (a :: _). a -> a }}} I would expect it to succeed and figure out that the wildcard is `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 16:27:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 16:27:19 -0000 Subject: [GHC] #11242: GHCi ignores -fno-warn-typed-holes Message-ID: <047.2da415eb99e1aeab3465b740d41302f2@haskell.org> #11242: GHCi ignores -fno-warn-typed-holes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 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: -------------------------------------+------------------------------------- If I load the following code in GHCi: {{{ {-# LANGUAGE PartialTypeSignatures #-} main = print $ f 3 f :: Int -> _ f = id }}} I get a warning about having a type hole. But when I load GHCi with `-fno- warn-typed-holes` (or set it with `:set`) I still get the warning message. It seems that GHC does respect the flag, i.e. `ghc Main -fno-warn-typed- holes` does not produce a warning, as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 16:53:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 16:53:06 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.77fc610e28f310d6b7f70b4d20ed0acf@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | recompilation 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 ezyang): Plugin interface hash is insufficient, since you want to recompile if the plugin implementation changes (even if its unfoldings do not.) It's almost as if you just want the file modification time... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:22:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:22:03 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.9f0c37c35b33bc94f699568712aca627@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"a2f04a26fe6bf989fb3575d73cb2a07464ab81a5/ghc" a2f04a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a2f04a26fe6bf989fb3575d73cb2a07464ab81a5" Testsuite: #10712 is fixed Verified by running: make TEST='exceptionsrun001 T3279 conc012 conc014' slowtest }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:24:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:24:32 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors Message-ID: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Error messages can be ugly, especially when working with promoted types. I've been dealing with this for a long time with [one library in particular](https://hackage.haskell.org/package/lol). But I just encountered something truly heinous. Due to a minor mistake, GHC spit out 8 errors in total, the shortest of which was 60 lines, and the longest of which was 20,046 lines long. That's no typo: the last error is over 20,000 lines long. Props to GHC for handling such a mess. As the library author, I've learned to look paste these massive errors. But I'm afraid that some user is going to have a heart attack (or worse: give up and go home). You can see in the error message that most of it is recurring blocks of {{{ PrimePower ('PP '(type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type- natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)))))), type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)) }}} and {{{ (NextListElt * zq ((':) * (ZqBasic * Types.Q18869761 Types.Z) ((':) * (Types.Zq * Types.Q19393921, ZQ1) ((':) * (Types.Zq * Types.Q19918081, ZQ2) ((':) * (Types.Zq * Types.Q2149056001, ZQ3) ((':) * (Types.Zq * Types.Q3144961, ZQ4) ((':) * (Types.Zq * Types.Q7338241, ZQ5) ('[] *))))))))), }}} I believe that GHC attempts to expand type synonyms as much as possible, which is great in many cases. But for this error, the repetition of fully expanded blocks completely hides the true nature of the error, especially since the user (obviously) makes heavy use of type synonyms anyway. The feature I'm requesting is the ability to somehow reduce the mess in the attached error. Here are a few ideas: 1. A flag to tell GHC to *not* expand type synonyms, i.e. if the user uses `N2` from Data.Type.Natural, GHC should print 'N2' instead of {{{ type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0) }}} 2. Allow library developers a way to tell the compiler how to print a certain entity, i.e., with a custom name. This is somewhat similar to the Custom Type Errors proposal, but I don't think that proposal includes a way to tell GHC how to print specific types/type synonyms. Has anyone else run into this issue before? Are there any existing solutions or other ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:24:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:24:39 -0000 Subject: [GHC] #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing In-Reply-To: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> References: <045.e7e6b1fe63913ee0ef5a119e69380bb4@haskell.org> Message-ID: <060.e8386d27078c45f80ae51de4f248ea98@haskell.org> #10712: Regression: make TEST=exceptionsrun001 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | base/tests/exceptionsrun001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1616 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Your patch did fix the bug, the four failing tests just had to marked as 'normal' again. All done now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:24:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:24:53 -0000 Subject: [GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) In-Reply-To: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> References: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> Message-ID: <060.31b81f2c212681f43bacca75c2f6334c@haskell.org> #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: ARMv7 Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Great! Thanks! I have installed LLVM 3.5.2 and it now is working fine. It will be great if GHC configure script is doing version checking of LLVM >= 3.5.2, report warning and stop using it if it is under 3.5.2 for ARM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:27:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:27:33 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.9f1527fce3d3d88373be07e9060b44a8@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Apparently, this error is too big for Trac and for LPaste. So you'll just have to take my word for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:28:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:28:52 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.f9e625639493ea67b1a492dcc22590be@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, it might help to have some idea of the structure of the error message at least. Have you tried with HEAD? I think there have been changes in when type synonyms are expanded in error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:31:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:31:45 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.5e1c1fbf394e81089d1f91ac7ce6a9fc@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "ghcierror.zip" added. Zip of error file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:32:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:32:46 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.f6a61e58129a8015f3fc34f7c9c5781b@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I was able to compress the error and attach it. Unfortunately, I don't have an easy way to test with HEAD. The test was with 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:34:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:34:02 -0000 Subject: [GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) In-Reply-To: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> References: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> Message-ID: <060.229a9af8ff8bfc7d0826fe902b4da46f@haskell.org> #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: ARMv7 Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): This will prevent all those headaches and wasted time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:35:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:35:32 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.aa6cc00816255649aec58bd98f1d0f63@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So the large types appear in the known constraints and the types of things in scope, like {{{ examples/Main.hs:113:23: Could not deduce (Typeable (* -> *) sym0) arising from a use of ?genKeys? from the context [LARGE] bound by the inferred type of prfTest :: [LARGE] at examples/Main.hs:(104,1)-(123,18) The type variable ?sym0? is ambiguous Relevant bindings include ast0 :: [LARGE] (bound at examples/Main.hs:110:3) In the first argument of ?evalCryptoRandIO?, namely ?(genKeys v ast0)? In the second argument of ?(=<<)?, namely ?evalCryptoRandIO (genKeys v ast0)? In a stmt of a 'do' block: (ast1, idMap) <- time "Generating keys: " =<< evalCryptoRandIO (genKeys v ast0) }}} I think this isn't what changed in HEAD; that was when the error actually involved a disagreement between types which were expressed using type synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:41:21 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.5f2b9aa44bc656c03c025b20b25b105d@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I believe that GHC attempts to expand type synonyms as much as possible On the contrary, GHC tries ''not'' to expand type synonyms unless necessary. So the first thing to do is to look at a small example, and see why it is failing to not-expand them. Can you make a test case that is as small as possible, in which a type synoym is expanded that you'd rather wasn't? (I.e. NOT one that demonstrates (as above) that unnecessary expansion is undesirable; we all believe that already.) It's possible that there's a good reason. Then the next thing is to think whether we could improve GHC's existing techniques for delaying expansion. Finally you could try to re-compress expanded types, though that sounds harder. Definitely a good project! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:45:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:45:20 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.e03dadc2ec9ac3af26aa1891568f8a55@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Quite a bit of discussion has led to this general rule: * Two user-written type variables, both in scope at the same time, should always refer to distinct, unknown types. Note that this rule is, in fact, violated sometimes: {{{ f :: a -> a -> Int f (x :: b) (y :: c) = 3 }}} This definition is accepted, even though `b` and `c` share a scope and refer to the same type. Under the general rule, this should be rejected. Now that we have type wildcards, a user who really wanted to write something like `f` can use wildcards. Returning to the situation in the original ticket, the general rule would allow `S`/`T` and prevent `Q`, as desired. Now, how to implement: when creating a `SigTv`, we could record the set of variables in scope at the time. Then, whenever we unify a `SigTv` with another type, we just make sure that the other type can never unify with any of those variables. Specifically: let's write `SigTv{a,b}` to denote a `SigTv` type variable flavor (a `MetaInfo`) that cannot unify with `a` or `b`. A tyvar `b` with flavor `SigTv{vs}` may unify with a type `t` only when: 1. `t` is a type variable, `a`; AND 2. (`a` is a skolem; OR 3. `a` is a `SigTv{ws}` such that `ws` is a superset of `vs`) Note that `ws` and `vs` may contain other `SigTv`s that have unified; it might be necessary to zonk `ws` and `vs` before doing the superset check. I offer no justification for why my approach might work. But I think it would. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:49:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:49:44 -0000 Subject: [GHC] #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) In-Reply-To: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> References: <045.8162439fdc5fb5d84712b0d16ed239ce@haskell.org> Message-ID: <060.b1af8b8ad4f0720ef9d0ec44c1bbfc87@haskell.org> #11236: Illegal instruction on ARMv7 with official build and simple program (IMX53 board) -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: ARMv7 Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: Agreed that there should be such a check in the GHC 7.10 line. But HEAD will require LLVM 3.7+, which I imagine contains the relevant bug fix that is in 3.5.2. And I don't know whether there will be another release of GHC 7.10. The GHC 8.0 release should be just a few months away anyways. So for that reason, even though your request is completely correct, I'm going to go ahead and close this ticket as wontfix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:57:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:57:44 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.d0f7e840429040e6d634ae4d00b22c52@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: deferred, | roles 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:D1641 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"1722fa106e10e63160bb2322e2ccb830fd5b9ab3/ghc" 1722fa10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1722fa106e10e63160bb2322e2ccb830fd5b9ab3" Fix #11230. Previously, we were optimizing away all case expressions over coercions with dead binders. But sometimes we want to force the coercion expression. Like when it contains an error. Test case: typecheck/should_run/T11230 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:57:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:57:44 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.02c2ac0ffa9d00dbff4b11588ee68252@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"ae86eb9f72fa7220fe47ac54d6d21395691c1308/ghc" ae86eb9f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae86eb9f72fa7220fe47ac54d6d21395691c1308" Fix tcTyClTyVars to handle SigTvs Previously, tcTyClTyVars required that the names of the LHsQTyVars matched up exactly with the names of the kind of the given TyCon. It now does a bit of matching up when necessary to relax this restriction. This commit enables a few tests that had previously been disabled. The shortcoming this addresses is discussed in #11203, but that ticket is not directly addressed here. Test case: polykinds/SigTvKinds, perf/compiler/T9872d }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:58:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:58:39 -0000 Subject: [GHC] #11230: No run-time exception for deferred type errors when error is in a phantom role position In-Reply-To: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> References: <046.200999812c22af87d58e3df7b9e466dd@haskell.org> Message-ID: <061.e6033693f367203f719886c956ea33cb@haskell.org> #11230: No run-time exception for deferred type errors when error is in a phantom role position -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: deferred, | roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | typecheck/should_run/T11230 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1641 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => typecheck/should_run/T11230 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 17:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 17:59:56 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.055fae5d73a4e06008f9a61181f30b4d@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The commit just pushed restores the (broken) behavior from before `TypeInType`, but does not address this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:04:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:04:43 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.8dadcf50060e909e369a4e1bb1ec261f@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to clarify what may be an auxiliary issue: GHC has made a (arbitrary) decision that vanilla type synonyms (`type Foo = ...`) should not be expanded, while type families should be expanded. The idea is that type families do computation and it might be useful to see the results of computation. This decision could be revisited or usefully controlled by a flag. Also, we're a bit hamstrung when it comes to expanding constraint synonyms, which tend to get expanded quite eagerly. But it's hard to do better. Is this what you're seeing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:20:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:20:08 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.18d4e84743366ce936e39da7111d6a33@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): I believe both of the major replicated blocks are due to type families. The `PrimePower` block is due to singletons, which makes heavy use of type families. Ideally, it would say something more like `PrimePower (PP (N7, N1))`. The `NextListElt` block also comes from a type family: while the type list itself is a simple type synonym, `NextListElt` is a type family. In that case, I'd like to see `NextListElt * zq MyTypeList`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:24:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:24:06 -0000 Subject: [GHC] #11243: Use Type Synonyms to Compress Errors In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.58fbbc2a8360f8aea858628fb563b90c@haskell.org> #11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah, so I think we've solved it then. Your experience is by design. And it's a design we settled on based on a different bug report asking for the opposite behavior of what you want. (I don't recall the ticket number.) Time to introduce `-fno-print-expanded-type-families`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:24:28 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.2be88fcdad49f7055a9f0257a70b7057@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:43:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:43:10 -0000 Subject: [GHC] #11243: Flag to not expand type families (was: Use Type Synonyms to Compress Errors) In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.93a019ffb46b3fa60485fde9e042a7da@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Please! That would (likely) solve the issue reported in this ticket. I can't find a ticket where the solution was to expand type families, perhaps someone else recalls the reason for that choice? I wonder if a more granular approach might be warranted. Perhaps we could say `-fno- print-expanded-type-families -fprint-tf NextListElt` to *only* expand `NextListElt`? I don't have a concrete use case for this off the top of my head, but if some people want TFs to be expanded, it seems like there should be some sort of intermediate solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:44:32 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package Message-ID: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 way compiler plugins are recommended to be specified is by putting it in a package and then referring to the exported module name in the `-fplugin` flag. Consequently, the recommended way to use a plugin from Cabal is to put it in `build-depends`. For example, [https://hackage.haskell.org/package/ghc-typelits-natnormalise ghc- typelits-natnormalise] is used by [http://hackage.haskell.org/package /clash-prelude clash-prelude], whose [http://hackage.haskell.org/package /clash-prelude-0.10.4/clash-prelude.cabal build-depends] depends on it explicitly. There are numerous downsides to operating in this manner: 1. Cabal will always link in any library which is `build-depend`ed on, even if there is no runtime dependency on the package in question. For example, suppose the default `cabal-init` package with a `build-depends: ghc` and doesn't use it, you get: {{{ ezyang at sabre:~/Dev/labs/link$ cat Main.hs module Main where main :: IO () main = putStrLn "Hello, Haskell!" ezyang at sabre:~/Dev/labs/link$ cabal configure --enable-executable-dynamic; cabal build # elided ezyang at sabre:~/Dev/labs/link$ ldd dist/build/link/link | grep libHSghc libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so => /srv/code/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc_JzwEp1oQ8kA7NFNTGk1ho5/libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so (0x00007f591f47a000) }}} That's terrible. And it's inflicted on every package which depends on a library that uses the plugin. The situation is better with static linking, since the linker can drop unreferenced object files; but we shouldn't be passing it to the linker in the first place. 2. It should be possible use a compiler plugin with a cross-compiler (e.g. GHCJS, etc.); unlike Template Haskell, the plugin must be written with the host compiler in mind. But the package database contains libraries compiled in the //target language//; whereas a compiler plugin must be compiled in the //host language//. It seems clear that using `-package` to bring a plugin into scope is highly undesirable. So what should we do? The necessary information to load a plugin is: 1. The package DB entry for the package it lives in (and information about all its transitive dependencies, because we may need to load code from them as well), 2. The actual module which contains the plugin. This leaves us with a number of options on the GHC end: 1. We could have a explicitly, IPID qualified method of specifying plugins. So, instead of saying `-fplugin ModuleName` and being at the mercy of what is exposed, you could say `-fplugin foo-0.1-xxxx:ModuleName` and as long as that package is usable (not ignored/broken) it would get loaded. 2. We could have a *completely separate* package database for plugins. You would control it using `-plugin-package` rather than `-package`; you don't even have to use the default system/user databases (which means that it might be possible to support a cross-compiler, although the details are fuzzy in my head). A benefit of this approach is that you can support the `-fplugin MyModule` mode of use, and have Cabal feed in the extra plugin package arguments to give meaning to this expression. An alternate command line interface (suggested by SPJ) would be that to load a plugin, you specify a path to the package database, package, and module in question, something like `-fplugin /path/to/package.conf/foo-0.1-xxxx.conf:MyPlugin` (one difficulty with this approach is that you may need multiple package databases to get this to work.) There would also be necessary Cabal adjustments, to get people to not put their plugins in `build-depends`, but a different dependency section, and how to have Cabal feed the IPID of the plugin to GHC. I'm happy to implement, but I'm looking for some consensus on what to do. (1) is easier to implement, but I dare say harder to integrate with Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:51:05 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.20818d372d36f04c27e634b76ba25504@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | 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: #6024 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 jstolarek]: > Note that we also have #6024 (and its wiki page [[wiki:GhcKinds/KindsWithoutData]]), which is about implementing close data kinds without the need for declaring a data type. Can we implement this and #6024 at the same time? It seems to me that the answer is yes. Agreed. That would be nice. > > Here is my proposal for the syntax: ... > > This syntax would steal `kind` as a keyword. Do we feel bad about it? I think it's easily avoidable, by just writing `data kind`. Using just `kind` here could be confusing, because your `kind` is not at all analogous to Haskell's `type`. > Also, I don't like `data constructor` syntax. I find it misleading as data constructor is a totally different thing than what we are declaring (in fact, in #6024 we specifically wish to avoid creating data constructors). We are precisely declaring a data constructor. It's just a data constructor that makes compile-time data. I recognize that others may usefully disagree about the meaning of a data constructor here, but I really to think that these are data constructors. (Compare to what other dependently typed languages do.) > > If we made this into a separate language extension, I wonder if that extension would have to be enabled only in modules that declare kinds or also in the ones that use them? Only at declaration sites. Infectious extensions are annoying. > ... If this was what dreixel meant then I disagree with it. I agree with you. `* :: *` does not obviate this or #6024. > > Another question related to `* :: *` is about namespace collision. If I say: > > {{{#!hs > -- assume DataKinds are enabled, so that C becomes a type > data T = C > }}} Ah. But `C` does not become a type. `C` lives in the data namespace. It's just that the renamer looks in both the type namespace and then the data namespace. `C` is always just a data constructor, even when used in a type. > {{{ > kind K = T | C > }}} > do we have collisions beetwen definitions of `T`s and `C`s? They are all in namespace of types. On the other hand they could be disambiguated by kind, but I'm not sure if this is acceptable. You are suggesting type-directed name resolution. That's a bigger pickle than we need to crack at the moment. > > Aside: if we can index kinds does this mean we have sort polymorphism? No no no. We have type polymorphism. And that's it. There are no kinds and no sorts. Just types. We humans have small brains and it is thus helpful to use both kind and type in speech to keep the ideas apart. But the terms are now truly synonymous. So, a type that classifies a type can be indexed, perhaps polymorphically. But let's not call it sort polymorphism. :) > > I will work on extending [[wiki:GhcKinds/KindsWithoutData]] wiki page, as I think this discussion belongs there (even if closed and open kinds should be implemented separately). Yell if you think otherwise. Fine by me. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 18:58:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 18:58:14 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.ae4aa70a799317f3fe87110750c3bae0@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): (dcoutts writes on IRC that he prefers the explicit qualification approach, since Cabal is going to have to play ball anyway.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:11:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:11:56 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.65e999a7c873f1d5e76a7b3a43500ed7@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > The current way compiler plugins are recommended to be specified is by > putting it in a package and then referring to the exported module name in > the `-fplugin` flag. Consequently, the recommended way to use a plugin > from Cabal is to put it in `build-depends`. For example, > [https://hackage.haskell.org/package/ghc-typelits-natnormalise ghc- > typelits-natnormalise] is used by [http://hackage.haskell.org/package > /clash-prelude clash-prelude], whose [http://hackage.haskell.org/package > /clash-prelude-0.10.4/clash-prelude.cabal build-depends] depends on it > explicitly. > > There are numerous downsides to operating in this manner: > 1. Cabal will always link in any library which is `build-depend`ed on, > even if there is no runtime dependency on the package in question. For > example, suppose the default `cabal-init` package with a `build-depends: > ghc` and doesn't use it, you get: > {{{ > ezyang at sabre:~/Dev/labs/link$ cat Main.hs > module Main where > > main :: IO () > main = putStrLn "Hello, Haskell!" > ezyang at sabre:~/Dev/labs/link$ cabal configure --enable-executable- > dynamic; cabal build > # elided > ezyang at sabre:~/Dev/labs/link$ ldd dist/build/link/link | grep libHSghc > libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so => > /srv/code/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc_JzwEp1oQ8kA7NFNTGk1ho5/libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so > (0x00007f591f47a000) > }}} > That's terrible. And it's inflicted on every package which depends on > a library that uses the plugin. The situation is better with static > linking, since the linker can drop unreferenced object files; but we > shouldn't be passing it to the linker in the first place. > 2. It should be possible use a compiler plugin with a cross-compiler > (e.g. GHCJS, etc.); unlike Template Haskell, the plugin must be written > with the host compiler in mind. But the package database contains > libraries compiled in the //target language//; whereas a compiler plugin > must be compiled in the //host language//. > > It seems clear that using `-package` to bring a plugin into scope is > highly undesirable. So what should we do? The necessary information to > load a plugin is: > > 1. The package DB entry for the package it lives in (and information > about all its transitive dependencies, because we may need to load code > from them as well), > 2. The actual module which contains the plugin. > > This leaves us with a number of options on the GHC end: > > 1. We could have a explicitly, IPID qualified method of specifying > plugins. So, instead of saying `-fplugin ModuleName` and being at the > mercy of what is exposed, you could say `-fplugin > foo-0.1-xxxx:ModuleName` and as long as that package is usable (not > ignored/broken) it would get loaded. > > 2. We could have a *completely separate* package database for plugins. > You would control it using `-plugin-package` rather than `-package`; you > don't even have to use the default system/user databases (which means > that it might be possible to support a cross-compiler, although the > details are fuzzy in my head). A benefit of this approach is that you can > support the `-fplugin MyModule` mode of use, and have Cabal feed in the > extra plugin package arguments to give meaning to this expression. > > An alternate command line interface (suggested by SPJ) would be that > to load a plugin, you specify a path to the package database, package, > and module in question, something like `-fplugin > /path/to/package.conf/foo-0.1-xxxx.conf:MyPlugin` (one difficulty with > this approach is that you may need multiple package databases to get this > to work.) > > There would also be necessary Cabal adjustments, to get people to not put > their plugins in `build-depends`, but a different dependency section, and > how to have Cabal feed the IPID of the plugin to GHC. > > I'm happy to implement, but I'm looking for some consensus on what to do. > (1) is easier to implement, but I dare say harder to integrate with > Cabal. New description: The current way compiler plugins are recommended to be specified is by putting it in a package and then referring to the exported module name in the `-fplugin` flag. Consequently, the recommended way to use a plugin from Cabal is to put it in `build-depends`. For example, [https://hackage.haskell.org/package/ghc-typelits-natnormalise ghc- typelits-natnormalise] is used by [http://hackage.haskell.org/package /clash-prelude clash-prelude], whose [http://hackage.haskell.org/package /clash-prelude-0.10.4/clash-prelude.cabal build-depends] depends on it explicitly. There are numerous downsides to operating in this manner: 1. Cabal will always link in any library which is `build-depend`ed on, even if there is no runtime dependency on the package in question. For example, suppose the default `cabal-init` package with a `build-depends: ghc` and doesn't use it, you get: {{{ ezyang at sabre:~/Dev/labs/link$ cat Main.hs module Main where main :: IO () main = putStrLn "Hello, Haskell!" ezyang at sabre:~/Dev/labs/link$ cabal configure --enable-executable-dynamic; cabal build # elided ezyang at sabre:~/Dev/labs/link$ ldd dist/build/link/link | grep libHSghc libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so => /srv/code/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc_JzwEp1oQ8kA7NFNTGk1ho5/libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so (0x00007f591f47a000) }}} That's terrible. And it's inflicted on every package which depends on a library that uses the plugin. The situation is better with static linking, since the linker can drop unreferenced object files; but we shouldn't be passing it to the linker in the first place. 2. It should be possible use a compiler plugin with a cross-compiler (e.g. GHCJS, etc.); unlike Template Haskell, the plugin must be written with the host compiler in mind. But the package database contains libraries compiled in the //target language//; whereas a compiler plugin must be compiled in the //host language//. It seems clear that using `-package` to bring a plugin into scope is highly undesirable. So what should we do? The necessary information to load a plugin is: 1. The package DB entry for the package it lives in (and information about all its transitive dependencies, because we may need to load code from them as well), 2. The actual module which contains the plugin. This leaves us with a number of options on the GHC end: 1. We could have a explicitly, IPID qualified method of specifying plugins. So, instead of saying `-fplugin ModuleName` and being at the mercy of what is exposed, you could say `-fplugin foo-0.1-xxxx:ModuleName` and as long as that package is usable (not ignored/broken) it would get loaded. 2. We could have a *completely separate* package database for plugins. You would control it using `-plugin-package` rather than `-package`; you don't even have to use the default system/user databases (which means that it might be possible to support a cross-compiler, although the details are fuzzy in my head). A benefit of this approach is that you can support the `-fplugin MyModule` mode of use, and have Cabal feed in the extra plugin package arguments to give meaning to this expression. An alternate command line interface (suggested by SPJ) would be that to load a plugin, you specify a path to the package database, package, and module in question, something like `-fplugin /path/to/package.conf/foo-0.1-xxxx.conf:MyPlugin` (one difficulty with this approach is that you may need multiple package databases to get this to work.) 3. We could use the same databases, but a *separate* package namespace. So I can say `ghc -hide-all-packages -plugin-package-id foo-0.1-xxx`; the `-plugin-package-id` makes it so that I can say `-fplugin FooPlugin` later in the command line options. This is desirable because it allows you to continue to say `{-# OPTIONS -fplugin FooPlugin #-}` in a Haskell file, turning on the plugin per-module, while letting Cabal configure where it points to. There would also be necessary Cabal adjustments, to get people to not put their plugins in `build-depends`, but a different dependency section, and how to have Cabal feed the IPID of the plugin to GHC. I'm happy to implement, but I'm looking for some consensus on what to do. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:22:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:22:59 -0000 Subject: [GHC] #11243: Flag to not expand type families In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.c5887039a32cb17e66e212fca37f6c21@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The Right Solution is to be more like Idris and allow users to, say, click on parts of error messages to expand or contract them. That's a major project. But the pressure is mounting for such an improvement, and so I'll leery of putting in gobs more complexity into command-line flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:27:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:27:31 -0000 Subject: [GHC] #11243: Flag to not expand type families In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.8e55b2f11b342274cf8892b6a82dc042@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Sounds like a good long-term solution, and in the short term `-fno-print- expanded-type-families` should suffice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:31:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:31:28 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty Message-ID: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Example: {{{#!haskell module Main where maybeOdd :: Int -> Maybe Int maybeOdd i = if odd i then Just i else Nothing main :: IO () main = do let x = maybeOdd 10 let a | Just i <- x , odd i = True | Nothing <- x = False print x print a }}} Warning printed by GHC HEAD: {{{ Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In an equation for ?a?: Patterns not matched: Linking Exhaustive ... }}} The problem with this message is; if it couldn't come up with an example unmatched pattern, then how can it know that the pattern is non- exhaustive? If it came up with an example, why is that example not printed? UPDATE: I just realized it's actually worse that I first thought. If I change {{{a}}} in this example: {{{#!haskell let a | Just i <- x = True }}} This message is printed: {{{ [1 of 1] Compiling Main ( Exhaustive.hs, Exhaustive.o ) Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In an equation for ?a?: Patterns not matched: Exhaustive.hs:10:16: warning: Defined but not used: ?i? Linking Exhaustive ... }}} NOTE: Tried with GHC 7.10 too. It seems like in the case where the checks are not exhaustive, both 7.10 and HEAD are giving the same warning(with empty list of non-checked patterns). HEAD is better in detecting exhaustive patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:55:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:55:57 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.7dfce6a65526592f98d631b6a1dbf740@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:56:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:56:27 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.627932b4bf409c210ea7abc73668aa75@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf 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 ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:56:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:56:34 -0000 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@haskell.org> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@haskell.org> Message-ID: <074.b64949954fc14f0a64c24365459e3d96@haskell.org> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient -------------------------------------+------------------------------------- Reporter: jcpetruzza@? | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: deriving-perf 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 ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:56:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:56:41 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.7626206d7668a5f5f178dedbeebb8224@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8731 #10858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:56:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:56:47 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.16c54989486ee80323afa41793fefaf2@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: deriving-perf 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 ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 19:56:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 19:56:54 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.603e629ed077808b57307303c5d5eb1d@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:04:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:04: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.a090adad284ac30f55b6d03cdfc861a1@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:04:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:04:44 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.30e1ee0c51d80a036a92a410559a58c4@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:05:11 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.816dbdaa327e3ef6bb858f4fda8f95f2@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 ezyang): * keywords: => deriving-perf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:22:01 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. Message-ID: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{ module Foo where import GHC.Exts type Key a = Any }}} produces the error message on HEAD but compiles on 7.8.3 and 7.10.1 (thanks to Reid for testing). {{{unsafeany.hs:5:1: error: ? The type family ?Any? should have no arguments, but has been given none ? In the type synonym declaration for ?Key? Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:25:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:25:14 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.526a801a35c0e33f91a54fb6c3e8fa60@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Old description: > {{{ > module Foo where > > import GHC.Exts > > type Key a = Any > }}} > > produces the error message on HEAD but compiles on 7.8.3 and 7.10.1 > (thanks to Reid for testing). > > {{{unsafeany.hs:5:1: error: > ? The type family ?Any? should have no arguments, but has been given > none > ? In the type synonym declaration for ?Key? > Failed, modules loaded: none. > }}} New description: {{{ module Foo where import GHC.Exts type Key a = Any }}} produces the error message on HEAD but compiles on 7.8.3 and 7.10.1 (thanks to Reid for testing). {{{ unsafeany.hs:5:1: error: ? The type family ?Any? should have no arguments, but has been given none ? In the type synonym declaration for ?Key? Failed, modules loaded: none. }}} -- Comment (by mpickering): Omer comments that the bug could be caused by levity polymorphism. > mpickering: I don't quite understand what changes need to be made, but if you look at anyTyCon in TysPrim.hs you'll see that it's not updated after Richard's patch. I'm just guessing that this may be the reason because tuple tycons are changed to update the kind arguments, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:42:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:42:02 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.c79f3671cd04237c47aab4882c3e629f@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bc436f9ec51eb54aaebfbcd7de9c10543d629917/ghc" bc436f9e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc436f9ec51eb54aaebfbcd7de9c10543d629917" Testsuite: mark frontend01 conditionally expect_broken on #10301 This should fix validate on Travis. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 20:44:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 20:44:33 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.0a01e0e7f631d79e102af34248639e9c@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: plugins/T10294 => plugins/T10294 plugins/frontend01 Comment: `frontend01` is failing in the same way when DYNAMIC_GHC_PROGRAMS=NO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 21:03:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 21:03:12 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.9981cf245976172579c5e58ac9a01b4d@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"e0e03d5b9d5cd678f6402534451964d491f16540/ghc" e0e03d5b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e0e03d5b9d5cd678f6402534451964d491f16540" Move Data.Functor.(Classes,Compose,Product,Sum) into base These modules were previously provided by the `transformers` package. Hence the submodule update. This patch was originally contributed by M Farkas-Dyck and subsequently taken over and completed by Ryan. The original proposal discussion can be found at https://mail.haskell.org/pipermail/libraries/2015-July/026014.html This addresses #11135 Differential Revision: https://phabricator.haskell.org/D1543 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 21:13:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 21:13:13 -0000 Subject: [GHC] #10524: PolyKinds doesn't interact well with DeriveFunctor In-Reply-To: <050.7408f13045aa603e186c148218ece722@haskell.org> References: <050.7408f13045aa603e186c148218ece722@haskell.org> Message-ID: <065.6a41426ce49fed7fcae837f17b7a5d0e@haskell.org> #10524: PolyKinds doesn't interact well with DeriveFunctor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10561 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I also experienced the same error as in comment:15 when I tried to derive a `Generic1` instance for `Compose` in Phab:D1543. A workaround is to use standalone deriving: {{{#!hs deriving instance Functor f => Generic1 (Compose f g) }}} If we fix this bug, we should remember to change that instance (located [http://git.haskell.org/ghc.git/blob/e0e03d5b9d5cd678f6402534451964d491f16540:/libraries/base/Data/Functor/Compose.hs#l41 here]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 21:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 21:13:14 -0000 Subject: [GHC] #11097: `unlit` executable installed in wrong folder In-Reply-To: <042.e54dd93bfb8a88229d3581e0230ebbc0@haskell.org> References: <042.e54dd93bfb8a88229d3581e0230ebbc0@haskell.org> Message-ID: <057.8aae1fb14c772eb3750b59b13ce7b0c1@haskell.org> #11097: `unlit` executable installed in wrong folder -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build 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 thomie): * status: new => closed * resolution: => fixed Comment: Fixed by commit 4905b83a2d448c65ccced385343d4e8124548a3b (buried in there somewhere) and c1bd3d444f8c52c688fdbea695ee0ae7f402945d: {{{ Author: Thomas Miedema Date: Thu Dec 17 19:45:13 2015 +0100 Build system: also put scripts in libexecdir/bin This follows a similar change in 4905b83a2d448c65ccced385343d4e8124548a3b, where binaries are installed in libexecdir/bin instead of libexecdir. This fixes a problem with ghc not able to find ghc-split, when SplitObjs=YES. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 21:41:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 21:41:33 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.900837b0533aaf4336fdc947868b0a33@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.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: 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 Thu Dec 17 21:56:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 21:56:03 -0000 Subject: [GHC] #11247: Weird error from running runghc on an invalid input filename Message-ID: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> #11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7765 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had files `random.hs` and `random.hi` and `random.o`, so I accidentally entered the following command with tab completion. {{{ rwbarton at morphism:/tmp$ runghc random. Warning: ignoring unrecognised input `random.' random.:1:33: Not in scope: ?main? Perhaps you meant ?min? (imported from Prelude) }}} #7765 is surely related, but with HEAD (well, rather old, but at least new enough to contain the fix for #7765), the error is not really any better: {{{ rwbarton at morphism:/tmp$ ~/ghc/inplace/bin/runghc random. Warning: ignoring unrecognised input `random.' random.:0:53: error: Variable not in scope: main :: IO a0 Perhaps you meant ?min? (imported from Prelude) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 17 23:27:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Dec 2015 23:27:34 -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.3cde0abff729f85e3c7f691be0ed6a22@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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: | -------------------------------------+------------------------------------- Changes (by kolmodin): * cc: kolmodin (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 00:03:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 00:03:34 -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.77455d2044b0ccdc5b1384a52914bed8@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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 ezyang): I did some investigation related to this bug on GHC 7.10.3-ish and binary 0.7.5.0 (yes it's old, but I didn't see any more recent relevant commits; and it's what GHC is bootstrapping with). Here are some partial findings: 1. I can trigger bad constant factors this data type: {{{ {-# LANGUAGE DeriveGeneric #-} module A where import Data.Binary import GHC.Generics data T = T () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () deriving Generic instance Binary T }}} {{{ ezyang at sabre:~/Dev/labs$ time $DEV/ghc-7.10-frontend-plugins/usr/bin/ghc --make Bin.hs -O2 -fforce-recomp -fliberate-case-threshold=1000 [1 of 1] Compiling A ( Bin.hs, Bin.o ) real 0m7.369s user 0m6.408s sys 0m0.224s ezyang at sabre:~/Dev/labs$ time $DEV/ghc-7.10-frontend-plugins/usr/bin/ghc --make Bin.hs -O0 -fforce-recomp -fliberate-case-threshold=1000 [1 of 1] Compiling A ( Bin.hs, Bin.o ) real 0m0.881s user 0m0.776s sys 0m0.080s }}} 2. The problem gets worse if you have explicit field names, something like a x2 factor. {{{ data T = T () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () deriving Generic -- versus data T = T { f0 :: (), f1 :: (), f2 :: (), f3 :: (), f4 :: (), f5 :: (), f6 :: (), f7 :: (), f8 :: (), f9 :: (), f10 :: (), f11 :: (), f12 :: (), f13 :: (), f14 :: (), f15 :: (), f16 :: (), f17 :: (), f18 :: (), f19 :: (), f20 :: (), f21 :: (), f22 :: (), f23 :: (), f24 :: (), f25 :: (), f26 :: (), f27 :: (), f28 :: (), f29 :: (), f30 :: (), f31 :: (), f32 :: (), f33 :: (), f34 :: (), f35 :: (), f36 :: (), f37 :: (), f38 :: (), f39 :: () } deriving (Generic) }}} {{{ ezyang at sabre:~/Dev/labs$ time $DEV/ghc-7.10-frontend-plugins/usr/bin/ghc --make Bin.hs -O -fforce-recomp -fliberate-case-threshold=1000 [1 of 1] Compiling A ( Bin.hs, Bin.o ) real 0m2.649s user 0m2.520s sys 0m0.080s ezyang at sabre:~/Dev/labs$ time $DEV/ghc-7.10-frontend-plugins/usr/bin/ghc --make Bin.hs -O -fforce-recomp -fliberate-case-threshold=1000 [1 of 1] Compiling A ( Bin.hs, Bin.o ) real 0m4.990s user 0m4.824s sys 0m0.144s }}} It's NOT just generic deriving; the generic deriving is still pretty speedy, honestly. 3. If you inline all of Binary's class definitions into the same file, things speed up. Comparing the two cases, it seems that when we cross- module compile, GHC does more inlining and more optimization, and it takes longer. This is something like a 30% factor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 00:44:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 00:44:33 -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.7f07dfc233f73ed048ad0aac8b04f602@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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 ezyang): Here is a minimized test-case with no dependencies, which may be useful for diagnosing: {{{ {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fno-warn-missing-methods #-} module Gen where import GHC.Generics import Control.Monad import Data.Monoid data PairS a = PairS a !(() -> ()) newtype PutM a = Put { unPut :: PairS a } -- Use of this writer monad seems to be important; IO speeds it up type Put = PutM () -- type Put = IO () -- binary has INLINE pragmas on most of the instances but you can still -- trigger bad behavior without them. instance Functor PutM where fmap f m = Put $ let PairS a w = unPut m in PairS (f a) w -- Just to appease AMP instance Applicative PutM where pure = return (<*>) = ap instance Monad PutM where return a = Put $ PairS a id m >>= k = Put $ let PairS a w = unPut m PairS b w' = unPut (k a) in PairS b (w . w') class GBinary f where gput :: f t -> Put -- Forcing the dictionary to have two elements hurts -- the optimizer a lot. not_used :: f t instance GBinary a => GBinary (M1 i c a) where gput = gput . unM1 instance Binary a => GBinary (K1 i a) where gput = put . unK1 instance (GBinary a, GBinary b) => GBinary (a :*: b) where gput (x :*: y) = gput x >> gput y class Binary t where put :: t -> Put instance Binary () where put () = return () data T = T () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () () deriving Generic -- Trigger specialization tput :: T -> Put tput = gput . from }}} On my machine, it takes 2.8s to build -O2, and 0.9s to build -O0. There are a few important ways you can tweak this: 1. This also exhibits the "out-of-line more expensive" behavior; moving the code out into a separate module jumps compile time from 2.7s to 5.2s. 2. If you replace `PutM ()` with `IO ()`, compile time goes from 2.7s to 1.9s 3. Removing `not_used`, pushes compile time from 2.7s to 1.5s. This DOES NOT stack with (2). So having to deal with dictionaries seems to make things work. I also wonder if this writer monad is actually leaking thunks, because apparently it's impossible to correctly implement writer without leaking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:12:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:12:08 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms Message-ID: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) type Ctx1 e r s e' r' = (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) bug :: (Ctx1 e r s e' r') => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ?e'0? is ambiguous When checking that ?foo? has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I move the `e' ~ ...` constraint from `Ctx1` to `Ctx2` or to the context of `bug`, it compiles as expected. Somehow, GHC misses the constraint when it is in `Ctx1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:17:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:17:13 -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.92be9791d157d104b18c10b4ca25efe2@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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 ezyang): I managed to massively speed up Binary by applying (3). So I think we have our culprit. Here's the PR: https://github.com/kolmodin/binary/pull/95 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:20:33 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types Message-ID: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) bug :: (Ctx2 e r s e' r', e' ~ (e ** (FDiv r' r))) => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ?e'0? is ambiguous When checking that ?foo? has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I change the definition of `bug` to: {{{ bug :: (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) => CT r r' -> CT s s' bug = undefined }}} that is, I use the type synonym `/` for `FDiv`, then the code suddenly compiles. This seems like a different bug than #11248 because that ticket is about transitivity of constraint synonyms, while this example is broken simply by using a type synonym. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:21:44 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.722ff610f74a2c60fa3a6096af9f76ec@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 crockeea: Old description: > The following code fails to compile: > > {{{ > {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, > KindSignatures, ConstraintKinds #-} > > import GHC.TypeLits > > type a / b = FDiv a b > type a ** b = FMul a b > > type family FDiv a b where > FDiv 11648 128 = 91 > > type family FMul a b where > FMul 64 91 = 5824 > > type family FGCD a b where > FGCD 128 448 = 64 > FGCD 128 5824 = 64 > > type family FLCM a b where > FLCM 128 5824 = 11648 > > data CT (m :: Nat) (m' :: Nat) > type H0 = 128 > type H1 = 448 > type H0' = 11648 > type H1' = 5824 > > main' = > let x = undefined :: CT H0 H0' > in foo x :: CT H1 H1' > > foo x = bug x > > type Ctx2 e r s e' r' = > (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) > > type Ctx1 e r s e' r' = > (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) > > bug :: (Ctx1 e r s e' r') > => CT r r' -> CT s s' > bug = undefined > }}} > > with the error > > {{{ > Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) > ... > The type variable ?e'0? is ambiguous > When checking that ?foo? has the inferred type > foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). > ((~) Nat (FGCD r s) (FGCD r e'), > (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => > CT r (FLCM r e') -> CT s s' > Probable cause: the inferred type is ambiguous > }}} > > However, if I move the `e' ~ ...` constraint from `Ctx1` to `Ctx2` or to > the context of `bug`, it compiles as expected. Somehow, GHC misses the > constraint when it is in `Ctx1`. New description: The following code fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) type Ctx1 e r s e' r' = (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) bug :: (Ctx1 e r s e' r') => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ?e'0? is ambiguous When checking that ?foo? has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I move the `e' ~ ...` constraint from `Ctx1` to `Ctx2` or to the context of `bug`, it compiles as expected. Somehow, GHC misses the constraint when it is in `Ctx1`. I don't think this is #10338, but someone who knows more about the innards of GHC can verify. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:22:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:22:14 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types In-Reply-To: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> References: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> Message-ID: <062.53bd3400ccb0d1f4ebedb1a02bb43d95@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 crockeea: Old description: > The following code fails to compile: > > {{{ > {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, > KindSignatures, ConstraintKinds #-} > > import GHC.TypeLits > > type a / b = FDiv a b > type a ** b = FMul a b > > type family FDiv a b where > FDiv 11648 128 = 91 > > type family FMul a b where > FMul 64 91 = 5824 > > type family FGCD a b where > FGCD 128 448 = 64 > FGCD 128 5824 = 64 > > type family FLCM a b where > FLCM 128 5824 = 11648 > > data CT (m :: Nat) (m' :: Nat) > type H0 = 128 > type H1 = 448 > type H0' = 11648 > type H1' = 5824 > > main' = > let x = undefined :: CT H0 H0' > in foo x :: CT H1 H1' > > foo x = bug x > > type Ctx2 e r s e' r' = > (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) > > bug :: (Ctx2 e r s e' r', e' ~ (e ** (FDiv r' r))) > => CT r r' -> CT s s' > bug = undefined > }}} > > with the error > > {{{ > Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) > ... > The type variable ?e'0? is ambiguous > When checking that ?foo? has the inferred type > foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). > ((~) Nat (FGCD r s) (FGCD r e'), > (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => > CT r (FLCM r e') -> CT s s' > Probable cause: the inferred type is ambiguous > }}} > > However, if I change the definition of `bug` to: > > {{{ > bug :: (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) > => CT r r' -> CT s s' > bug = undefined > }}} > > that is, I use the type synonym `/` for `FDiv`, then the code suddenly > compiles. This seems like a different bug than #11248 because that ticket > is about transitivity of constraint synonyms, while this example is > broken simply by using a type synonym. New description: The following code fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) bug :: (Ctx2 e r s e' r', e' ~ (e ** (FDiv r' r))) => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ?e'0? is ambiguous When checking that ?foo? has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I change the definition of `bug` to: {{{ bug :: (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) => CT r r' -> CT s s' bug = undefined }}} that is, I use the type synonym `/` for `FDiv`, then the code suddenly compiles. This seems like a different bug than #11248 because that ticket is about transitivity of constraint synonyms, while this example is broken simply by using a type synonym. It's possible that this is also related to #10338, but I'm not sure. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 01:25:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 01:25:09 -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.3d44c7149cab90677830249d4e9897e0@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 03:08:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 03:08:18 -0000 Subject: [GHC] #11250: GHC shows core with error Message-ID: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> #11250: GHC shows core with error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 intentionally does not compile: {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds #-} data Proxy (p :: k) = Proxy data Tagged (t :: k) s = Tagged s proxy :: Tagged t s -> Proxy t -> s proxy = undefined bar :: Tagged (gad :: *) Int bar = undefined foo :: Int foo = proxy bar (Proxy::Proxy 'True) }}} but it produces the following output with GHC and GHCi: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) RAE1 [W] cobox_aLM :: t0_aK4[tau:1] ~ 'True (CNonCanonical) t0_aK4[tau:1] 'True False Bug.hs:13:18: Couldn't match kind ?Bool? with ?*? Expected type: Proxy t0 Actual type: Proxy 'True In the second argument of ?proxy?, namely ?(Proxy :: Proxy True)? In the expression: proxy bar (Proxy :: Proxy True) In an equation for ?foo?: foo = proxy bar (Proxy :: Proxy True) Failed, modules loaded: none. }}} This ticket is about the first block printed out. It seems to be a random section of core, and is completely useless to debugging the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 03:41:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 03:41:40 -0000 Subject: [GHC] #11250: GHC shows core with error In-Reply-To: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> References: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> Message-ID: <062.679dfb1dfc20b03d116965f16a04ca22@haskell.org> #11250: GHC shows core with error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 goldfire): Well, that's embarrassing -- it's a bit of debug output I put in at some point. (My initials are RAE. I use them in all my debugging output I intend to remove, for easy searching.) I can't reproduce this on 7.10.2. What version of GHC are you working with? A quick search shows that this problem isn't in the current codebase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 04:03:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 04:03:22 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.f98e9bbdb2f755137c649c7ffe644172@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I doubt it's levity polymorphism, but I feel quite confident I'm the culprit. Will look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 04:23:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 04:23:00 -0000 Subject: [GHC] #11250: GHC shows core with error In-Reply-To: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> References: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> Message-ID: <062.5743da37ccd5016bee278b8abc0f2ae5@haskell.org> #11250: GHC shows core with error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): That output was with version 7.10.2.20151030. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 08:37:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 08:37:34 -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.6cb88f4ebb185b336befd57a6af617a3@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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): Thank you for helping to characterise this. More please! Eg is it the type checker, or all the way down the pipeline? Do terms get big? Why does putting Binary's classes in the file help? Why does removing `not- used` help. One possible reason: see [http://research.microsoft.com/en- us/um/people/simonpj/papers/variant-f/index.htm Scrap your type applications] Section 2.3. Generics, I suspect, uses lots of nested types! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 08:42:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 08:42:03 -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.5bbf9188dd3b4796be7d8078a8093dfa@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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): Splitting `binary` as done in comment:23 will improve matters. As you say it doesn't fix GHC; indeed it'll make the problem less egregious. Just to check, then: does comment:22 give a standalone case, independent of the `binary` class, that demonstrates the effect of splitting the `Binary` class into two? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:01:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:01:00 -0000 Subject: [GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore Message-ID: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> #11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: Typeable, | Operating System: Unknown/Multiple isInstance | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs > :set -XTemplateHaskell > :m +Data.Tyepable > :m +Language.Haskell.TH --- With GHC 7.8 or earlier versions of GHC (I only tried with GHC 7.6, but my friends tried on 7.8 and earlier versoin) > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "True" --- With GHC 7.10.1 > $(isInstance ''Typeable [ConT ''Char] >>= stringE.show) "False" }}} I have noticed that standalone derivings of Typeable instances in Data.Typeable are disappared magically in base-4.8 of GHC 7.10,also one cannot query the instances of it by using `:i Typeable` in GHCi, however, obviously, I can use `typeOf` function in base-4.8 to get the TypeRep of Char. The problem is that `isInstance` in template-haskell library doesn't know Char and many other types are instances of Typeable anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:26:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:26:08 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.d3e0ff413758e7ea9157be6185cccb77@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): OK I've got it. Patch coming. Your example differs from Edward's in #10318, because you really do have an infinite stack of superclasses. * `Eq a` has `Boolean (Logic a)` as a superclass * `Boolean a` ultimately has `Eq a` as a superclass So we get `Eq (Logic a)`, `Eq (Logic (Logic a))`, etc forever. Do you really mean that. Edward cut this off by adding a constraint {{{ Frac (Frac a) ~ Frac a }}} Can you do something like that for `Logic`? If you really really do have infinitely many superclasses then unsolved constraints will indeed hit the iteration limit as you found... GHC keeps adding superclasses in the hope of finding one that works, but there are infinitely many of them (I fixed the error message to give the right flag name, but it doesn't solve the problem). I don't see any way to solve this without you giving GHC some way to bound the tower as Edward did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:30:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:30:38 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types In-Reply-To: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> References: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> Message-ID: <062.c315b7946e61fd4fe3c7c4578581c844@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): Works in HEAD (and hence in upcoming 8.0). I'll add a regression test at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:32:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:32:40 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.463afa09d043cf3f2aba717e0a6cde56@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): This too works in HEAD (and hence 8.0). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:41:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:41:32 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.ab235944e0575a74224bccb38e40be0f@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: => gkaracha -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:49:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:49:30 -0000 Subject: [GHC] #11243: Flag to not expand type families In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.c414b613e80544166568feb755fd5070@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The underlying issue is this: * Suppose `F` is a type function with an instance for `F [Int]`. If we have constraints 1. `(C (F [Int]))`, where `C` is a class 2. `F [Int] ~ Maybe Bool` 3. `G (F [Int]) ~ Maybe Bool` then we want to apply the instance in case that unlocks the class constraint or equality. * That expansion may be fruitless. For (1), perhaps `F [Int]` expands to `Bool`, `C` has no `Bool` instance. Then would you prefer to see "can't solve `C (F [Int])`" or "can't solve `C Bool`? Perhaps the latter. * In (3) we might expand `F [Int]` vigorously to get a big type, and ''still'' not be able to simplify the call to `G`. In the case of type synonyms we can have the best of both worlds. Say we have {{{ type T a = S a a }}} Then the type `T [Int]` is represented (essentially) as a pair of its expanded and un-expanded form; so we can freely choose to use either at any time. But it's not so easy for type functions becuase the expanded and un- expanded forms are not interchangeable; there's a coercion involved. I think we could still be a bit less aggressive about expansion. We even implemted this once. But we disabled it for ill-understood performance reasons. Here is the Note from `TcFlatten`: {{{ Note [Lazy flattening] ~~~~~~~~~~~~~~~~~~~~~~ The idea of FM_Avoid mode is to flatten less aggressively. If we have a ~ [F Int] there seems to be no great merit in lifting out (F Int). But if it was a ~ [G a Int] then we *do* want to lift it out, in case (G a Int) reduces to Bool, say, which gets rid of the occurs-check problem. (For the flat_top Bool, see comments above and at call sites.) HOWEVER, the lazy flattening actually seems to make type inference go *slower*, not faster. perf/compiler/T3064 is a case in point; it gets *dramatically* worse with FM_Avoid. I think it may be because floating the types out means we normalise them, and that often makes them smaller and perhaps allows more re-use of previously solved goals. But to be honest I'm not absolutely certain, so I am leaving FM_Avoid in the code base. What I'm removing is the unique place where it is *used*, namely in TcCanonical.canEqTyVar. See also Note [Conservative unification check] in TcUnify, which gives other examples where lazy flattening caused problems. Bottom line: FM_Avoid is unused for now (Nov 14). Note: T5321Fun got faster when I disabled FM_Avoid T5837 did too, but it's pathalogical anyway }}} In short, here's a project for someone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 11:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 11:59:34 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.ae419c6ab698ed1d0a451a79c79bdaaf@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 gkaracha): Yes, this will probably not be fixed. It is not exactly a bug: Since `a` is a nullary function, there is nothing to print. The only possible thing to print would be something like: {{{#!hs Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In an equation for `a': Patterns not matched: ??? where (x ~ Just i) && (not (odd i)) }}} but there is nothing to actually print as a pattern because you have zero arguments. Additionally, you wrote **"UPDATE: I just realized it's actually worse that I first thought. If I change a in this example: {...} This message is printed: {...}"** but the following gives no warning on my computer: {{{#!hs let a | Just i <- x = True | Nothing <- x = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 12:48:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 12:48:23 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.bda1e5b59194d48589bc58533207f465@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Added testcase in Phab:D1655 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 12:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 12:56:25 -0000 Subject: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# In-Reply-To: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> References: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> Message-ID: <060.2c7486e6987a0a7b7de329a581326a91@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * cc: osa1 (added) Comment: osa1, I believe this is relevant to your recent work on unboxed sums. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:06:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13: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.f988cf31c174f20c4df4046dd29e1c0c@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.0.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 bgamari): * priority: high => normal * status: new => patch * differential: => Phab:D1656 * type: bug => task Comment: Phab:1656 resolves this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13:06:30 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.47112224e1a941129caaceaef7a3c089@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Works for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:10:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13:10:02 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.813bdc8069ab55d2793cfd122e558488@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm looking forward to being able to remove all sorts of helper classes and trickery from my `algebra` and `hask` packages -- and closing out a bunch of longstanding issues. (My tests all worked as expected.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:15:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13:15:36 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind Message-ID: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> #11252: :kind command hides the explicit kind ----------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: TypeInType | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- {{{#!hs -- /tmp/test.hs {-# LANGUAGE TypeInType #-} data Proxy1 k (a :: k) = P1 data Proxy2 (a :: k) = P2 }}} if I load the following into ghci (head) the `:kind` command gives the same result {{{#!haskell % ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> :kind Proxy1 :kind Proxy1 Proxy1 :: k -> * *Main> :kind Proxy2 :kind Proxy2 Proxy2 :: k -> * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:18:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13:18:01 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.cab81e2c0cf8f041cf2ce7b3a380ab79@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{#!hs > -- /tmp/test.hs > {-# LANGUAGE TypeInType #-} > > data Proxy1 k (a :: k) = P1 > data Proxy2 (a :: k) = P2 > }}} > > if I load the following into ghci (head) the `:kind` command gives the > same result > > {{{#!haskell > % ghci -ignore-dot-ghci /tmp/test.hs > GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( test.hs, interpreted ) > Ok, modules loaded: Main. > *Main> :kind Proxy1 > :kind Proxy1 > Proxy1 :: k -> * > *Main> :kind Proxy2 > :kind Proxy2 > Proxy2 :: k -> * > }}} New description: {{{#!hs -- /tmp/test.hs {-# LANGUAGE TypeInType #-} data Proxy1 k (a :: k) = P1 data Proxy2 (a :: k) = P2 }}} if I load the following into ghci (head) the `:kind` command gives the same result {{{#!haskell % ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> :kind Proxy1 :kind Proxy1 Proxy1 :: k -> * *Main> :kind Proxy2 :kind Proxy2 Proxy2 :: k -> * }}} edit: I asked on #ghc, was told this was undesirable -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 13:35:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 13:35:24 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.0ea58009b98fc04729a8ba16645bdf87@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{#!hs > -- /tmp/test.hs > {-# LANGUAGE TypeInType #-} > > data Proxy1 k (a :: k) = P1 > data Proxy2 (a :: k) = P2 > }}} > > if I load the following into ghci (head) the `:kind` command gives the > same result > > {{{#!haskell > % ghci -ignore-dot-ghci /tmp/test.hs > GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( test.hs, interpreted ) > Ok, modules loaded: Main. > *Main> :kind Proxy1 > :kind Proxy1 > Proxy1 :: k -> * > *Main> :kind Proxy2 > :kind Proxy2 > Proxy2 :: k -> * > }}} > > edit: I asked on #ghc, was told this was undesirable New description: {{{#!hs -- /tmp/test.hs {-# LANGUAGE TypeInType #-} data Proxy1 k (a :: k) = P1 data Proxy2 (a :: k) = P2 }}} if I load the following into ghci (head) the `:kind` command gives the same result {{{#!haskell % ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> :kind Proxy1 Proxy1 :: k -> * *Main> :kind Proxy2 Proxy2 :: k -> * }}} edit: I asked on #ghc, was told this was undesirable -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 14:06:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 14:06:39 -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.280944b30ca7021b99aa4e9a5e916ba4@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * status: closed => new * cc: vandijk.roel@? (added) * version: 7.6.3 => 7.10.2 * resolution: fixed => * priority: normal => high Comment: At LumiGuide we're hitting this issue on GHC-7.10.2. We're developing a binding to `opencv-3.0.0` which is a C++ library. The Haskell package is called `thea` and `thea.cabal` specifies the following `cc-options: -O2 -std=c++11`. We also need to build the package using the following cabal flags: `--with-gcc=g++ --with-ld=g++`. Maybe irrelevant but `thea` uses [http://hackage.haskell.org/package/inline-c inline-c] for the FFI. We have another Haskell package called `vision-playground` that depends on `thea`. This all works great. However I need to use some !TemplateHaskell in `TM.Types` (one of the modules of `vision-playground`) and get the following error when doing a `cabal build`: {{{ [1 of 3] Compiling TM.Types ( src/TM/Types.hs, dist/build/vision- playground/vision-playground-tmp/TM/Types.o ) ghc: /nix/store/1wyif1adq0pb9h08jqr0v5lrykfhdhah- opencv-3.0.0/lib/libopencv_hal.a: unknown symbol `_ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5' ghc: unable to load package `thea-0.0.0' }}} I tried the hacks suggested by @rwbarton but they did not work for me. I hope there's a work-around since this is a high priority issue for us at LumiGuide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 14:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 14:19:03 -0000 Subject: [GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) Message-ID: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: pattern | Operating System: Unknown/Multiple matching, exhaustiveness | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #595 Differential Rev(s): | Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation -------------------------------------+------------------------------------- There are some cases where the new exhaustiveness checker emits duplicate warnings. E.g. for `f`: {{{#!hs f :: Bool -> Bool -> () f (not -> True) (not -> False) = () }}} we get: {{{ DuplicateWarn.hs:6:1: warning: Pattern match(es) are non-exhaustive In an equation for ?f?: Patterns not matched: _ _ -- represents (not -> False) _ _ _ -- represents (not -> True) (not -> True) }}} As indicated in the comments, the two comments represent different missing cases, but since we do not print the additional information, they look alike. It would be better to either: * Give additional information to the user to distinguish between the two or * Print a single warning `(_ _)` I cannot think of a nice solution to this yet but I will keep thinking about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 14:19:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 14:19:24 -0000 Subject: [GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) In-Reply-To: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> References: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> Message-ID: <062.677ce293b8bd2339033b2efb32eebcf6@haskell.org> #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | matching, exhaustiveness Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #595 | Differential Rev(s): Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation | -------------------------------------+------------------------------------- Changes (by gkaracha): * Attachment "DuplicateWarn.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 14:20:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 14:20:07 -0000 Subject: [GHC] #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) In-Reply-To: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> References: <047.2aa585f914075d8873b7545ad3bf5669@haskell.org> Message-ID: <062.f3b21eeeb3ecdb1e256bbe0919fd184d@haskell.org> #11253: Duplicate warnings for pattern guards and relevant features (e.g. View Patterns) -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | matching, exhaustiveness Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #595 | Differential Rev(s): Wiki Page: | PatternMatchCheck, | PatternMatchCheckImplementation | -------------------------------------+------------------------------------- Description changed by gkaracha: Old description: > There are some cases where the new exhaustiveness checker emits duplicate > warnings. E.g. for `f`: > {{{#!hs > f :: Bool -> Bool -> () > f (not -> True) (not -> False) = () > }}} > we get: > {{{ > DuplicateWarn.hs:6:1: warning: > Pattern match(es) are non-exhaustive > In an equation for ?f?: > Patterns not matched: > _ _ -- represents (not -> False) _ > _ _ -- represents (not -> True) (not -> True) > }}} > As indicated in the comments, the two comments represent different > missing cases, but since we do not print the additional information, > they look alike. It would be better to either: > * Give additional information to the user to distinguish between the > two or > * Print a single warning `(_ _)` > > I cannot think of a nice solution to this yet but I will keep thinking > about it. New description: There are some cases where the new exhaustiveness checker emits duplicate warnings. E.g. for `f`: {{{#!hs f :: Bool -> Bool -> () f (not -> True) (not -> False) = () }}} we get: {{{ DuplicateWarn.hs:6:1: warning: Pattern match(es) are non-exhaustive In an equation for ?f?: Patterns not matched: _ _ -- represents (not -> False) _ _ _ -- represents (not -> True) (not -> True) }}} As indicated in the comments, the two warnings represent different missing cases, but since we do not print the additional information, they look alike. It would be better to either: * Give additional information to the user to distinguish between the two or * Print a single warning `(_ _)` I cannot think of a nice solution to this yet but I will keep thinking about it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 14:21:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 14:21:09 -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.469340c12d18beb1760b3d14f3cf31f0@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid I'm not terribly familiar with the root cause of this problem but I would be happy to help provided we had something concrete to work with. Could you provide a bit of code so that we can reproduce the issue? Have you checked whether the symbol in question (or symbols like it) is defined in `libopencv_hal.a`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:05:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:05:54 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.ddda63be0ec7c0b35c25ad6e4a76040d@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Example from [https://www.cis.upenn.edu/~eir/papers/2013/fckinds/fckinds- extended.pdf System FC with Explicit Kind Equality (Extended Version)]: {{{#!hs data Kind = Star | Arr Kind Kind data Ty :: Kind -> * where TInt :: Ty Star ... data TypeRep (k :: Kind) (t :: Ty k) where TyInt :: TyRep Star TInt ... }}} gives {{{#!hs >>> :kind TyRep TyRep :: Ty k -> * }}} making the user think they should provide a `Ty k` {{{#!hs >>> :kind TyRep TInt }}} when they should really provide a `Kind` and ''then'' some `Ty k`: {{{#!hs >>> :kind TyRep Star TyRep Star :: Ty 'Star -> * >>> :kind TyRep Star TInt TyRep Star TInt :: * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:16:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:16:14 -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.9d7c5fea2c6a0058c6b5834f2c0aba2f@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Hi Ben, I created a minimal isolated test case that has the same problem: `git clone https://github.com/basvandijk/th-unknown-symbol-test` If you're using Nix a simple `nix-build` will show the problem. If you aren't using Nix you have to install `hs-opencv-binding` yourself (probably in a cabal sandbox) and build `play` manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:38:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:38:52 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.b668420cee71c34398937e44522841f4@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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:"9d921d6bfeec8320f7ad5e4532bf4edadc7f92cd/ghc" 9d921d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d921d6bfeec8320f7ad5e4532bf4edadc7f92cd" Test Trac #11248, #11249 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:38:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:38:53 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types In-Reply-To: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> References: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> Message-ID: <062.fa279507cabb930b7f6663bb9bd9efb2@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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:"9d921d6bfeec8320f7ad5e4532bf4edadc7f92cd/ghc" 9d921d6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d921d6bfeec8320f7ad5e4532bf4edadc7f92cd" Test Trac #11248, #11249 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:38:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:38:53 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.81dc9772be413365cfdfa795edafecfe@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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:"ff752a1a5eb69955c0e4fda8647f495409a2c384/ghc" ff752a1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff752a1a5eb69955c0e4fda8647f495409a2c384" tcCheckSatisfiability: less aggressive superclass expansion In the pattern-match check we are looking for a proof of *unsatisfiablity* among a bunch of givens. The unsat-ness might be hidden in the superclasses, so we must expand them. But in the common case where the constraints are satisfiable, we don't want to expand a recursive superclass forever. This is all a bit arbitrary, but then the whole question is undecidable anyway. The bug in Trac #10592 comment:12 was that I expanded superclasses forever. This patch fixes it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:40:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:40:12 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.afbc16c3d68328e3dc0004bd63bf3f8a@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11248 Comment: Regression test added. I doubt we'll fix the 7.10 branch unless there's a compelling reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:40:34 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types In-Reply-To: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> References: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> Message-ID: <062.6243d9aef855f0ef3175f3a216a21b29@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11249 Comment: Regression test added. I doubt we'll fix the 7.10 branch unless there's a compelling case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:41:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:41:01 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.dfbd7fc15cda94031b22a2dc78b84099@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): MikeIzbicki: OK can you try again now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:41:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:41:58 -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.25f6810efae426a109dfb224f066a58a@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Regarding the symbol in question, note that according to http://demangler.com/ the mangled symbol `_ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5` demangles to: {{{ guard variable for cv::v_invsqrt(cv::v_float32x4 const&)::_0_5 }}} It is defined here: https://github.com/Itseez/opencv/blob/3.0.0/modules/hal/include/opencv2/hal/intrin_sse.hpp#L683 And it indeed occurs in `libopencv_hal.a`: {{{ nm /nix/store/1wyif1adq0pb9h08jqr0v5lrykfhdhah- opencv-3.0.0/lib/libopencv_hal.a 2>/dev/null | grep _ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5 0000000000000000 u _ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:42:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:42:54 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.4b38de1482028bc2d895ae5ec6b9ea15@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => closed * resolution: => fixed Comment: Terrific, thanks. I'll close this. Yay. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:54:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:54:51 -0000 Subject: [GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore In-Reply-To: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> References: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> Message-ID: <060.b936cbe817321522c46e4f31992f7914@haskell.org> #11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Typeable, | isInstance 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 javran): * cc: javran (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:55:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:55:30 -0000 Subject: [GHC] #11250: GHC shows core with error In-Reply-To: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> References: <047.e0e0bd4d071ca8b6578c4ce5d031bb3f@haskell.org> Message-ID: <062.041b5ff379ce5abc8e11cfa7e60fedfa@haskell.org> #11250: GHC shows core with error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 goldfire): * status: new => closed * resolution: => fixed Comment: As far as I can tell, this output is no longer produced on the `ghc-7.10` branch (or in HEAD), so I'm going to close this ticket. Sorry for leaking this output into an RC! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:58:57 -0000 Subject: [GHC] #11254: GHC panic Message-ID: <051.76070f6fcce893e6bc75484414af761d@haskell.org> #11254: GHC panic ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- I like to mix features to make code fail, code inspired by [https://phabricator.haskell.org/diffusion/GHC/browse/master/testsuite/tests /indexed-types/should_compile/T10318.hs$1 T10318]: {{{#!hs -- /tmp/panic.hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeSynonymInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} class (Frac (Frac a) ~ Frac a, Fractional (Frac a), ID (Frac a)) => ID a where type Frac a embed :: a -> Frac a instance ID Rational where type Frac Rational = Int embed :: Rational -> Rational embed = undefined }}} When running it with `defer-type-errors` it causes GHC to panic: {{{#!hs % ghci -fdefer-type-errors -ignore-dot-ghci panic.hs &> panic.log }}} actual error included in panic.log. GHC asks me to report this as a bug and I do as I'm told. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:59:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:59:32 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.73450319f2ddcf65f0b701627e5dcbd6@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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 Iceland_jack): * Attachment "panic.log" added. Output of ghci -fdefer-type-errors -ignore-dot-ghci panic.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 15:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 15:59:59 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.f14e4b1d5955dc84cd6458f303bbe81a@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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 Iceland_jack): * Attachment "panic.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:04:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:04:03 -0000 Subject: [GHC] #11243: Flag to not expand type families In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.13e8f7ecba40455f6f42bf7d73f3e3b8@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon is right. I was thinking of the case in #10321, which is much simpler, as it concerns only output in GHCi. The behavior you're observing does not seem like it will easily succumb to controlling with a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:08:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:08:14 -0000 Subject: [GHC] #9394: Show data/type family instances with ghci's :info command In-Reply-To: <047.01134e82983fb263026aa29a14aa8897@haskell.org> References: <047.01134e82983fb263026aa29a14aa8897@haskell.org> Message-ID: <062.d3e8477ff87502981e57531b39755866@haskell.org> #9394: Show data/type family instances with ghci's :info command -------------------------------------+------------------------------------- Reporter: s9gf4ult | Owner: javran Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: ghci 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 javran): Replying to [comment:8 thomie]: > javran: did you make any progress with this ticket? Maybe just some notes that you could contribute, such that someone else can take over? Come over to the #ghc irc channel if you need help, there are usually people around all day there. Sorry I didn't have time to contribute since I have owned this ticket. I'm just about to continue working this. Previously I sent an email to goldfire and he suggested to begin with writing up new wiki page about the plan -- will do it as a start point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:08:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:08:27 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.9722cb48c71866d1af3cc44a602d2d74@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 your point about this not being a bug, but can't we have a better error message? For example: {{{ Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In the definition for ?a?: Cases not matched: (Just i <- x), not (odd i) }}} Maybe it's hard to get that "cases not matched" so exactly, but at least we can say vaguely that the guards are incomplete, instead of the error suggesting that a list follows but then omitting the list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:12:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:12:00 -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.46438d0e77c750adab8fdba29e546b3b@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I could not reproduce this on Debian Linux. Does "... and build `play` manually" mean something other than...? {{{ cabal sandbox init cabal install hs-opencv-binding/ cabal install play/ }}} Also I seriously doubt that lens is required, can you try simplifying `makeLenses ''MyRecord` to just a `return []`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:16:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:16:53 -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.8b67b79d792099c6f8a63369ce42cdcb@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I should probably add that I am building against the Debian package `libopencv-dev=2.4.9.1+dfsg-1.2` and the `hs-opencv-binding` is dynamically linked against a bunch of OpenCV libraries {{{ rwbarton at morphism:/tmp/th-unknown-symbol-test/hs-opencv-binding/dist/dist- sandbox-3f06d746/build$ ldd libHShs-opencv-binding-0.0.0 -3XpfF7vOgxLEUT7DVeoPSc-ghc7.10.1.so | grep libopencv libopencv_calib3d.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_calib3d.so.2.4 (0x00007f6bd2ec1000) libopencv_contrib.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_contrib.so.2.4 (0x00007f6bd2bda000) libopencv_core.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_core.so.2.4 (0x00007f6bd27a8000) libopencv_features2d.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_features2d.so.2.4 (0x00007f6bd2508000) libopencv_flann.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_flann.so.2.4 (0x00007f6bd229c000) libopencv_gpu.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_gpu.so.2.4 (0x00007f6bd203d000) libopencv_highgui.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_highgui.so.2.4 (0x00007f6bd1df0000) libopencv_imgproc.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_imgproc.so.2.4 (0x00007f6bd195d000) libopencv_legacy.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_legacy.so.2.4 (0x00007f6bd1648000) libopencv_ml.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_ml.so.2.4 (0x00007f6bd13cb000) libopencv_objdetect.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_objdetect.so.2.4 (0x00007f6bd1151000) libopencv_ocl.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_ocl.so.2.4 (0x00007f6bd0d82000) libopencv_photo.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_photo.so.2.4 (0x00007f6bd0b64000) libopencv_stitching.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_stitching.so.2.4 (0x00007f6bd08dc000) libopencv_superres.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_superres.so.2.4 (0x00007f6bd06a1000) libopencv_ts.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_ts.so.2.4 (0x00007f6bd03f1000) libopencv_video.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_video.so.2.4 (0x00007f6bd019a000) libopencv_videostab.so.2.4 => /usr/lib/x86_64-linux- gnu/libopencv_videostab.so.2.4 (0x00007f6bcff5b000) }}} It looks like you are using static linking, for some reason? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:19:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:19:25 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.2fed231566a4055def5de99ffcd62c30@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 gkaracha): Ah, yes, this is easy to do I guess. We can always check every uncovered vector before printing for being `[]`. If yes, we can print something like: {{{ Exhaustive.hs:10:7: warning: Pattern match(es) are non-exhaustive In the definition for ?a?: Cases not matched: (incomplete guards) }}} I am gonna patch this too :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:25:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:25:27 -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.eec5f5afcf0ecc9b2897c289c7845932@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving-perf 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 ezyang): Yes, comment:22 gives a standalone case of how making a type class only have one method improves time. I can try to characterize this further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:27:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:27:35 -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.ffc2abc0e2faca12bc4accc238f969f1@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Hi rwbarton, yes a `cabal sandbox init; cabal install hs-opencv-binding/; cabal install play/` should be all that's required to build manually. I removed the dependency on `lens` like you suggested and the problem remains as expected. Note that I'm linking against `opencv-3.0.0`. It's very likely this has something to do with static vs dynamic linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:28:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:28:59 -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.1b164997aeedf2e060f39fd931ec6e54@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: Also are you using a static GHC somehow? (`ghc --info` outputs `("GHC Dynamic","NO")`?) Otherwise I don't understand how you can be getting an error from ghc's runtime linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:36:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:36:35 -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.76974b9786b1911d2ec655a8673b38d3@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): rwbarton, thanks for investigating! It seems I'm using a dynamic GHC: {{{ $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc- wrapper-4.9.3/bin/cc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc- wrapper-4.9.3/bin/cc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc- wrapper-4.9.3/bin/ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/nix/store/lhgkssg79bxdba541h75mgdvjh35b8ic- perl-5.20.2/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.10.2") ,("Project Git commit id","0da488c4438d88c9252e0b860426b8e74b5fc9e8") ,("Booter version","7.8.4") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/nix/store/aivgsc0vbnq2vi8fzw9xjkrlgayfqppv- ghc-7.10.2/lib/ghc-7.10.2") ,("Global Package DB","/nix/store/aivgsc0vbnq2vi8fzw9xjkrlgayfqppv- ghc-7.10.2/lib/ghc-7.10.2/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:43:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:43:37 -0000 Subject: [GHC] #11252: :kind command hides the explicit kind In-Reply-To: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> References: <051.5f9a6f32b13fc113ab8b4f5fa6280adc@haskell.org> Message-ID: <066.a98bcea5c1c99441d86ccafa1d186e58@haskell.org> #11252: :kind command hides the explicit kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: TypeInType Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Another bug for me. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:46:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:46:02 -0000 Subject: [GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore In-Reply-To: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> References: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> Message-ID: <060.174bec90746a6801fd80ede92c194ac1@haskell.org> #11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Typeable, | isInstance 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): * owner: => goldfire * component: libraries/base => Template Haskell Comment: Will fix. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:54:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:54:07 -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.3d5697aff1e6d7c8f7894f015b61978d@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well I'm a bit stuck being unable to reproduce the behavior you seem to be getting. Here's what I think is going on: 1. Somehow, I don't know how, you're getting GHC's runtime linker involved. I guess this must be due to some difference in configuration of opencv, but I don't understand how. 2. From `man nm`: {{{ "u" The symbol is a unique global symbol. This is a GNU extension to the standard set of ELF symbol bindings. For such a symbol the dynamic linker will make sure that in the entire process there is just one symbol with this name and type in use. }}} GHC's runtime dynamic linker presumably doesn't understand this symbol type since it is a non-standard extension. And that's probably what causes it to report the symbol as not found. Fixing 2 would require changes to GHC, so it probably makes sense to fix 1. But I don't know why you are in this situation. Perhaps build output with `cabal -v` and `ghc -v` would help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 16:56:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 16:56:24 -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.5ebcc916ba285ebdd665422fd65930e8@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): For example, when I build `play` with `cabal install --ghc-option=-v`, I get a bunch of output including the lines {{{ ... Loading package primitive-0.6.1.0 ... linking ... done. Loading package vector-0.11.0.0 ... linking ... done. Loading package lens-4.13 ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown- symbol-test/.cabal-sandbox/lib/x86_64-linux- ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_calib3d.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown- symbol-test/.cabal-sandbox/lib/x86_64-linux- ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_contrib.so ... *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/tmp/th-unknown- symbol-test/.cabal-sandbox/lib/x86_64-linux- ghc-7.10.1/hsope_3XpfF7vOgxLEUT7DVeoPSc --print-file-name libopencv_videostab.so Loading package hs-opencv-binding-0.0.0 ... linking ... done. }}} That means GHC loaded the dynamic OpenCV libraries with `dlopen()`. In your case, it is apparently not doing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 17:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 17:33:21 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.d133929372d5bae607a36707c99dc3b7@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d6b91ea62e974969f203857deaa60f743e42513a/ghc" d6b91ea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6b91ea62e974969f203857deaa60f743e42513a" Add test for T11122 Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1655 GHC Trac Issues: #11122 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 17:37:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 17:37:50 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.9b2c1932df1eed551ab7c5fe4cccdf37@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | 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 simonpj): * owner: => goldfire Comment: Richard, what is the story for deferred type errors? We get a Lint error from the program as follows {{{ cobox_aPt :: Ratio Integer ~# Int [LclId[CoVarId], Str=DmdType] cobox_aPt = typeError @ 'Unlifted @ (Ratio Integer ~# Int) "T11254.hs:16:12: error:...blah..blah... "# $cembed_aP2 :: Rational -> Frac Rational [LclId, Str=DmdType] $cembed_aP2 = (...blah....) `cast` (_R -> Sub (cobox_aPt ; Sym TFCo:R:FracRatio[0]) }}} So we have a top-level unboxed value. That's not right. What became of coercion holes? Obviously the can't call `error`. Writing a `Note` about how deferred type errors fits with unlifted equalities would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 17:39:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 17:39:47 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.b1c960e0d06b7957e5652cfe2924180b@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): I don't understand the argument about the definition not having any arguments. The exhaustiveness checker somehow checking for some patterns, right? And on the process it has to realize that some patterns are not checked. Whatever that it's finding on the process, it should print! Am I missing anything? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 18:40:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 18:40:29 -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.2c3f009bd61fc0621c25bdda34315b45@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Since I'm on NixOS I think it's very likely that OpenCV is build differently than on your Debian system. Here's the full verbose `cabal install` output: {{{ $ cabal install -v --ghc-option=-v ./play/ /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/gcc -dumpversion /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/haddock --version /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hpc version looking for tool hsc2hs near compiler in /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin found hsc2hs in /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs --version /run/current-system/sw/bin/HsColour -version /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc -c /run/user/1001/1804289383846930886.c -o /run/user/1001/16816927771714636915.o -v Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4 Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-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: /run/user/1001/ghc2412_0 *** C Compiler: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -x c /run/user/1001/1804289383846930886.c -o /run/user/1001/ghc2412_0/ghc_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/include/ghcversion.h -I/nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw/include -I/nix/store /xgajz3ndnj863mx3zgmk5fx6c8rssz6v-gmp-5.1.3/include -I/nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/include *** Assembler: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /run/user/1001/ghc2412_0/ghc_1.s -o /run/user/1001/16816927771714636915.o *** Deleting temp files: Deleting: /run/user/1001/ghc2412_0/ghc_1.s *** Deleting temp dirs: Deleting: /run/user/1001/ghc2412_0 /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/ld -x -r /run/user/1001/16816927771714636915.o -o /run/user/1001/1957747793424238335.o /nix/store/v0hr8wc2bfzax11a756lc8j54v98141g-gnutar-1.28/bin/tar --help Reading available packages... Choosing modular solver. Resolving dependencies... Ready to install play-0.0.0 Waiting for install task to finish... Configuring play-0.0.0... Dependency base ==4.8.1.0: using base-4.8.1.0 Dependency hs-opencv-binding ==0.0.0: using hs-opencv-binding-0.0.0 Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4 Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-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: /run/user/1001/ghc2487_0 *** C Compiler: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -x c /run/user/1001/7198853861649760492.c -o /run/user/1001/ghc2487_0/ghc_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/include/ghcversion.h -I/nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/base_GDytRqRVSUX7zckgKqJjgw/include -I/nix/store /xgajz3ndnj863mx3zgmk5fx6c8rssz6v-gmp-5.1.3/include -I/nix/store /55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/nix/store/55dmsb48yf5l2wjhlsalm7lwbp74ycda- ghc-7.10.2/lib/ghc-7.10.2/include *** Assembler: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /run/user/1001/ghc2487_0/ghc_1.s -o /run/user/1001/5965166491189641421.o *** Deleting temp files: Deleting: /run/user/1001/ghc2487_0/ghc_1.s *** Deleting temp dirs: Deleting: /run/user/1001/ghc2487_0 Using Cabal-1.22.4.0 compiled by ghc-7.10 Using compiler: ghc-7.10.2 Using install prefix: /home/bas.van.dijk/.cabal Binaries installed in: /home/bas.van.dijk/.cabal/bin Libraries installed in: /home/bas.van.dijk/.cabal/lib/x86_64-linux- ghc-7.10.2/play-0.0.0-4YsBlLA8LO69MV7S17lkjf Private binaries installed in: /home/bas.van.dijk/.cabal/libexec Data files installed in: /home/bas.van.dijk/.cabal/share/x86_64-linux-ghc-7.10.2/play-0.0.0 Documentation installed in: /home/bas.van.dijk/.cabal/share/doc/x86_64-linux-ghc-7.10.2/play-0.0.0 Configuration files installed in: /home/bas.van.dijk/.cabal/etc No alex found Using ar found on system at: /nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/ar No c2hs found No cpphs found Using gcc version 4.9.3 found on system at: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/gcc Using ghc version 7.10.2 found on system at: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc Using ghc-pkg version 7.10.2 found on system at: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc-pkg No ghcjs found No ghcjs-pkg found No greencard found Using haddock version 2.16.1 found on system at: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/haddock No happy found Using haskell-suite found on system at: haskell-suite-dummy-location Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy- location No hmake found Using hpc version 0.67 found on system at: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hpc Using hsc2hs version 0.67 found on system at: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/hsc2hs Using hscolour version 1.22 found on system at: /run/current-system/sw/bin/HsColour No jhc found Using ld found on system at: /nix/store/klnq8izadq9c5jpg5swfak8kp2zwiijz-gcc-wrapper-4.9.3/bin/ld No lhc found No lhc-pkg found No pkg-config found Using strip version 2.23 found on system at: /nix/store/v7h3j43vx0dz5ahhkxg5z50by2iqc6k1-binutils-2.23.1/bin/strip Using tar found on system at: /nix/store/v0hr8wc2bfzax11a756lc8j54v98141g-gnutar-1.28/bin/tar No uhc found Component build order: executable 'play' creating dist/build creating dist/build/autogen Building play-0.0.0... /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc-pkg init dist/package.conf.inplace Preprocessing executable 'play' for play-0.0.0... Building executable play... creating dist/build/play creating dist/build/play/play-tmp /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/bin/ghc --make -no- link -fbuilding-cabal-package -O -static -outputdir dist/build/play/play- tmp -odir dist/build/play/play-tmp -hidir dist/build/play/play-tmp -stubdir dist/build/play/play-tmp -i -idist/build/play/play-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/play/play-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.8.1.0-4f7206fd964c629946bb89db72c80011 -package-id hs-opencv- binding-0.0.0-8f2416af7a2ee3c9cd620cc714b1aad9 -XHaskell2010 ./play.hs -v Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.4 Using binary package database: /nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/package.cache Using binary package database: dist/package.conf.inplace/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: 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. *** Chasing dependencies: Chasing modules from: *play.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-12-18 16:32:22.959647846 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import OpenCV] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file play.hs Created temporary directory: /run/user/1001/ghc2538_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( play.hs, dist/build/play/play- tmp/Main.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim-0.4.0.0 ... linking ... done. Loading package integer-gmp-1.0.0.0 ... linking ... done. Loading package base-4.8.1.0 ... linking ... done. Loading package hs-opencv-binding-0.0.0 ... linking ... ghc: /nix/store /yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/lib/libopencv_hal.a: unknown symbol `_ZGVZN2cv9v_invsqrtERKNS_11v_float32x4EE4_0_5' *** Deleting temp files: Deleting: /run/user/1001/ghc2538_0/ghc_1.s Warning: deleting non-existent /run/user/1001/ghc2538_0/ghc_1.s *** Deleting temp dirs: Deleting: /run/user/1001/ghc2538_0 ghc: unable to load package `hs-opencv-binding-0.0.0' Failed to install play-0.0.0 cabal: Error: some packages failed to install: play-0.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 18:48:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 18:48:40 -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.5d101838b8a81fa9ae4e7ceb03d15970@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What is the `hs-opencv-binding` package description? e.g. `cabal sandbox hc-pkg describe hs-opencv-binding` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 18:50:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 18:50:32 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.092b8d0d6a25c6194297af89166eba6e@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by goldfire): From TcErrors: {{{ Note [Deferred errors for coercion holes] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose we need to defer a type error where the destination for the evidence is a coercion hole. We can't just put the error in the hole, because we can't make an erroneous coercion. (Remember that coercions are erased for runtime.) Instead, we invent a new EvVar, bind it to an error and then make a coercion from that EvVar, filling the hole with that coercion. Because coercions' types are unlifted, the error is guaranteed to be hit before we get to the coercion. }}} But that's admittedly not the whole story. This also matters, from `TcUnify.buildImplication`: {{{ -- But with the solver producing unlifted equalities, we need -- to have an EvBindsVar for them when they might be deferred to -- runtime. Otherwise, they end up as top-level unlifted bindings, -- which are verboten. See also Note [Deferred errors for coercion holes] -- in TcErrors. }}} The comment describes a check to make sure that we always build an implication when `-fdefer-type-errors` is on (and we're at top-level). I noticed an unexpected `pushTcLevelM` at !TcInstDecls:811 that may throw this check off. Do you have a recommendation for how to improve the documentation? I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 18:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 18:52:28 -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.9d165b1dd35fa866110b4604cb953dc0@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: infoneeded Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): The following is from inside `nix-shell -A env` (i.e. inside an environment which has `hs-opencv-binding` installed): {{{ $ ghc-pkg describe hs-opencv-binding name: hs-opencv-binding version: 0.0.0 id: hs-opencv-binding-0.0.0-8f2416af7a2ee3c9cd620cc714b1aad9 key: hsope_LkixZPC131K3fnJ17eOHEn license: BSD3 exposed: True exposed-modules: OpenCV trusted: False import-dirs: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv- binding-0.0.0/lib/ghc-7.10.2/hs-opencv-binding-0.0.0 library-dirs: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv- binding-0.0.0/lib/ghc-7.10.2/hs-opencv-binding-0.0.0 /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh-opencv-3.0.0/lib data-dir: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv- binding-0.0.0/share/x86_64-linux-ghc-7.10.2/hs-opencv-binding-0.0.0 hs-libraries: HShs-opencv-binding-0.0.0-LkixZPC131K3fnJ17eOHEn extra-libraries: opencv_shape opencv_stitching opencv_objdetect opencv_superres opencv_videostab opencv_calib3d opencv_features2d opencv_highgui opencv_videoio opencv_imgcodecs opencv_video opencv_photo opencv_ml opencv_imgproc opencv_flann opencv_core opencv_hal include-dirs: /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh- opencv-3.0.0/include /nix/store/yd25dral2yg4sdn31iq3cbzf1k2lsqlh- opencv-3.0.0/include/opencv depends: base-4.8.1.0-4f7206fd964c629946bb89db72c80011 haddock-interfaces: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv- binding-0.0.0/share/doc/x86_64-linux-ghc-7.10.2/hs-opencv- binding-0.0.0/html/hs-opencv-binding.haddock haddock-html: /nix/store/9i2cs3qbs78bx8zph68578awirvpk4ja-hs-opencv- binding-0.0.0/share/doc/x86_64-linux-ghc-7.10.2/hs-opencv- binding-0.0.0/html pkgroot: "/nix/store/ij6kvzi44hmwnvkxsxfimvlixaxwfhf4-ghc-7.10.2/lib/ghc-7.10.2" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 19:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 19:40:04 -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.5d03f57d6e32aa43d2a398827f26bcbb@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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => closed * priority: high => normal * version: 7.10.2 => 7.6.3 * resolution: => fixed Comment: Okay, that's helpful and different from how my package was built. I managed to reproduce the error you saw by building an archive with an undefined symbol reference and specifying it with `extra-libraries:` and `extra-lib-dirs:` in `hs-opencv-binding.cabal`. (Of course, it's not a bug that GHC fails when there really is an undefined symbol!) It turns out that the GHC runtime linker is still used in the following situation: When loading a package into GHCi, the last step is to load libraries specified in the `extra-libraries:` field of the package registration. For each such library, GHCi will first try to find a matching shared library in the library path, then try to find a matching static library in the library path, then ask gcc where to find a shared library, and if all those fail, assume that `dlopen` will know where to find the shared library. (`compiler/ghci/Linker.hs`, function `locateLib`.) It is that second case that you are apparently in (I guess you only built OpenCV as a static library) and in that case the static library is loaded by the GHC runtime linker (in `linkPackage` in the same file). That is all fine, except that the GHC runtime linker apparently doesn't understand this `"u"` symbol type. But that is almost certainly unrelated to the original ticket here, so I reset the ticket status back to its previous state. I recommend that you simply use dynamic OpenCV libraries, if at all possible. If not, you will apparently need support for this `"u"` symbol type in the GHCi runtime linker. I'm not sure I understand exactly what the semantics of this symbol type are supposed to be, but it looks fairly straightforward to implement. However, that would obviously require a patch to GHC... so it would probably be easier for you just to use dynamic OpenCV libraries, and avoid the hairiness of the GHC runtime linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 20:01:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 20:01:34 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.f0d9c10d1c9a69e88754c62b55890960@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): OK, I'm coming back to this ticket 16 months later with a much better understanding of the conversation. Gergo's last comment (:19) is informative. I still think that this restriction should be removed in line with what Simon suggests (`CE => CP`). I can't add much to Gergo's worries about the implementation but 1. I hope this two stage type checking could be simplified, it's something I want to eventually look at. 2. One obvious stop-gap solution would be allow a user to provide a separate type signature for the builder. This gets around the whole "not being able to infer the type" problem. This ticket is probably a long way out of cache by now Simon but do you have any thoughts about my first bullet point? do you think it would be possible to refactor the pattern synonym type checking so the type of the builder can be inferred? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 20:14:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 20:14:04 -0000 Subject: =?utf-8?b?W0dIQ10gIzExMjU1OiBFeHBlY3RlZCBraW5kIOKAmGsw4oCZLCBi?= =?utf-8?q?ut_has_kind_=E2=80=98=28forall_k=2E_k=2C_forall_k=2E_k?= =?utf-8?b?KeKAmQ==?= Message-ID: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> #11255: Expected kind ?k0?, but has kind ?(forall k. k, forall k. k)? -------------------------------------+------------------------------------- Reporter: atnnn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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 works in GHC 7.10: {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds, UndecidableInstances #-} type family Default :: k type instance Default = '(Default, Default) }}} But fails in HEAD with: {{{ Expected kind ?k0?, but ?'(Default, Default)? has kind ?(forall k. k, forall k. k)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 20:21:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 20:21:09 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context (was: Add support for explicitly-bidirectional pattern synonyms) In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.ea3704d2b42608b39f19e70e592a8894@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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 mpickering): * cc: douglas.mcclean@? (removed) * blockedby: 5144 => Old description: > Some patterns cannot, by themselves, be turned over into an expression, > so they have to be defined as unidirectional. Maybe the most trivial > example would be > > {{{ > pattern P -> _ > }}} > > Sometimes, however, it would be desirable to give an explicit way of > turning these pattern synonyms into expressions. The PatternSynonyms wiki > page has this example: > > {{{ > import qualified Data.Sequence as Seq > > pattern Empty -> (Seq.viewl -> Seq.EmptyL) > pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) > pattern xs :> x -> (Seq.viewr -> xs Seq.:> x) > > }}} > > It would make a ton of sense to be able to use this cons/snoc notation as > "constructors" for `Seq`s. > > The proposed syntax for this > > {{{ > pattern x :< xs -> (Seq.viewl -> x Seq.:< xs) where > x :< xs = x Seq.<| xs > }}} New description: > The two directions of an explicitly-bidirectional pattern might have utterly different class constraints. After all, the two directions are specified by quite different code. Suppose that > * Pattern `P` (used in a pattern) requires constraints `CR`, and provides constraints `CP` > * Constructor `P` (used in an expression) requires constraints `CE` > > Then I think the only required relationship is this: `CP` must be provable from `CE` (since CP is packaged up in a P-object). Currently, `CE := CP + CR. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 20:23:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 20:23:59 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.0769caf446a94572a14502244339969e@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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 mpickering: Old description: > > The two directions of an explicitly-bidirectional pattern might have > utterly different class constraints. After all, the two directions are > specified by quite different code. Suppose that > > > * Pattern `P` (used in a pattern) requires constraints `CR`, and > provides constraints `CP` > > * Constructor `P` (used in an expression) requires constraints `CE` > > > > Then I think the only required relationship is this: `CP` must be > provable from `CE` (since CP is packaged up in a P-object). > > Currently, `CE := CP + CR. New description: > The two directions of an explicitly-bidirectional pattern might have utterly different class constraints. After all, the two directions are specified by quite different code. Suppose that > > * Pattern `P` (used in a pattern) requires constraints `CR`, and provides constraints `CP` > * Constructor `P` (used in an expression) requires constraints `CE` > > Then I think the only required relationship is this: `CP` must be provable from `CE` (since CP is packaged up in a P-object). Currently, `CE := CP + CR`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 21:12:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 21:12:20 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMTI1NTogRXhwZWN0ZWQga2luZCDigJhrMA==?= =?utf-8?b?4oCZLCBidXQgaGFzIGtpbmQg4oCYKGZvcmFsbCBrLiBrLCBmb3Jh?= =?utf-8?b?bGwgay4gaynigJk=?= In-Reply-To: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> References: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> Message-ID: <059.1ac5419aeda14bc9d30ce152a95cac7c@haskell.org> #11255: Expected kind ?k0?, but has kind ?(forall k. k, forall k. k)? -------------------------------------+------------------------------------- Reporter: atnnn | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I have a fix for this locally. I'm commoning up a bunch of fixes and will validate/push all at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 21:17:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 21:17:26 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.e4ad34c11a654df38f76d4eda599594e@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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 MikeIzbicki): Okay, I understand the limitations a bit better now. Adding the `Logic a ~ Logic (Logic a)` constraint makes it work for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 22:03:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 22:03:41 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.2dd31651f5d57091b57aa593f4191667@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | 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 looked into it. And I can't think of a convenient solution to the problem, which is restricted to instance signatures that produce a deferred type error. The problem is that deferred type errors absolutely must have an enclosing, non-top-level `EvBindsVar` in which to put the error. That's because the deferred type error is now unlifted and so cannot appear at top level. This is also why we can't have deferred kind errors, though there is logic to detect that and report an error without producing bad Core. With instance signatures, the (ab)use of `AbsBinds` means there's just not the right spot to put the `HsWrapper` that does the signature impedence- matching in a spot where the local evidence bindings are in scope. I could create such a spot, but that just doesn't seem like the right way forward. But wait! I've solved it! In parallel, I'm working on rushing my visible- type-application stuff to make it before the feature freeze. It turns out that it needed just such a spot, too, so I'll just reuse it here. So, we just have to wait a few days. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 00:09:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 00:09:50 -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.3ef36de88bb80b46475a46597b985f77@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 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): Would this approach be able to work for associated injective type families? If you had something like this: {{{#!hs class C a where type T a = r | r -> a instance C Int where type T Int = Char newtype WrappedInt = WrapInt Int deriving C }}} Then, if I understand the above proposal, the following code would be generated: {{{#!hs instance C WrappedInt where type T WrappedInt = T Int }}} which would violate injectivity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 01:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 01:12:14 -0000 Subject: [GHC] #4340: Add alignment to hsc2hs template In-Reply-To: <044.7302eb3b745a386507fb3de540273406@haskell.org> References: <044.7302eb3b745a386507fb3de540273406@haskell.org> Message-ID: <059.d107227a70e6e1125b66c7a6b11bb3e0@haskell.org> #4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | 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: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"543127388e8c82bce53b09e904a7ed8562badd22/ghc" 54312738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="543127388e8c82bce53b09e904a7ed8562badd22" Bump hsc2hs submodule Fixes #4340 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 01:57:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 01:57:32 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.c231ee435ad1b82c9159ebd953e15e8d@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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 mpickering): I've looked a bit now. It seems like the correct thing to do is disassemble the `PatSyns` so that the builder/matcher can be handled separately. The way to do this seems to be to modify `ValBindsOut` to use a new datatype instead of `HsBinds`, split apart the pat syn when calculating sccs and then stitch it back together after typechecking if that is still necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 02:47:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 02:47:41 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly Message-ID: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 A.hs file, with a valid header (no B.hs file) and a syntax error: {{{ module A where import B = as7df89a235r a23jk @A#$(&#$A }}} We get different behavior when one-shot compiling and make compiling: {{{ ezyang at sabre:~$ ghc -c A.hs A.hs:4:1: parse error on input `=' ezyang at sabre:~$ ghc --make A.hs A.hs:2:8: Could not find module `B' Use -v to see a list of the files searched for. }}} I feel like the `--make` error is wrong, and we shouldn't actually complain that an import is missing until we build it. But it cuts both ways; if you have a big module graph and you try to `--make`, currently `--make` will report instantaneously if any import is wrong; if we changed this behavior, `--make` would chug along until it actually tried to compile the offending file. It's easy to fix and I can easily submit a patch for it, if people think we should defer the error. Doing this will also let me remove a grievous hack from my fix to #11244. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 02:49:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 02:49:24 -0000 Subject: [GHC] #618: Dependency caching in ghc --make In-Reply-To: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> References: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> Message-ID: <062.415624cb29a2937bf77470aac2295c6e@haskell.org> #618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * cc: ezyang (added) Comment: `ghc-shake` is a compiler plugin which is comparable to `ghc --make`, but caches dependencies (through Shake). Here's an implementation that works with 7.10 (with frontend plugins; that patch hasn't been backported to 7.10) https://github.com/ezyang/ghc-shake -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 02:50:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 02:50:44 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.a27b7a6386cc22ef60515a3b2cf68c5e@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 6.7 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): This is related to #618, as if `ghc --make` remembered dependency information it would not need to preprocess *stable* modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 06:10:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 06:10:54 -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.266cca9f4a6b65e7cc36ea7f42deff94@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:1 simonpj]: > Can you give a concrete example? I finally found one, attempting to figure out how to write something like `reverse` for type-aligned lists. In this case, I use a pattern signature to name an existentially quantified type, but GHC's message doesn't seem to respect that. {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module TAList where import Control.Category import Prelude hiding ((.), id) data TAList (cat :: k -> k -> *) (x :: k) (z :: k) where Nil :: TAList cat x x (:<) :: cat b c -> TAList cat a b -> TAList cat a c infixr 5 :< newtype Op cat x y = Op {op :: cat y x} reverseOntoTA :: TAList cat b d -> TAList (Op cat) d a -> TAList (Op cat) d a reverseOntoTA Nil ys = ys reverseOntoTA ((x :: cat c d) :< (xs :: TAList cat b c)) ys = _ }}} I named the unknown type variable `c`, but GHC says: {{{ Relevant bindings include ys :: TAList (Op cat) d a (bound at TAList.hs:32:58) xs :: TAList cat b b1 (bound at TAList.hs:32:35) x :: cat b1 d (bound at TAList.hs:32:17) reverseOntoTA :: TAList cat b d -> TAList (Op cat) d a -> TAList (Op cat) d a }}} That is, it's decided to name that variable `b1` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 06:13:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 06:13:05 -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.8d52aa745b9649d2c0e41537fafca716@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): It looks like it may be preferring the name of the type variable used in the GADT definition to the one in the pattern, which seems very wrong to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 06:19:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 06:19:01 -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.164d92bc99db3275d88a09a5f78ec15f@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): Now that I know what to look for, I found a much smaller example: {{{#!hs {-# LANGUAGE ExistentialTypes #-} {-# LANGUAGE ScopedTypeVariables #-} data Foop = forall xx . Foop xx blah (Foop (q :: pah)) = _ }}} Here GHC again ignores the requested `pah` variable in favor of `xx`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 09:46:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 09:46:09 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.5f48fbf2a2389ca5bb35beb6b9db2436@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by glaubitz): * Attachment "0001-Add-the-initial-pieces-to-make-sparc64-a-known- archi.patch" added. Initial pieces for sparc64 platform support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 09:46:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 09:46:23 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.b1f66043d7228a1d058a6173ab9a3768@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by glaubitz): * Attachment "0002-On-sparc64-gcc-has-mrelax-in-it-s-default-specs- so-w.patch" added. Explicitly pass "-no-relax" to gcc on ArchSPARC64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 09:48:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 09:48:42 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.70a0125a136943b7987348880d8bb101@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): Alright, I have now successfully tested my modified patches, full build log for ghc 7.10.3 with the patches applied on sparc64 here: > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc64&ver=7.10.3-4&stamp=1450393450 Please review my two *latest* patches 0001-Add-the-initial-pieces-to-make-sparc64-a-known-archi.patch and 0002-On-sparc64-gcc-has-mrelax-in-it-s-default-specs-so-w.patch and apply them once you're happy. Thanks, Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:13:07 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode In-Reply-To: <044.8913742417593b59443e51343d8c3d48@haskell.org> References: <044.8913742417593b59443e51343d8c3d48@haskell.org> Message-ID: <059.1b82bf82c83b779cf2746ed6fb17438b@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: hsc2hs | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2cc5b607df27e702541985f7c4c987806c4ec2a1/ghc" 2cc5b607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cc5b607df27e702541985f7c4c987806c4ec2a1" Documentation, tests for hsc2hs's new #alignment macro Adds two tests (one for Trac #4340 and one for Trac #10272), as well as advice on how to fix your code if `hsc2hs` emits warnings with GHC 8.0 due to a redefinition of `#alignment`. (I also put the advice in the [GHC 8.0 Migration Guide](https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0).) Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1663 GHC Trac Issues: #4340, #10272 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:13:07 -0000 Subject: [GHC] #4340: Add alignment to hsc2hs template In-Reply-To: <044.7302eb3b745a386507fb3de540273406@haskell.org> References: <044.7302eb3b745a386507fb3de540273406@haskell.org> Message-ID: <059.0e34b626bc336ec6c0de98967735ee72@haskell.org> #4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | 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: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2cc5b607df27e702541985f7c4c987806c4ec2a1/ghc" 2cc5b607/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cc5b607df27e702541985f7c4c987806c4ec2a1" Documentation, tests for hsc2hs's new #alignment macro Adds two tests (one for Trac #4340 and one for Trac #10272), as well as advice on how to fix your code if `hsc2hs` emits warnings with GHC 8.0 due to a redefinition of `#alignment`. (I also put the advice in the [GHC 8.0 Migration Guide](https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0).) Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1663 GHC Trac Issues: #4340, #10272 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:13:07 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.73f6d8cbcdd5f51f76db9ccb2e96b454@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b02838405b00bcdeebb44da0a7a9562cd7fda66b/ghc" b028384/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b02838405b00bcdeebb44da0a7a9562cd7fda66b" Add -Nmax RTS feature (#10728) Added maximum core use based on processors -Nmax chooses the minimum of processor count or x Added documentation. Reviewed By: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1650 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:17:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:17:08 -0000 Subject: [GHC] #4340: Add alignment to hsc2hs template In-Reply-To: <044.7302eb3b745a386507fb3de540273406@haskell.org> References: <044.7302eb3b745a386507fb3de540273406@haskell.org> Message-ID: <059.0b1f3dd689a55fd72851d71f35cecad8@haskell.org> #4340: Add alignment to hsc2hs template -------------------------------------+------------------------------------- Reporter: mitar | Owner: RyanGlScott Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (FFI) | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: hsc2hs/T4340 Blocked By: | Blocking: Related Tickets: #10272 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => hsc2hs/T4340 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:18:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:18:00 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode In-Reply-To: <044.8913742417593b59443e51343d8c3d48@haskell.org> References: <044.8913742417593b59443e51343d8c3d48@haskell.org> Message-ID: <059.ff5a110c7776a391d8790f3283919c30@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: hsc2hs | Version: 7.11 Resolution: fixed | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: hsc2hs/T10272 Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Phab:D1436 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => hsc2hs/T10272 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:28:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:28:53 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.ec5d77687ba48216dde4326bcb15a699@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): You could try validating such a fix, if it really is not too much work. There might very well be a regression test against it. Then you could look to see if there is any discussion in the corresponding ticket. I am not sure which option is better from a users' perspective. I would go for the one that makes the implementation of `--make` the simplest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 10:34:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 10:34:18 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.36d7c6eaf99f68838284a51f9f6bd634@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Congratulations with your first GHC patch, Matthew. Still todo: * `-Ndiv`: use the number of processors divided by * `-Nsub`: use the number of processors minus * release notes * tests (use `getNumCapabilities` from `GHC.Conc.Sync`) Maybe you could take care of those as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 11:04:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 11:04:52 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.b4db3c607a17d0e92c0b0d418c2467b0@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by thomie): * cc: slyfox (added) * status: infoneeded => patch Comment: glaubitz: can you `git grep ArchSPARC`, and see if you covered all cases? I see for example that you didn't change libraries/ghci/GHCi/InfoTable.hsc (it's a rather new file), though there is a special case for `ArchSPARC` there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 11:25:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 11:25:09 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.092b3350bf2a8eb53415ced017d629e5@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): First, the single-dash introducing a long-opt is confusing. But let's ignore that one for a moment. Moreover, in the context of `-Ndiv` and `-Nsub` I consider `-Nmax` wrongly named: It should rather be named `-Nmin` to avoid confusion: Intuitively, `-N` denotes {{{N `infixop` }}}, with the binary operators {{{#!hs min, max, add, sub, div, mul :: Int -> Int -> Int }}} and the obvious definitions, this would imply that `-Nmax4` means {{{N `max` 4}}} which is not what's implemented here. The description of the flag alone should rise red flags already: | -N'''max''' chooses the '''min'''imum of processor count or x -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 12:20:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 12:20:34 -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.7d05191d92482f6bc61b4c6303032ba2@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 basvandijk): Thanks for the excellent explanation! I ended up using the HEAD version of OpenCV which doesn't have the `libopencv_hal.a` anymore. `play` now builds successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 12:37:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 12:37:03 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.21f09ed50fbc1e7a5a5e591a6e01f777@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It seems the RTS already has an import for `__mingw_raise_matherr` so just re-exporting it works. I also need to satisfy a few other symbols: {{{ SymI_HasProto_redirect(_fputwc_nolock, fputwc) \ SymI_HasProto_redirect(_fgetwc_nolock, fgetwc) \ SymI_HasProto_redirect(fileno , _fileno) \ SymI_HasProto_redirect(strdup , _strdup) \ }}} Along with {{{ SymI_HasProto(__mingw_raise_matherr) \ SymI_NeedsProto(mingw_app_type) \ }}} Though I need to find a better solution for redirecting the `nolock` version of `fputwc` and `fgetwc` to the locking versions. Now I've reached a fork in the road: Some libraries like `base` require a few symbols in `mingwex`, however they don't seem to specify the libraries in their `package.conf`. Because packages are pre-loaded by the rts then the symbols aren't weak anything. Which means that again, `libmingwex` can't be linked. This leaves me with 3 options: 1. Fix the entire dependency chain from packages like `base` on up. This is a large change but would be consistent. 2. Add all symbols to the RTS as weak symbols in `ocGetNames_PEi386`. Which means every library we load will accept duplicate symbols. So long the symbols haven't been used yet. This would also "fix" #6107 . Doing this will allow you to link in `libmingwex` by just simply adding `-lmingwex -lgcc` to the compiler. This would also make `libmingw32` work. {{{ Loading object (static archive) E:/msys64/home/Tamar/ghc2/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a ... done Loading object (static archive) E:/msys64/home/Tamar/ghc2/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/5.2.0/libgcc.a ... done final link ... done }}} 3. Pre-load `libmingwex` and `libgcc` during the `initLinker` calls for `GHCi` as weak symbols. This will ignore the symbols we already have loaded (they come from `mingwex` anyway). This will fix `GHCi` as in, there's no change needed to use all symbols in `libmingwex`, but `libmingw32` won't work as it will fail on a duplicate symbols. These are the three options I currently see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 13:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 13:08:30 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.c5b2f24db20a9adcabecd5786ad192aa@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I have a repository with an implementation of no# 2 here https://github.com/Mistuke/ghc/tree/trac-11223-fix-symbols-re-exported- from-rts Though I think no# 1 is the proper solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 13:40:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 13:40:42 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.dd03bc227970c5a2e6e0806faadebce0@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): So, I did a git-grep and I don't think the other occurences are relevant for sparc64. For one, compiler/main/DriverPipeline.hs has several tests for ArchSPARC and then passes -mcpu=v9 to gcc which is irrelevant for sparc64 which always defaults -mcpu to "v9" unlike sparc which, by default, matches to -mcpu=v8. The other occurences in question are in libraries/ghci/GHCi/InfoTable.hsc. However, since there is no NGC on sparc64 (yet), I don't think ghci is supported at all, is it? My understanding is that ghci always requires NGC support but I might be wrong. The mention in compiler/llvmGen/LlvmCodeGen/CodeGen.hs seems to apply for NGC-suppored architectures only as well, is it? Basically, my patches just add the necessary changes to make sparc64 known to ghc analog to https://git.haskell.org/ghc.git/commitdiff/9756690fe7aa26aee6955d0b720377d53170c542, plus the SPARC-related change https://git.haskell.org/ghc.git/commitdiff/3b322660f82d0c7c4f7d02523367ebd0e34c5287 which enforces -no-relax. NGC will add some additional mentions of ArchSPARC64 in code in the future. And since GHC's current NGC for SPARC already implements the SPARC V9 ISA but just with 32-bit pointers, it shouldn't be too difficult to add NGC to sparc64 in the future. The current SPARC NGC probably just needs to extended or cloned plus modified for 64-bit pointers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 14:00:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 14:00:41 -0000 Subject: [GHC] #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 Message-ID: <047.efd17d599edaee400b6320c08d507412@haskell.org> #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 ---------------------------------+---------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Building HEAD I get the following on powerpc64: {{{ InfoTable.hsc:80:2: error: #error Unknown architecture InfoTable.hsc: In function ?main?: InfoTable.hsc:80:2: error: #error Unknown architecture InfoTable.hsc:80:2: error: #error Unknown architecture compiling libraries/ghci/dist-install/build/GHCi/InfoTable_hsc_make.c failed (exit code 1) }}} I am working on a fix for powerpc64 and powerpc64le. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 14:08:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 14:08:26 -0000 Subject: [GHC] #449: Very big integer arithmetic crashes GHCi on Windows and Mac In-Reply-To: <046.591a1796564b24cbf9cdc2d3c500f4d5@haskell.org> References: <046.591a1796564b24cbf9cdc2d3c500f4d5@haskell.org> Message-ID: <061.13940085e629f720d2bf3fe20c2ef00e@haskell.org> #449: Very big integer arithmetic crashes GHCi on Windows and Mac -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.4.2 Component: Runtime System | Version: 6.4.1 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: simonmar (added) * failure: => Runtime crash Comment: Indeed. This is fixed in GMP 6.1.0, see #7655. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 14:10:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 14:10:54 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.d7a58dd673c93471ed5172be68b6acec@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 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 slyfox): * cc: slyfox (added) Comment: changeset:a93ab43ab5f40cadbedea2f6342b93c245e91434 should add shared library support for sparc thus should be slightly less painful for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 14:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 14:18:30 -0000 Subject: [GHC] #11258: Add Location to RdrName in FieldOcc Message-ID: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> #11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11019 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Post #11019, there have been some new instances of RdrName that are not located, in particular {{{#!lhs data FieldOcc name = FieldOcc { rdrNameFieldOcc :: RdrName , selectorFieldOcc :: PostRn name name } data AmbiguousFieldOcc name = Unambiguous RdrName (PostRn name name) | Ambiguous RdrName (PostTc name name) deriving (Typeable) }}} Add locations to them -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 17:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 17:17:14 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.2f8393f5ac5f6f5e4b224524c7ff359a@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"59de6e84ff022ddca540724ab1aa0577c6aa2363/ghc" 59de6e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59de6e84ff022ddca540724ab1aa0577c6aa2363" Add sparc64 a known architecture (Ticket #11211) Explicitly pass "--no-relax" on ArchSPARC64 (as ArchSPARC does) where gcc's default specs set "-mrelax" which conflicts with "-Wl,-r". Known architecture will also help extending sparc NCG support 64-bit ABI. Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 17:21:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 17:21:45 -0000 Subject: [GHC] #11211: Please add initial platform support for sparc64 In-Reply-To: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> References: <047.0c48307eb5cf41ce473cd1a37b3d64f0@haskell.org> Message-ID: <062.3bed06922cdbd7fd9e4fc0dca99c0051@haskell.org> #11211: Please add initial platform support for sparc64 ----------------------------------------+------------------------------ Reporter: glaubitz | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by slyfox): * status: patch => closed * resolution: => fixed Comment: Pushed almost as-is: - added missing case clause detected by `./validate` build in `compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs` - used `elem [ArchSPARC, ArchSPARC64]` to check for `-no-relax` workaround Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 18:07:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 18:07:59 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.0df105594bb8f824131b17543261c3db@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): With the fix, three test cases see a diff like the following: {{{ -Q.hs:3:8: - Could not find module ?Data.Set? - It is a member of the hidden package ?containers-@containers-?. +Q.hs:3:1: + Failed to load interface for ?Data.Set? + It is a member of the hidden package ?containers-?. Perhaps you need to add ?containers? to the build-depends in your .cabal file. Use -v to see a list of the files searched for. }}} Arguably, "Could not find module" is a better error message; however, this is indeed the message `-c` gives when it can't find the module, so surely it can't be that bad? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 18:11:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 18:11:18 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.74fed5be9a1aae76d959982804d0d46f@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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 mpickering): This plan runs into problems as we can't given the matcher and builder different `Name`s as they are both in the same namespace so there is no way to disambiguate which one we should choose. As a result, the dependency analysis is still too coarse, all occurrences point to the same thing which is not what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 18:11:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 18:11:20 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.c9e5020f01a5b65f527b6285fa3380cf@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, is this not what `reinitializeGlobals` fixes? I can't easily test for `frontend01` because `reinitializeGlobals` is only implemented for the Core monad? Are they unrelated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 18:18:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 18:18:33 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.236c196e69698d8493a438b8bff4c299@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Yeah, that seems fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 19:30:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 19:30:37 -0000 Subject: [GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit Message-ID: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> #11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: GHCi crash Test Case: ghcilink004, | Blocked By: prog001, and 11 more | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Teach GHCi to use the system runtime linker to load Haskell libraries on powerpc64. See the following test failures. ghcilink004: {{{ ghc-stage2: dir004/libfoo.a: unknown architecture (e_machine == 21) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): loadArchive "dir004/libfoo.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} prog001: {{{ ghc-iserv.bin: /home/peter/ghc/libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.0.0.a: unknown architecture (e_machine == 21) ghc-iserv.bin: loadArchive "/home/peter/ghc/libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.0.0.a": failed CallStack (from ImplicitParams): error, called at libraries/ghci/GHCi/ObjLink.hs:91:21 in ghci-0.0:GHCi.ObjLink ghc-stage2: ghc-iserv terminated (1) }}} Using the system runtime linker fixes 13 failing tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 19:35:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 19:35:57 -0000 Subject: [GHC] #11260: Re-compilation tests fail on powerpc64 Message-ID: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> #11260: Re-compilation tests fail on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- recomp011: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] Linking Main ... 4343 +Linking Main ... 4343 }}} recomp015: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 19:40:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 19:40:59 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 Message-ID: <047.fcb308b656617448e39264eeafa29658@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: debug, T10667 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- debug: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151219 for powerpc64-unknown-linux): dwarfReturnRegNo: Unsupported platform! CallStack (from ImplicitParams): error, called at compiler/nativeGen/Dwarf/Constants.hs:224:19 in ghc:Dwarf.Constants Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Provide DWARF constants for registers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 19:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 19:45:17 -0000 Subject: [GHC] #11262: Test print022: wrong stdout on powerpc64 Message-ID: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> #11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: print022 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi prints a NUL(?) character instead of an 'x'. {{{ () -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23 Breakpoint 0 activated at print022.hs:11:1-7 Stopped at print022.hs:11:1-7 _result :: r = _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 20:44:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 20:44:10 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.cd02dc4eb6c110114c7d4d279710bac8@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10426 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1665 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1665 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:03:05 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.b6ce339a04a1515d914102b504e5e405@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 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 kgardas): Replying to [comment:5 slyfox]: > changeset:a93ab43ab5f40cadbedea2f6342b93c245e91434 should add shared library > support for sparc thus should be slightly less painful for you. yes, but I need static libs first since about twice per year I'm still trying to fix SPARC NCG. And this should be first done for static libs. So this is the reason I push static libs... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:09:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:09:18 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.3c31e218f55f2638389961b0cc1b4001@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1156 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:09:34 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.942f61233b40e6c3d2d53aabc94bfdb7@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1556 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: Phab:D1156 => Phab:D1556 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:10:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:10:50 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.5fbb24ed4ca16cf66409b8295c751d44@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1661 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: Phab:D1556 => Phab:D1661 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:27:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:27:28 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.e19eedde50df4fbb3e09659180699d70@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: patsyn/T10897 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): For me this fails with {{{ Declaration for Single: Iface type variable out of scope: t Cannot continue after interface file error }}} I've had a poke around but the interface file stuff is a complete mystery for me. Someone else with more experience will have to look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:51:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:51:47 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 Message-ID: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10527 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= 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: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:52:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:52:40 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.2d23c405fa10b9979f8b15f444828a22@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: 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: #10527 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * related: 10527 => #10527 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 21:54:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 21:54:52 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.22553b23b801eff83b429d233a1d860c@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: 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: #10527 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jberryman: Old description: > This is perhaps the same bug as #10527 but I'm not sure, as it goes away > with a modest bump to `-fsimpl-tick-factor`. > > I'm developing a library and am seeing this when I go to compile a small > hello-world executable. > > {{{ > : > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.3 for x86_64-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone $fMonadIdentity_$c>>= > 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: 6642 > }}} > > If I remove the `INLINE` from the exported functions it goes away, but > also makes the code much slower (for some reason the way I use the > function in my benchmark suite doesn't exhibit the error). > > It also compiles with `-fsimpl-tick-factor=200`. > > Previously on 7.10.1 I got the same error in a different part of my code > (the test suite) which went away when I moved to 7.10.3. If it's helpful > I can upload the state of the repo, but it's not a small test case. > > Even if this is a duplicate, I'd love some guidance on this: Is this > actually a ghc bug, or is it my fault that I've got too much inlining in > my code (I've never seen anything like this before, and pretty much mark > everything INLINE)? Should I pass this off to my users and should it be > their responsibility to bump `-fsimpl-tick-factor` to work around > regressions in their GHC? If I want to try to work around this in my > library, what strategies could I employ (besides disabling inlining of > exported functions)? New description: This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= 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: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the benchmark suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of my library repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions), and how do I know whether this won't blow up in the same way for users anyway? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 22:03:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 22:03:10 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.b25324f9756c5daf1b9761e370208ed8@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matt): I did some testing on how GCC linker and GHC runtime linker resolve symobols and I found 2 major differences on how they treat symbols from static archives. Let me illustrate them on some examples: Given two C source files which both have the same function defined: {{{ $ cat test1.c int test() { return 111; } $ cat test2.c int test() { return 555; } }}} C and Haskell program that call our test fuction: {{{ $ cat prog1.c #include int test(); int main(int argc, char **argv) { printf("%d\n", test()); return 0; } $ cat prog1.hs module Main (main) where foreign import ccall test :: Int main = print test }}} Build static library from two source files {{{ $ gcc -c test1.c test2.c $ ar rcs libtest1.a test1.o $ ar rcs libtest2.a test2.o }}} Now this is where it gets interesting: {{{ $ gcc prog1.c test1.o -L. -ltest2 $ ./a.exe 111 $ gcc prog1.c -L. -ltest1 -ltest2 $ ./a.exe 111 }}} As you can see gcc will happily link both programs. Test function was resolved from first object file/static library while other one is ignored. However GHC runtime linker fails to link both programs with duplicate symbols error: {{{ $ ghci prog1.hs test1.o -L. -ltest2 GHC runtime linker: fatal error: I found a duplicate definition for symbol _test whilst processing object file .\libtest2.a ... $ ghci prog1.hs -L. -ltest1 -ltest2 GHC runtime linker: fatal error: I found a duplicate definition for symbol _test whilst processing object file .\libtest2.a ... }}} So this is '''1st major difference''': duplicate symbols from static archives seem to be ignored by GCC, while GHC runtime linker errors out on them. Now the 2nd point. In new 3rd file we define function that calls function which isn't defined anywhere. {{{ $ cat test3.c /* this function is nowhere defined */ void bla_bla(); /* this function is not called at all */ void test_uncalled() { bla_bla(); } }}} Make new static library with first object file and this 3rd one that contains call to undefined function. {{{ $ gcc -c test3.c $ ar rcs libtest3.a test1.o test3.o }}} And try to run both C and Haskell example: {{{ $ gcc prog1.c -L. -ltest3 $ ./a.exe 111 $ ghci prog1.hs -L. -ltest3 linking extra libraries/objects failed ghc.exe: .\libtest3.a: unknown symbol `_bla_bla' }}} As you can see GHCi errors out with unknown symbol to function in object file we do not call, while GCC seems to ignore it. So based on this '''2nd major difference''': GCC seems to ignores symbols from object files in static archive which are not used while GHC runtime linker tries to eagerly resolve all object files, even those that are not called into. I think because of this 2nd difference we end up with all kinda strange unresolved symbols like `__image_base` and similar which cause so much problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 22:13:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 22:13:40 -0000 Subject: [GHC] #4914: FPU initialization required again In-Reply-To: <044.5e0f305cf70ec5dad0ec5591490a619f@haskell.org> References: <044.5e0f305cf70ec5dad0ec5591490a619f@haskell.org> Message-ID: <059.699ceee4e6960930f208b4d235bb4fe8@haskell.org> #4914: FPU initialization required again ------------------------------------------------+------------------------- Reporter: aruiz | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler (NCG) | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect result at runtime | Test Case: Blocked By: | Blocking: ------------------------------------------------+------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"34eaf2b8d699c49ba367f26840052c8c9aa031b1/ghc" 34eaf2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34eaf2b8d699c49ba367f26840052c8c9aa031b1" Fix two occurences of `x86_HOST_ARCH` The proper name for the define is `i386_HOST_ARCH` One was introduced back in 2011 via 035b8ebb5405efbcbfd3474821a877add1feca1e / #4914 and the other one more recently via 4905b83a2d448c65ccced385343d4e8124548a3b We may want to add some validation to catch such typos early on... Reviewed By: erikd Differential Revision: https://phabricator.haskell.org/D1664 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 22:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 22:24:24 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.a1b439ee3359847880dd36727b3722c0@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.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): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1666 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 22:31:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 22:31:08 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.745bd39f3d0b25b2a99576faac37be4e@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: 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: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by jberryman): * related: #10527 => #10527 #5539 #8319 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 00:08:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 00:08:20 -0000 Subject: [GHC] #11205: Validation on ARM fails to due Corex-A8 erratum check In-Reply-To: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> References: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> Message-ID: <061.4dafcec6be313e93a7d7f1bc4e9bb4f2@haskell.org> #11205: Validation on ARM fails to due Corex-A8 erratum check ---------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1599 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by bgamari): Hi Thomie; I am quite certain I am on `master`. In particular, with b02838405b00bcdeebb44da0a7a9562cd7fda66b with Phab:D1599 I am seeing this issue despite, {{{ $ git show commit c625506556698a9d695c720ca87cefab4a1f018d Author: Ben Gamari Date: Fri Dec 11 15:18:43 2015 +0100 config.mk.in: Disable stripping by default on ARM The Cortex A8 hardware apparently has a bug which ld.gold will try to correct; however in order to do so it must have unstripped executables lest we see warnings of the form (see #10376, #10464), /usr/bin/ld.gold: warning: cannot scan executable section 1 of ... for Cortex-A8 erratum because it has no mapping symbols. Consequently we disabling stripping by default on this architecture. diff --git a/mk/config.mk.in b/mk/config.mk.in index d7cd05b..38cb262 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -755,6 +755,17 @@ endif ifeq "$(TARGETPLATFORM)" "x86_64-unknown-mingw32" STRIP_CMD = $(TOP)/inplace/mingw/bin/strip.exe +elif "$(TARGETPLATFORM)" "arm-unknown-linux" +# The Cortex A8 hardware apparently has a bug which ld.gold will check for; +# however in order to do so it must have unstripped executables lest we +# see warnings of the form (see #10376, #10464), +# +# /usr/bin/ld.gold: warning: cannot scan executable section 1 of ... for +# Cortex-A8 erratum because it has no mapping symbols. +# +# Consequently we disabling stripping by default on this architecture. +# The hack of using `:` to disable stripping is implemented by ghc-cabal. +STRIP_CMD = : else STRIP_CMD = strip endif [0105 ben at odroid ghc(D1599)] $ make show! VALUE=TARGETPLATFORM make --no-print-directory -f ghc.mk show NO_INCLUDE_PKGDATA=YES TARGETPLATFORM="arm-unknown-linux" $ ./validate >log 2>&1 ... Wait many hours. Tests fail with above messages $ grep strip log checking for arm-unknown-linux-strip... no checking for strip... strip checking for arm-unknown-linux-strip... strip checking whether stripping libraries is possible... yes # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. for i in driver/ghc-usage.txt driver/ghci-usage.txt includes/dist- derivedconstants/header/platformConstants settings; do case $i in *.a) /usr/bin/install -c -m 644 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219"; true "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219" ; strip "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219" ;; *.dylib) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219";; *) /usr/bin/install -c -m 644 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219"; esac; done # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts- ghc7.11.20151219.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_debug-ghc7.11.20151219.so rts/dist/build /libHSrts_thr-ghc7.11.20151219.so rts/dist/build/libHSrts_thr_debug- ghc7.11.20151219.so rts/dist/build/libHSrts_l-ghc7.11.20151219.so rts/dist/build/libHSrts_thr_l-ghc7.11.20151219.so rts/dist/build/libffi.so.6.0.4 rts/dist/build/libffi.so.6 rts/dist/build/libffi.so rts/dist/build/libCffi.a rts/dist/build/libCffi_l.a rts/dist/build/libCffi_debug.a rts/dist/build/libCffi_thr.a rts/dist/build/libCffi_thr_debug.a rts/dist/build/libCffi_thr_l.a; do case $i in *.a) /usr/bin/install -c -m 644 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts"; true "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts" ; strip "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts";; *) /usr/bin/install -c -m 644 $i "/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219/rts"; esac; done "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/wo rk/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /integer-gmp dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt /work/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/base dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/work/a rm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/filepath dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/wo rk/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/array dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/work/ arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/deepseq dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/wor k/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/bytestring dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/ work/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/containers dist-install "strip" '' '/mnt/work/arm/ghc/ghc/bindisttest/install dir' '/mnt/work/arm/ghc/ghc/bindisttest/install dir/lib/ghc-7.11.20151219' '/mnt/ work/arm/ghc/ghc/bindisttest/install dir/share/doc/ghc/html/libraries' 'v dyn' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 00:37:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 00:37:46 -0000 Subject: [GHC] #11264: Previously compiling example does not compile Message-ID: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 00:39:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 00:39:30 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.ef04e32439389beb94efab901ecf2fb3@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => typecheck/should_compile/ClassOperator * failure: None/Unknown => GHC rejects valid program * milestone: => 8.0.1 * priority: normal => high Old description: New description: The example in the testcase introduced in Phab:D1667 currently fails with, {{{ ClassOperator.hs:12:3: error: ? Could not deduce (a ><> b0) from the context: a ><> b bound by the type signature for: (**>) :: (a ><> b) => a -> a -> () at ClassOperator.hs:12:3-44 The type variable ?b0? is ambiguous ? In the ambiguity check for ?**>? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: (**>) :: forall a b. (a ><> b) => a -> a -> () In the class declaration for ?><>? ClassOperator.hs:12:3: error: ? Could not deduce (a ><> b0) from the context: a ><> b bound by the type signature for: (**<) :: (a ><> b) => a -> a -> () at ClassOperator.hs:12:3-44 The type variable ?b0? is ambiguous ? In the ambiguity check for ?**<> b) => a -> a -> () In the class declaration for ?><>? ClassOperator.hs:12:3: error: ? Could not deduce (a ><> b0) from the context: a ><> b bound by the type signature for: (>**) :: (a ><> b) => a -> a -> () at ClassOperator.hs:12:3-44 The type variable ?b0? is ambiguous ? In the ambiguity check for ?>**? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: (>**) :: forall a b. (a ><> b) => a -> a -> () In the class declaration for ?><>? ClassOperator.hs:12:3: error: ? Could not deduce (a ><> b0) from the context: a ><> b bound by the type signature for: (<**) :: (a ><> b) => a -> a -> () at ClassOperator.hs:12:3-44 The type variable ?b0? is ambiguous ? In the ambiguity check for ?<**? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: (<**) :: forall a b. (a ><> b) => a -> a -> () In the class declaration for ?><>? }}} This is a regression relative to 7.10.2, which accepts the program without error. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 03:40:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 03:40:22 -0000 Subject: [GHC] #11265: Internal error, using pattern synonym as instance head Message-ID: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> #11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 {-# LANGUAGE PatternSynonyms, DataKinds #-} pattern A = True class F a instance F A }}} when loaded in ghci it results in an internal error {{{!#hs % g internal.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( internal.hs, interpreted ) internal.hs:5:12: error: ? GHC internal error: ?A? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the first argument of ?F?, namely ?A? In the instance declaration for ?F A? Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 03:41:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 03:41:16 -0000 Subject: [GHC] #11265: Internal error, using pattern synonym as instance head In-Reply-To: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> References: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> Message-ID: <066.414692e3a0a811aa9e35b0b1cafd6275@haskell.org> #11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{!#hs > {-# LANGUAGE PatternSynonyms, DataKinds #-} > > pattern A = True > > class F a > instance F A > }}} > > when loaded in ghci it results in an internal error > > {{{!#hs > % g internal.hs > GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( internal.hs, interpreted ) > > internal.hs:5:12: error: > ? GHC internal error: ?A? is not in scope during type checking, but > it passed the renamer > tcl_env of environment: [] > ? In the first argument of ?F?, namely ?A? > In the instance declaration for ?F A? > Failed, modules loaded: none. > Prelude> > }}} New description: {{{#!hs {-# LANGUAGE PatternSynonyms, DataKinds #-} pattern A = True class F a instance F A }}} when loaded in ghci it results in an internal error {{{#!hs % g internal.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( internal.hs, interpreted ) internal.hs:5:12: error: ? GHC internal error: ?A? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the first argument of ?F?, namely ?A? In the instance declaration for ?F A? Failed, modules loaded: none. Prelude> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:12:38 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 Message-ID: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 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: -------------------------------------+------------------------------------- Trying to `:browse` certain modules with GHCi fails with GHC 7.11: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help ?> :browse GHC.Base ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b ($!) :: (a -> b) -> a -> b data Ordering*** Exception: No match in record selector tyConTyVars ?> :browse GHC.Exts class GHC.Exts.IsList l where type family GHC.Exts.Item l Kind: * -> * GHC.Exts.fromList :: [GHC.Exts.Item l] -> l GHC.Exts.fromListN :: Int -> [GHC.Exts.Item l] -> l GHC.Exts.toList :: l -> [GHC.Exts.Item l] {-# MINIMAL fromList, toList #-} data GHC.Prim.MutableByteArray# a*** Exception: No match in record selector tyConTyVars ?> :browse GHC.Prim *** Exception: No match in record selector tyConTyVars }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:19:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:19:43 -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.e3495fff09e2951a4dc9fefe6b4cfc25@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: 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): * milestone: 8.0.1 => 8.2.1 Comment: Yes, as well it should. Derived instances are still type-checked, so this would be caught with no special-casing. I could imagine that the error message would be hard to understand, but that's the worst that would happen. But this isn't going to happen by the 8.0 feature freeze, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:22:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:22:27 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.dae68f07db9466c01cd6e55437a4166e@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 RyanGlScott): This might possibly be related: running the following command in GHCi yields an error: {{{ $ ghc/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeInType -XRankNTypes ?> :kind! forall (a :: k). 'Just a :1:14: error: ? GHC internal error: ?k? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the kind ?k? In the type ?forall (a :: k). Just a? }}} Yet putting it into a module makes it compile without issues: {{{ {-# LANGUAGE RankNTypes, TypeInType #-} module InternalError where type T = forall (a :: k). 'Just a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:34:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:34:44 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command Message-ID: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- I was playing around with GHCi's `:kind` command and noticed that trying to ascribe a type with a kind doesn't parse: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeInType ?> :kind 'True :: Bool :1:7: error: parse error on input ?::? }}} This seems like something that should be able to parse, given that `:type True :: Bool` parses just fine. Is there a reason it couldn't? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:36:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:36:32 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.032c7308b1da17a5c33b136ef029c4aa@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D1669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:37:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:37:40 -0000 Subject: [GHC] #11265: Internal error, using pattern synonym as instance head In-Reply-To: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> References: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> Message-ID: <066.06244ecfea01e56a4263a568e7b961f2@haskell.org> #11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: This smells like my fault, but it also looks quite easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:42:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:42:49 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command In-Reply-To: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> References: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> Message-ID: <065.a58ee31ad3172ace0024c78954f12c9a@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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 goldfire): Kind ascriptions in types require parentheses (and have for some time). Not sure precisely why, but I'm sure that the parser would be made more complicated by relaxing this restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 04:47:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 04:47:56 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command In-Reply-To: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> References: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> Message-ID: <065.6763e74fc78b3d777dc749ee09ed730d@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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 RyanGlScott): I was afraid of that. If it would be too much work to change, then we could close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 10:03:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 10:03:39 -0000 Subject: [GHC] #11258: Add Location to RdrName in FieldOcc In-Reply-To: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> References: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> Message-ID: <059.0f56cf58d8412dd6075e87437945e207@haskell.org> #11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11019 | Differential Rev(s): Phab:D1670 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1670 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 10:11:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 10:11:43 -0000 Subject: [GHC] #11268: Extend ghc environment file features Message-ID: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: highest | Milestone: 8.0.1 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): Phab:D1668 | Wiki Page: -------------------------------------+------------------------------------- This is essential to make it into GHC 8.0.1 as it provides the infrastructure for cabal's new features See Phab:D1668 for more detail -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 10:11:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 10:11:49 -0000 Subject: [GHC] #11268: Extend ghc environment file features In-Reply-To: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> References: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> Message-ID: <057.5ec29f0eb35fce56abdd6d8e7ee1d15f@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 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:D1668 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 10:19:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 10:19:30 -0000 Subject: [GHC] #11268: Extend ghc environment file features In-Reply-To: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> References: <042.b9d05badcb9b043d04acfc68ffd50c5e@haskell.org> Message-ID: <057.4f7a29986e9cde24917e3d78c68f8a61@haskell.org> #11268: Extend ghc environment file features -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: feature request | Status: patch Priority: highest | Milestone: 8.0.1 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:D1668 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => bgamari Comment: assigning to Ben as he's been discussing this patch with Duncan already -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 11:46:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 11:46:49 -0000 Subject: [GHC] #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi In-Reply-To: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> References: <042.bc0030991d1508d8ebcd4c859c529fc3@haskell.org> Message-ID: <057.6cb1e0a14bdc9d4af1787f3cbc557416@haskell.org> #10874: Implement `:type-at`, `:all-types`, `:loc-at` in GHCi -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | 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:D1240 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"dd56eb1efc11bcbd60ab0b77ca3e4f949d7d0844/ghc" dd56eb1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd56eb1efc11bcbd60ab0b77ca3e4f949d7d0844" Merge new commands from ghci-ng (re #10874) This adds the new commands `:all-types`, `:loc-at`, `:type-at`, and `:uses` designed for editor-integration (such as Emacs' `haskell-mode`). This was originally implemented by Chris Done on https://github.com/chrisdone/ghci-ng and has been in use by Emacs' `haskell-mode` for over a year already, and closely missed the GHC 7.10 release back then. I've squashed the commits, rebased to GHC HEAD, and heavily refactored and improved the patch. Tests will be added in a separate commit. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1240 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 12:01:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 12:01:30 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.9ef5152d74327edd670945c6a873a4c7@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Here's two less controversial variants to `-Nmax` I wouldn't object to: - `-maxN` (this follows common conventions for `max` used for upper- bounding, c.f. `find . -mindepth -maxdepth ` - Use a single letter option, e.g. `-n `; this follows current `+RTS --help` convention, c.f. {{{ -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G }}} For reference, here's the current output of `ghc +RTS --help` for GHC HEAD, where `-Nmax` clearly deviates from the existing naming conventions: {{{ ghc: unknown RTS option: --help ghc: ghc: Usage: [+RTS | -RTS ] ... --RTS ghc: ghc: +RTS Indicates run time system options follow ghc: -RTS Indicates program arguments follow ghc: --RTS Indicates that ALL subsequent arguments will be given to the ghc: program (including any of these RTS flags) ghc: ghc: The following run time system options are available: ghc: ghc: -? Prints this message and exits; the program is not executed ghc: --info Print information about the RTS used by this program ghc: ghc: -K Sets the maximum stack size (default: 80% of the heap) ghc: Egs: -K32k -K512k -K8M ghc: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m ghc: -kc Sets the stack chunk size (default 32k) ghc: -kb Sets the stack chunk buffer size (default 1k) ghc: ghc: -A Sets the minimum allocation area size (default 512k) Egs: -A1m -A10k ghc: -n Allocation area chunk size (0 = disabled, default: 0) ghc: -O Sets the minimum size of the old generation (default 1M) ghc: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G ghc: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G ghc: -m Minimum % of heap which must be available (default 3%) ghc: -G Number of generations (default: 2) ghc: -c Use in-place compaction instead of copying in the oldest generation ghc: when live data is at least % of the maximum heap size set with ghc: -M (default: 30%) ghc: -c Use in-place compaction for all oldest generation collections ghc: (the default is to use copying) ghc: -w Use mark-region for the oldest generation (experimental) ghc: -I Perform full GC after idle time (default: 0.3, 0 == off) ghc: ghc: -T Collect GC statistics (useful for in-program statistics access) ghc: -t[] One-line GC statistics (if omitted, uses stderr) ghc: -s[] Summary GC statistics (if omitted, uses stderr) ghc: -S[] Detailed GC statistics (if omitted, uses stderr) ghc: ghc: ghc: -Z Don't squeeze out update frames on stack overflow ghc: -B Sound the bell at the start of each garbage collection ghc: ghc: -h Heap residency profile (output file .hp) ghc: -i Time between heap profile samples (seconds, default: 0.1) ghc: ghc: -C Context-switch interval in seconds. ghc: 0 or no argument means switch as often as possible. ghc: Default: 0.02 sec. ghc: -V Master tick interval in seconds (0 == disable timer). ghc: This sets the resolution for -C and the heap profile timer -i, ghc: and is the frequence of time profile samples. ghc: Default: 0.01 sec. ghc: ghc: -N[] Use processors (default: 1, -N alone determines ghc: the number of processors to use automatically) ghc: -qg[] Use parallel GC only for generations >= ghc: (default: 0, -qg alone turns off parallel GC) ghc: -qb[] Use load-balancing in the parallel GC only for generations >= ghc: (default: 1, -qb alone turns off load-balancing) ghc: -qa Use the OS to set thread affinity (experimental) ghc: -qm Don't automatically migrate threads between CPUs ghc: -qi If a processor has been idle for the last GCs, do not ghc: wake it up for a non-load-balancing parallel GC. ghc: (0 disables, default: 0) ghc: --install-signal-handlers= ghc: Install signal handlers (default: yes) ghc: -e Maximum number of outstanding local sparks (default: 4096) ghc: -xm Base address to mmap memory in the GHCi linker ghc: (hex; must be <80000000) ghc: -xq The allocation limit given to a thread after it receives ghc: an AllocationLimitExceeded exception. (default: 100k) ghc: ghc: RTS options may also be specified using the GHCRTS environment variable. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 12:29:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 12:29:59 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.8b7b00986b029049cbcbb24176d05c47@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:15 hvr]: > Here's two less controversial variants to `-Nmax` I wouldn't object to: > > - `-maxN` (this follows common conventions for `max` used for upper- bounding, c.f. `find . -mindepth -maxdepth ` > - Use a single letter option, e.g. `-n ` I'm ok with either of those as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 13:58:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 13:58:18 -0000 Subject: [GHC] #11269: powerpc64le: Build fails in rts/Linker.c Message-ID: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> #11269: powerpc64le: Build fails in rts/Linker.c -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime | Version: 7.11 System (Linker) | Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building HEAD: {{{ rts/Linker.c: In function ?do_Elf_Rel_relocations?: rts/Linker.c:4978:23: error: error: cast from pointer to integer of different size [-Werror =pointer-to-int-cast] Elf_Addr P = ((Elf_Addr)targ) + offset; ^ rts/Linker.c:4979:22: error: error: cast to pointer from integer of different size [-Werror=int- to-pointer-cast] Elf_Word* pP = (Elf_Word*)P; ^ }}} Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 14:32:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 14:32:59 -0000 Subject: [GHC] #11058: selected processor does not support ARM mode In-Reply-To: <046.179fa65419f6552c89ce7f996b230033@haskell.org> References: <046.179fa65419f6552c89ce7f996b230033@haskell.org> Message-ID: <061.8bfefd82d9bbf180ef0ef61477f6d53d@haskell.org> #11058: selected processor does not support ARM mode ----------------------------------------+------------------------------ Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by glaubitz): Replying to [comment:9 erikd]: > This gets stranger still. If I simply revert commit `933adc0f31164cb651d` (on master) it still doesn't build on `armel`. Works here. I took 7.10.3-4 from Debian, reverted the change and was immediately able to build ghc again. My suggested workaround in Debian is therefore to revert the change when compiling on armel while keeping the change on all other architectures. This will allow us to continue using ghc on armel again and in the future, this issue will hopefully be fixed properly. Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 14:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 14:56:37 -0000 Subject: [GHC] #11269: powerpc64le: Build fails in rts/Linker.c In-Reply-To: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> References: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> Message-ID: <062.99a5fefacaf3fb5cf712c050853a429d@haskell.org> #11269: powerpc64le: Build fails in rts/Linker.c -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1672 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D1672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 14:59:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 14:59:44 -0000 Subject: [GHC] #11258: Add Location to RdrName in FieldOcc In-Reply-To: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> References: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> Message-ID: <059.6c91eca8480105e2e6392e11c72e4110@haskell.org> #11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11019 | Differential Rev(s): Phab:D1670 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 17:13:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 17:13:45 -0000 Subject: [GHC] #11266: Can't :browse some modules with GHCi 7.11 In-Reply-To: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> References: <050.2d71edf257c5fc583e5495abd62ddd6f@haskell.org> Message-ID: <065.bbb2da6d82af1f808cba858aea05011b@haskell.org> #11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: goldfire (added) Comment: This bug is introduced with kind equality patch, at this line: https://github.com/ghc/ghc/blame/6746549772c5cc0ac66c0fce562f297f4d4b80a2/compiler/iface/MkIface.hs#L1415 (also related with lines 1422-1424). CCing Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 19:47:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 19:47:47 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O Message-ID: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- UNPACK pragmas are ignored when -O is not used, and this is very annoying when developing inside GHCi. Example: {{{ ? unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp --make [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} No warning printed even though I used {{{-Wall}}}. If I add {{{-O}}}: {{{ ? unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp --make -O [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:5:13: warning: ? Ignoring unusable UNPACK pragma on the first argument of ?Blah? ? In the definition of data constructor ?Blah? In the data type declaration for ?Blah? Linking Main ... }}} This is very annoying, because {{{-O}}} is ignored in GHCi: {{{ ? unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp -O --interactive when making flags consistent: warning: -O conflicts with --interactive; -O ignored. GHCi, version 7.11.20151220: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main. }}} So basically there's no way to get these warning in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 23:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 23:47:40 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.6809b21a7757187659c7e5e95c8bdfb4@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10426 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1665 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"8d954125604e4585167306c4f1d4807275be0a61/ghc" 8d954125/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d954125604e4585167306c4f1d4807275be0a61" Disallow empty where bindings in pattern synonym declarations. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1665 GHC Trac Issues: #10426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 20 23:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Dec 2015 23:47:40 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.f7432a7e26f2f560f2d41bab1e6fb6c7@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T9739 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"44640af7afa1a01ff2e2357f7c1436b4804866fc/ghc" 44640af7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44640af7afa1a01ff2e2357f7c1436b4804866fc" Allow as-patterns in pattern synonym declarations. We can allow them if they contain no free variables. This patch just allows them in one direction and not to be used as builders as the original ticket suggests. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1666 GHC Trac Issues: ?#9739 Conflicts: testsuite/tests/patsyn/should_fail/all.T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 00:00:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 00:00:38 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.a4760ca85b88597d3735ba50343525f5@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10426 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1665 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 01:37:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 01:37:09 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.4d39a7e319279c003682df829cf8dee8@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by duairc): While I can see how the `Eq1`, `Ord1`, `Read1` and `Show1` classes could be useful in their own right, is it set in stone that the `Eq`, `Ord`, `Read` and `Show` instances of the various functors must use them? Why can't the `Eq` instance for `Compose` just be `Eq (f (g a)) => Eq (Compose f g a)`? Do we care about Haskell98 compatibility in `base`? I don't have a strong opinion either way for `Eq`, `Ord`, `Read` and `Show`, but I would slightly prefer instances of the form I have above. What I'm really interested in is the other type classes for which the functors could have instances. Do we need to make a `Semigroup1`, a `Monoid1` if we want to make `Compose` an instance of `Semigroup` and `Monoid`? What about a `Storable1`? Or can we just make an instance `Storable (f (g a)) => Eq (Compose f g a)`? I would basically like to make as many of these instances as possible, because I'm working on something at the moment that uses a lot of functors and potentially compositions of functors, but I want to "keep" as many of the instances of my base types as possible. I'd be happy to do up a patch that made as many of these instances as possible, but I'm wondering would I be expected to make all those extra classes, or could I just make the non-Haskell98 instances? And if so, is there any good reason not to just do the same for `Eq`, `Ord`, `Read` and `Show`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 03:46:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 03:46:16 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.764072cbc43e12963c28d1b761a4d57c@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by ekmett): @duairc: The benefit of having `Eq1`, `Ord1`, etc. in the first place is that the resulting instances are fully Haskell 98 and do not require language extensions at all. {{{#!hs instance Eq (f (g a)) => Eq (Compose f g a) }}} requires `FlexibleContexts`. This means that `transformers` which works on *every* compiler since Haskell 98 _without any CPP_ simply could not accept instances of this form. Even allowing for that, it is beneficial to allow things like {{{#!hs instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) }}} because instances like that are more useful in the presence of polymorphic recursion than the at-first-glance simpler pointwise `Eq` instance, because it says something fundamental about how the instances are defined: that it isn't able to do something hinky with the argument type, and do something fundamentally different for `Compose Foo [] Int` vs. `Compose Foo [] Double`, that both have to use the `Eq` or `Ord` or `Read` or `Show` instance for 'Int' or `Double` in a homogeneous way, not separate `FlexibleInstances`. This is confidence you do not get from the pointwise definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 04:36:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 04:36:44 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.1f91e7cab27be38f4b70c5d99d79aa40@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by duairc): I understand that. Like I said, I can see why `Eq1`, etc. are useful in their own right. But the questions I was really asking are: 1. Do we care about Haskell 98 compatibility in base? 2. If not, could I add an instance e.g., `Semigroup (f (g a)) => Semigroup (Compose f g a)`? There are a bunch of non-Haskell 98 instances I would like to add, especially for `Compose`. Some of these could be made into Haskell 98-compatible instances with more `Eq1`-style helper type classes, but some could not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 06:00:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 06:00:56 -0000 Subject: [GHC] #11271: Costly let binding gets duplicated in IO action value Message-ID: <050.e8ad7ff9004503147bb3eb1eeb608b8c@haskell.org> #11271: Costly let binding gets duplicated in IO action value -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- The following code is much slower when optimized. {{{#!hs module Main where import Control.Monad import Data.Char import System.IO -- getInt: read a integer from stdin, skipping spaces {-# NOINLINE getInt #-} -- to simplify generated core getInt :: IO Int getInt = skipSpaces >> go 0 where skipSpaces = do next <- hLookAhead stdin if isSpace next then getChar >> skipSpaces else return () go n = do next <- hLookAhead stdin if isNumber next then getChar >> go (10 * n + digitToInt next) else return n {-# NOINLINE generateSlowList #-} generateSlowList :: Int -> [Int] generateSlowList 0 = [1] generateSlowList n = scanl (+) 1 (generateSlowList (n-1)) main = do n <- getInt let ls = generateSlowList n --- !!! replicateM_ n $ do i <- getInt print (ls !! i) }}} How to run: {{{ (echo 10000; yes 5000) | time ./slow > /dev/null }}} After a rough look through the generated core, it seems that the `ls` was moved into the argument to `replicateM_`, which is a lambda taking a `State# RealWorld`. It means that a list is rebuilt every time it's indexed, even though a let binding could have caused sharing. By the way it seems that `-fno-state-hack`, which seems related, doesn't seem to help. Interesting to note that using a bang pattern (`let !ls = ...`) would make the problem go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 06:26:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 06:26:31 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.2c6d49786daad38a6942cf69572bb24c@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * owner: tvv => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 06:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 06:27:08 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.c5724e34a7abb276de5a426e5a656ee3@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvv): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 08:16:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 08:16:26 -0000 Subject: [GHC] #11271: Costly let binding gets duplicated in IO action value In-Reply-To: <050.e8ad7ff9004503147bb3eb1eeb608b8c@haskell.org> References: <050.e8ad7ff9004503147bb3eb1eeb608b8c@haskell.org> Message-ID: <065.de5b57c012f3b081de1094d85715fdd7@haskell.org> #11271: Costly let binding gets duplicated in IO action value -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 nomeata): With 7.8, this is reproducable, but there, `-fno-state-hack` _does_ amend the problem. I think the reason is that since 7.10, interface files leak information about one-shot lambdas. This is intentional, but it means that the effect of `-fstate-hack` is less local. In particular, in this case, we have this in the interface of `System.IO`: {{{ f6fca8f374be656f4987fa89a8843dac print :: Show a => a -> IO () {- Arity: 3, Strictness: , Unfolding: InlineRule (0, True, True) print1 `cast` (forall a. _R ->_R _R ->_R Sym (NTCo:IO[0] <()>_R)) -} 26b6b5cf5870ccc833912748cf8c9456 print1 :: Show a => a -> State# RealWorld -> (# State# RealWorld, () #) {- Arity: 3, Strictness: , Unfolding: InlineRule (3, True, False) (\ @ a $dShow :: Show a x :: a eta :: State# RealWorld[OneShot] -> hPutStr2 stdout (show @ a $dShow x) True eta) -} }}} where the real-world argument is marked as `OneShot`. Without digging deeper, I could imagine that this flag will make GHC believe that the whole argument to `replicateM_` is one shot and hence inline `ls` into it. The ideas in #9388 should amend this problem, but I was stalled there by performance regressions. But maybe we should just take the plunge, get rid of the state hack in its current form, get a more correct compiler, live with the performance regressions due to that and try to make up for it in other ways. Not sure though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 08:51:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 08:51:18 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.1121791ebc4661fe3b5206f68fc48eb3@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: msosn Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11098, | NamedWildcardsAsTyVars, | NamedWildcardExplicitForall Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * testcase: => T11098, NamedWildcardsAsTyVars, NamedWildcardExplicitForall * differential: => Phab:D1576 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 08:51:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 08:51:55 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.4a4aef7d487ee12f26d8868db66ddac2@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | UnusedTyVarWarnings, | UnusedTyVarWarningsNamedWCs Blocked By: | Blocking: Related Tickets: #11098 | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * testcase: => UnusedTyVarWarnings, UnusedTyVarWarningsNamedWCs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 09:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 09:02:20 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.cccae8c43c2f7e54a0e1b5614c8f1aad@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by ekmett): Up until now we've avoided adding instances that would require extensions of that sort to base as they aren't suitable for describing in a language report without extending the language, and we lack a suitable precedent. Ultimately, we _had_ to move the classes from `Data.Functor.Classes` when we moved the other `Data.Functor.*` data types or we'd have wound up with orphan instances things that were previously perfectly sound and that are already seeing use. In the original Data.Functor migration proposal the inclusion of Data.Functor.Classes was offered up as a reluctant way to avoid random bikeshedding and loss of functionality during the migration of data types that truly belong further up the hierarchy, where we can avoid duplication of them and permit nicer extensions. On the other hand, we don't exactly have to go fishing for 3 dozen new classes to describe every other class 'one argument up'. There are viable solutions for folks who don't care about Haskell 98 (so long as they also don't care about the `Functor` concerns brought up above.) E.g. in my `constraints` package, using `ConstraintKinds` and `PolyKinds`, I supply {{{#!hs data Dict p where Dict :: p => Dict p newtype p :- q = Sub (p => Dict q) class Lifting p t where lifting :: p a :- p (t a) }}} Then everything from `Lifting Eq`, `Lifting Monad`, to `Lifting Monoid` all "just work". However, while more universal they aren't as effective as the manual dictionary passing done here. Such a pattern rules out some nice usecases, while simultaneously requiring a ridiculous number of instances to be defined by all users and a fair bit of sophistication to use. Consequently, I'm very much not advocating for something like that more radical approach. As for `Semigroup (Compose f g a)` -- we have an `Applicative (Compose f g)` because there is a canonical construction for nesting them. However, the choice of `Semigroup` here is quite open. You can't reason usefully about the instance you propose except instance by instance and there are multiple viable candidates. Let's consider `Monoid`: Given the existence of both: {{{#!hs instance (Applicative f, Applicative g, Monoid a) => Monoid (Compose f g a) instance Applicative (f (g a)) => Monoid (Compose f g a) }}} and the lack of a compelling motivation to pick one over the other, while one forces us to incur a flexible context, and the other requires a needless unit in the applicative structure when weakened to give the `Semigroup` constraint, I'd say it is better to supply neither instance. We've been meaning towards supplying instances when they are unambiguous and non-controversial. I'd say that such an instance for `Semigroup (Compose f g a)` would pass neither test. For right now I see the migration of the `Data.Functor.Classes` from `transformers` to `base` as more of a necessary evil than as a pattern to emulate, and trying to hit a decent compromise point, and I'd rather see if they see any sort of meaningful adoption outside of the `transformers` class hierarchy before we go and double/triple down on this design immediately. That said, as `Monoid` (now being in `Prelude`) and `Semigroup` in a few releases become more ingrained in our culture the idea of a `Monoid1` and `Semigroup1` to extend the consistency of this module might take better hold, but deciding that we want to do so probably belongs in the context of a much broader discussion in the libraries@ mailing list, rather than a rapidfire amendment in the last days before a release. E.g. is `Monoid1` sufficiently distinguished from `Applicative` to be worth defining? After all, you can likely prove that you need full parametricity in the argument, which would enable you to define an `Applicative` structure instead, meaning it likely doesn't add any expressive power, which would morally place `Semigroup1` at the same level as semi-applicative / `Apply` in the class hierarchy -- with nearly equivalent parametricity requirements. I personally find such structures useful, but I don't think there is community will to support a finer- grained AMP at this time. '''tl;dr''' My answer to your two questions could best be summaried as 1.) Insofar as it prevents people from writing portable code if they want to and would break such code that already exists, then I think the answer is yes. 2.) Even if you don't buy my reasoning in (1), unilaterally adding such an instance would rule out a potentially much more interesting discussion that should be had on libraries@ that I at least personally think would be more valuable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 09:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 09:13:24 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.e82db8fabedb29017213c51874b8a72c@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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): Let's not think about implementation before we have a ''design''. I have not read the entire thread again, but I'm pretty convinced that * We can't have two different types, one for construction and one for pattern matching I think it'll just be too confusing to have two types. It's bad enough to have this provided/required stuff without, in addition, having a completely separate type for construction. Are you seriously proposing to have two signatures for each pattern synonym? (Optionally, I assume.) So: if you give a pattern signature, I think it has to work for both construction and pattern matching. If you need extra constraints for construction, define a smart constructor (that can happen today with regular data constructors). Let's not over-elaborate until we have more experience. There are plenty of [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms open tickets to tackle on the pattern-synonym front]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 09:24:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 09:24:06 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.03bfc5d0cb0e76458a55bb1b7e504cea@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: 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: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not a bug in your code. It just indicates that GHC is doing an unusual amount of work per line of (your original) code. That's interesting but probably not your fault. It ''can'' indicate that you (or a library you are using) are inlining too much code, perhaps (but not necessarily) unproductively so. Occasionally it can be an indication that you've tripped over a well-known bug in GHC that makes things inline forever (#11240, #8833, #3872, #5400, #5448, #5722, #7057, #7369, #9235). Reporting it is good, especially if we can reproduce it; it ''can'' also mean that GHC is working harder than it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 09:33:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 09:33:53 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.12e817b7e19820eac93f9a5c3e03c92e@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.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): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hang on. What is the ''design'' here? Specifically, what is the semantics of matching? To put it another way, suppose I have {{{ pattern P x <- x@(Right _) }}} What does it mean to match against ''that''? Well, to a first approximation, in a pattern, `P pat` means the same as ` with pat instead of x`. So {{{ f (P (Left y)) = e }}} means {{{ f ((Left y)@(Right _)) = e }}} And what does ''that'' mean? Perhaps we could expand the semantics of as-patterns to be `p1 @ p2`, meaning match against ''both'' `p1` ''and'' `p1`. An "and-pattern" if you like. Now everything would be well-specified. And I suppose you could say things like {{{ f ((\xs -> length xs < 10) -> True)@(y:_) = ... }}} which would match against a list of length shorter than 10, and then bind 'y' to the head of that list. But this is a bigger change, and not directly related to pattern synonyms. So far I'm unconvinced. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 09:44:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 09:44:14 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command In-Reply-To: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> References: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> Message-ID: <065.784db4a5d014d5f1d13d045fd651fa85@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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): Not necessarily "too much work to change". It might just need someone to look into it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:12:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:12:08 -0000 Subject: [GHC] #11258: Add Location to RdrName in FieldOcc In-Reply-To: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> References: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> Message-ID: <059.4daf7cb67d7b616f2086c90d7ffc82cd@haskell.org> #11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11019 | Differential Rev(s): Phab:D1670 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"d8ed20c8772bee5eb83719c804121374157cf9b6/ghc" d8ed20c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8ed20c8772bee5eb83719c804121374157cf9b6" Add Location to RdrName in FieldOcc Summary: Post #11019, there have been some new instances of RdrName that are not located, in particular ```#!hs data FieldOcc name = FieldOcc { rdrNameFieldOcc :: RdrName , selectorFieldOcc :: PostRn name name } data AmbiguousFieldOcc name = Unambiguous RdrName (PostRn name name) | Ambiguous RdrName (PostTc name name) deriving (Typeable) ``` Add locations to them Updates haddock submodule to match Test Plan: ./validate Reviewers: goldfire, hvr, bgamari, austin Reviewed By: hvr Subscribers: hvr, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1670 GHC Trac Issues: #11258 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:12:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:12:08 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.c9368bb879d94c7648e9f1a7a3c7c48a@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1512 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"d8ed20c8772bee5eb83719c804121374157cf9b6/ghc" d8ed20c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8ed20c8772bee5eb83719c804121374157cf9b6" Add Location to RdrName in FieldOcc Summary: Post #11019, there have been some new instances of RdrName that are not located, in particular ```#!hs data FieldOcc name = FieldOcc { rdrNameFieldOcc :: RdrName , selectorFieldOcc :: PostRn name name } data AmbiguousFieldOcc name = Unambiguous RdrName (PostRn name name) | Ambiguous RdrName (PostTc name name) deriving (Typeable) ``` Add locations to them Updates haddock submodule to match Test Plan: ./validate Reviewers: goldfire, hvr, bgamari, austin Reviewed By: hvr Subscribers: hvr, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1670 GHC Trac Issues: #11258 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:22:30 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised Message-ID: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:22:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:22:55 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.cca90758712f3a8e810d51a6395fbf69@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 NickSmallbone): * Attachment "A.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:23:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:23:01 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.4664e70bcfd767a64f96180d4a65bca9@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 NickSmallbone): * Attachment "B.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:23:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:23:17 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.3c169de459102b99118a2ab1002216b0@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 NickSmallbone): * Attachment "A.hcr" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:23:24 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.61d17c7b50a5721b96c0913d7363fde2@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 NickSmallbone): * Attachment "B.hcr" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:30:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:30:54 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.1333fa8d07d41a5cc4c62cb23ce8ddef@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by duairc): Thanks for the detailed answer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 10:53:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 10:53:01 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O In-Reply-To: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> References: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> Message-ID: <058.2d9699485b5e553bdd2400df57009768@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): But in GHCi, which does not optimise, UNPACK pragmas do nothing, so it seems sensible to ignore them. Are you saying that you want GHC to do all the checks that it would have done if it had been optimising, even though it will then ignore the results? I'm sure that would be do-able if that's what everyone wants, and someone was willing to do it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:41:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:41:25 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.51ea27fa42a5fe7ebf77be20e2bcbe2c@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit c5597bb6da612e0578290c3bccdac089d6519e19 {{{ Author: Ben Gamari Date: Thu Dec 3 14:59:18 2015 +0100 Revert "Create empty dump files when there was nothing to dump" This reverts commit 8cba907ad404ba4005558b5a8966390159938172 which broke `-ddump-to-file`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:59:31 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] In-Reply-To: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> References: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> Message-ID: <059.11be32ddec89f5404a9edf5b0fe0bd55@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: dolio Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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:D1572 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b225b234a6b11e42fef433dcd5d2a38bb4b466bf/ghc" b225b234/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b225b234a6b11e42fef433dcd5d2a38bb4b466bf" Modify IsString String instance (fixes #10814) The new instance resolves to `s ~ [Char]` as soon as we know that `s ~ [a]`, to avoid certain functions (like (++)) causing a situation where `a` is ambiguous and (currently) unable to be defaulted. Reviewers: #core_libraries_committee, hvr, austin, bgamari Reviewed By: hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1572 GHC Trac Issues: #10814 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:59:31 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.5185d66c764c6d59f71b83377a14f13b@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: msosn Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11098, | NamedWildcardsAsTyVars, | NamedWildcardExplicitForall Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb7796f13e701cce4e7d1d86f36c966aa17f1e9c/ghc" eb7796f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb7796f13e701cce4e7d1d86f36c966aa17f1e9c" Warn about unused type variables in type families The warnings are enabled with the flag -fwarn-unused-matches, the same one that enables warnings on the term level. Identifiers starting with an underscore are now always parsed as type variables. When the NamedWildCards extension is enabled, the renamer replaces those variables with named wildcards. An additional NameSet nwcs is added to LocalRdrEnv. It's used to keep names of the type variables that should be replaced with wildcards. While renaming HsForAllTy, when a name is explicitly bound it is removed from the nwcs NameSet. As a result, the renamer doesn't replace them in the quantifier body. (Trac #11098) Fixes #10982, #11098 Reviewers: alanz, bgamari, hvr, austin, jstolarek Reviewed By: jstolarek Subscribers: goldfire, mpickering, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D1576 GHC Trac Issues: #10982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:59:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:59:31 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.802cf06aa7e0c8a18bdbfb0bf0f96d7d@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | UnusedTyVarWarnings, | UnusedTyVarWarningsNamedWCs Blocked By: | Blocking: Related Tickets: #11098 | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb7796f13e701cce4e7d1d86f36c966aa17f1e9c/ghc" eb7796f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb7796f13e701cce4e7d1d86f36c966aa17f1e9c" Warn about unused type variables in type families The warnings are enabled with the flag -fwarn-unused-matches, the same one that enables warnings on the term level. Identifiers starting with an underscore are now always parsed as type variables. When the NamedWildCards extension is enabled, the renamer replaces those variables with named wildcards. An additional NameSet nwcs is added to LocalRdrEnv. It's used to keep names of the type variables that should be replaced with wildcards. While renaming HsForAllTy, when a name is explicitly bound it is removed from the nwcs NameSet. As a result, the renamer doesn't replace them in the quantifier body. (Trac #11098) Fixes #10982, #11098 Reviewers: alanz, bgamari, hvr, austin, jstolarek Reviewed By: jstolarek Subscribers: goldfire, mpickering, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D1576 GHC Trac Issues: #10982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:59:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:59:43 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.ab50f9725f4f3471055f9c1225627097@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.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:D1514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:10 tvv]: > How about to switch back to Phab:D1514 Diff 5330? It fixes the ticket's issue and does not introduce any side-effects like described. `pipeLoop` could be throwing exceptions, and dump files should be closed when that happens (there could be ghc api users recovering from the exception). Maybe someone else can have a look? It can't be //that// hard to fix this issue properly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 11:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 11:59:56 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.94f77abe84dfeb0302a1aa66b87f9e16@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | UnusedTyVarWarnings, | UnusedTyVarWarningsNamedWCs Blocked By: | Blocking: Related Tickets: #11098 | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:00:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:00:01 -0000 Subject: [GHC] #10814: Eliminate some ambiguity for IsString [a] In-Reply-To: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> References: <044.3cb71730365e3c9cf61989f2886ab212@haskell.org> Message-ID: <059.17af3fe37ce806fe5842aed8be11c630@haskell.org> #10814: Eliminate some ambiguity for IsString [a] -------------------------------------+------------------------------------- Reporter: dolio | Owner: dolio Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | 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): Phab:D1572 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:03:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:03:50 -0000 Subject: [GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers Message-ID: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently only `F1` through `F4` and `D1` and `D2` are assigned to registers in the PowerPC backend. Assign `F5` and `F6` and `D3` through `D6` to registers too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:05:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:05:50 -0000 Subject: [GHC] #11269: powerpc64le: Build fails in rts/Linker.c In-Reply-To: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> References: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> Message-ID: <062.df3dbe79aa88aba75bd6a9b86db75a32@haskell.org> #11269: powerpc64le: Build fails in rts/Linker.c -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1672 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:24:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:24:25 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.778f02fecd03943ac6e812ae21ac56bc@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: msosn Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11098, | NamedWildcardsAsTyVars, | NamedWildcardExplicitForall Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Changes (by msosn): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:39:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:39:39 -0000 Subject: [GHC] #11240: Simplifier ticks exhausted on Y combinator In-Reply-To: <047.e113184e41db9f201270a32e4e8055d2@haskell.org> References: <047.e113184e41db9f201270a32e4e8055d2@haskell.org> Message-ID: <062.b47242096ad88c82dc0d923fcc6fc6c4@haskell.org> #11240: Simplifier ticks exhausted on Y combinator -------------------------------------+------------------------------------- Reporter: sweirich | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #424 Comment: Replying to [comment:1 goldfire]: > Could this be related to the third bullet under [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html Sec 13.2.1] in the manual? Indeed. See also #8833, #3872, #5400, #5448, #5722, #7057, #7369, #9235 (copied from [wiki:Status/SLPJ-Tickets#Inlining]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:40:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:40:59 -0000 Subject: [GHC] #10372: panic! compiling Y combinator with optimizations In-Reply-To: <042.4bc4d3ef8e2b09a054daf4f8f20341b2@haskell.org> References: <042.4bc4d3ef8e2b09a054daf4f8f20341b2@haskell.org> Message-ID: <057.749f571a21574483d4d81fb854bb46a7@haskell.org> #10372: panic! compiling Y combinator with optimizations -------------------------------------+------------------------------------- Reporter: cdk | Owner: Type: bug | Status: closed Priority: lowest | Milestone: ? Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: panic, | simplifier Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #424 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #424 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:41:39 -0000 Subject: [GHC] #10865: Poly-kinded Const In-Reply-To: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> References: <048.9e286d630268edb801227c2f20a8ad8a@haskell.org> Message-ID: <063.9c0949d69954fb10ab9d1e3250c426bc@haskell.org> #10865: Poly-kinded Const -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: duplicate | Keywords: poly-kinded, | Const Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"edcf17bd2ae503c2dda43ded40dca0950edfd018/ghc" edcf17b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="edcf17bd2ae503c2dda43ded40dca0950edfd018" Move Const to own module in Data.Functor.Const and enable PolyKinds `Const` from `Control.Applicative` can trivially be made kind-polymorphic in its second argument. There has been a Trac issue about this for nearly a year now. It doesn't look like anybody objects to it, so I figured I might as well make a patch. Trac Issues: #10039, #10865, #11135 Differential Revision: https://phabricator.haskell.org/D1630 Reviewers: ekmett, hvr, bgamari Subscribers: RyanGlScott, thomie }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:41:39 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.95e4d6a77d0424356bd551d6057b5b2f@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"edcf17bd2ae503c2dda43ded40dca0950edfd018/ghc" edcf17b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="edcf17bd2ae503c2dda43ded40dca0950edfd018" Move Const to own module in Data.Functor.Const and enable PolyKinds `Const` from `Control.Applicative` can trivially be made kind-polymorphic in its second argument. There has been a Trac issue about this for nearly a year now. It doesn't look like anybody objects to it, so I figured I might as well make a patch. Trac Issues: #10039, #10865, #11135 Differential Revision: https://phabricator.haskell.org/D1630 Reviewers: ekmett, hvr, bgamari Subscribers: RyanGlScott, thomie }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:41:39 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.3fe59a204a65044330c0c163f5759c2b@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1630 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"edcf17bd2ae503c2dda43ded40dca0950edfd018/ghc" edcf17b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="edcf17bd2ae503c2dda43ded40dca0950edfd018" Move Const to own module in Data.Functor.Const and enable PolyKinds `Const` from `Control.Applicative` can trivially be made kind-polymorphic in its second argument. There has been a Trac issue about this for nearly a year now. It doesn't look like anybody objects to it, so I figured I might as well make a patch. Trac Issues: #10039, #10865, #11135 Differential Revision: https://phabricator.haskell.org/D1630 Reviewers: ekmett, hvr, bgamari Subscribers: RyanGlScott, thomie }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:41:39 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) In-Reply-To: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> References: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> Message-ID: <057.32bbabd52c2e820100f0c25190d097ee@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dolio Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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:D1605 Wiki Page: | prime:Libraries/Proposals/ExpandFloating| -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6457903e7671b6096d2cca5d965f43daee3572a6/ghc" 6457903e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6457903e7671b6096d2cca5d965f43daee3572a6" Implement phase 1 of expanded Floating - This part of the proposal is to add log1p, expm1, log1pexp and log1mexp to the Floating class, and export the full Floating class from Numeric Reviewers: ekmett, #core_libraries_committee, bgamari, hvr, austin Reviewed By: ekmett, #core_libraries_committee, bgamari Subscribers: Phyx, RyanGlScott, ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1605 GHC Trac Issues: #11166 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:41:39 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.e979a607f045fa7656e52893b428934f@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9f23dd9d05eb0945fa7a60492d2f2721d364327b/ghc" 9f23dd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f23dd9d05eb0945fa7a60492d2f2721d364327b" testsuite: Add ClassOperator testcase This is derived from Haddock's `Operators` `html-test`, which appears to fail with GHC master yet compiles with 7.10.2 Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1667 GHC Trac Issues: #11264 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:48:01 -0000 Subject: [GHC] #11242: GHCi ignores -fno-warn-typed-holes In-Reply-To: <047.2da415eb99e1aeab3465b740d41302f2@haskell.org> References: <047.2da415eb99e1aeab3465b740d41302f2@haskell.org> Message-ID: <062.147770bcfb2554f72b8b622a67c3ab8e@haskell.org> #11242: GHCi ignores -fno-warn-typed-holes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: invalid | 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 thomie): * status: new => closed * resolution: => invalid Comment: You need `-fno-warn-partial-type-signatures`. The reason you did't see the waring in `ghc` was probably because you forgot to use `-fforce-recomp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:53:15 -0000 Subject: [GHC] #11265: Internal error, using pattern synonym as instance head In-Reply-To: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> References: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> Message-ID: <066.bf944f5208f0f3b6fe02ae3d05f54569@haskell.org> #11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: simonpj 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: goldfire => simonpj Comment: Actually it's not your fault. I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 12:58:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 12:58:09 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.d5a770cc8ec457379342dfcd537f8d4c@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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 see no difficulty in principle, and I don?t think this would be too hard in practice. That is, you can give a new name (via newtype) to an unlifted type like `Int#`, `Float#`, `Double#` etc. Consequences: * newtypes might have kind `#` (unlifted) * The `Coercible` class would have to work over unlifted types See [https://mail.haskell.org/pipermail/ghc-devs/2015-December/010840.html email thread] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 13:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 13:10:40 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.7c254d4333d60d800ea12b9852d95d23@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message is quite right. Here's an excerpt {{{ class C a b where (**>) :: a -> a -> () }}} The type of `(**>)` is ambiguous, because nothing fixes `b`. You could remove a parameter from the class, or add a functional dependency. Anyway the error message looks spot on. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 13:38:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 13:38:49 -0000 Subject: [GHC] #10592: Allow cycles in class declarations In-Reply-To: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> References: <050.6ec91d55766f7dba414220a7b67bdbfd@haskell.org> Message-ID: <065.ae00eedfbc4afd66a46f8a086ab9ef72@haskell.org> #10592: Allow cycles in class declarations -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): Well, you only want to add that constraint if it's actually true -- that is, if you intend that `Logic` is idempotent. But hurrah anyway. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 14:06:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 14:06:41 -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.2b4ec436bf0abd436d147f29b6d74faf@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): OK I understand. Here is a version of comment:4 that actually shows the problem {{{ {-# LANGUAGE ExistentialQuantification, ScopedTypeVariables #-} module T11186 where data Foop = forall xx . Foop xx blah (Foop (q :: pah)) = length ([q] :: _) }}} We get {{{ T11186.hs:8:41: error: ? Found type wildcard ?_? standing for ?[xx]? Where: ?xx? is a rigid type variable bound by a pattern with constructor: Foop :: forall xx. xx -> Foop, in an equation for ?blah? at T11186.hs:8:7 }}} Now, the difficulty is this: lexically scoped type variable might be bound somewhere very different to the existential pattern itself. For example: {{{ bla2 (Foop q) = (\(r::pah) -> length ([r] :: _)) q }}} And indeed, the same skolem bound in the pattern might have different lexical names in different places: {{{ bla2 (Foop q) = ( (\(r::pah) -> length ([r] :: _)) q , (\(r::hap) -> length ([r] :: _)) q ) }}} Now what would you expect? Ugh. Tiresome, and not particularly easy to fix. * Visible type application will let you bind the type variable in the pattern (which is where it "ought" to be bound * Maybe some hack could do a better job when the type variable is in fact bound in the pattern where the existential is born. Funnily enough, Richard, Stephanie, Adam, and I were discussing questions around lexically scoped type variables only last week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 14:07:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 14:07:01 -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.f9c4c5b673d304b558b84dc6ee78deca@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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire, sweirich, adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 15:17:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 15:17:36 -0000 Subject: [GHC] #11166: Implement phase1 of Expand Floating Proposal (EFP) In-Reply-To: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> References: <042.d5f6b4430656f0bd45e08001145fd98b@haskell.org> Message-ID: <057.45e2c0c4423d202fcd0d455b7424a1c4@haskell.org> #11166: Implement phase1 of Expand Floating Proposal (EFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: dolio Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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): Phab:D1605 Wiki Page: | prime:Libraries/Proposals/ExpandFloating| -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 15:17:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 15:17:45 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.58ab7ea8cd9fcaff9d5922a9d9ceffa7@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.4 Resolution: fixed | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1630 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 15:20:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 15:20:02 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.4aa9511178942793243484a010ff0ae3@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Ahh, of course. I should have looked more closely at the example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 15:42:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 15:42:09 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.7cbae69cdd756c8867be2412b2029d64@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Then the test should be deleted, or at least not marked expect_broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 16:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 16:21:51 -0000 Subject: [GHC] #11135: Migrate more of Data.Functor.* from transformers to base. In-Reply-To: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> References: <042.83233f22e5175dafd0dee94fc12c4d5f@haskell.org> Message-ID: <057.d76d871447a4f27cd8802d2e4121d748@haskell.org> #11135: Migrate more of Data.Functor.* from transformers to base. -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries/base | 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): Phab:D1543 Wiki Page: | Phab:D1544 Phab:D1630 -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 16:23:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 16:23:29 -0000 Subject: [GHC] #10901: failing build of ghc in openSUSE with ncurses-6.0 In-Reply-To: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> References: <046.56ed3ec6ea0e0e43d43cc81f7b3aebcf@haskell.org> Message-ID: <061.a1f66752f771ec84d8fd070ee00c21b4@haskell.org> #10901: failing build of ghc in openSUSE with ncurses-6.0 -------------------------------------+------------------------------------- Reporter: mimi.vx | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: upstream => closed * resolution: => fixed Comment: This is fixed as we updated `terminfo` and `haskeline`. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 16:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 16:44:23 -0000 Subject: [GHC] #11247: Weird error from running runghc on an invalid input filename In-Reply-To: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> References: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> Message-ID: <062.9c7832d6645bc103866c2e9fa920f2f1@haskell.org> #11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: runghc/T11247 Blocked By: | Blocking: Related Tickets: #7765 | Differential Rev(s): Phab:D1678 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => runghc/T11247 * differential: => Phab:D1678 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 16:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 16:54:50 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.04a9192b69eb1c02da923aee76a695aa@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:01:28 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.08290b26ca0b037a16b6f562cb7e8bab@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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: #4188 | Differential Rev(s): Phab:D1465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #4188 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:05:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:05:28 -0000 Subject: [GHC] #4188: Template Haskell support for reifying non-vanilla data constructors In-Reply-To: <048.6cba25a414a412de8c73bc8ff669d470@haskell.org> References: <048.6cba25a414a412de8c73bc8ff669d470@haskell.org> Message-ID: <063.bba98b38da6a0a633fb87325e396b274@haskell.org> #4188: Template Haskell support for reifying non-vanilla data constructors -------------------------------------+------------------------------------- Reporter: illissius | Owner: illissius Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T4188 Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #10828 Comment: Note that #10828 adds proper support for representing GADTs in Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:08:30 -0000 Subject: [GHC] #5217: GADT declaration not (yet) handled by Template Haskell In-Reply-To: <053.574b6ec5c0c64411ebdd17aeace43618@haskell.org> References: <053.574b6ec5c0c64411ebdd17aeace43618@haskell.org> Message-ID: <068.4644014548b3ace588f98df84dd2aebe@haskell.org> #5217: GADT declaration not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T5217 Blocked By: | Blocking: Related Tickets: #10828 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #10828 Comment: #10828 extends TH syntax to support GADTs without encoding them as normal data types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:25:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:25:22 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.37f92004870372bc1dc741fb43307f8f@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:28:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:28:36 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.e9a74f5f44b56c4f4b889d334606a014@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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: #4188, #5217 | Differential Rev(s): Phab:D1465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: #4188 => #4188, #5217 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:29:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:29:57 -0000 Subject: [GHC] #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 In-Reply-To: <047.efd17d599edaee400b6320c08d507412@haskell.org> References: <047.efd17d599edaee400b6320c08d507412@haskell.org> Message-ID: <062.b6e2a63d9bc39b1dbadf7b492b39205f@haskell.org> #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1680 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D1680 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:30:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:30:15 -0000 Subject: [GHC] #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 In-Reply-To: <047.efd17d599edaee400b6320c08d507412@haskell.org> References: <047.efd17d599edaee400b6320c08d507412@haskell.org> Message-ID: <062.c9695cd5dac5004362aee0e92273eb41@haskell.org> #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1680 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 17:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 17:40:28 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.ca3a80785c8146fdf2e4bd8142a49dad@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: Phab:D1138 => Phab:D1681 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:09:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:09:06 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.2275844f9bba5e4b25674a859a7b4c06@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | 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:1646 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ee6fba89b066fdf8408e6a18db343a4177e613f6/ghc" ee6fba89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee6fba89b066fdf8408e6a18db343a4177e613f6" Encode strictness in GHC generics metadata This augments `MetaSel` with a `Bang` field, which gives generic programmers access to the following information about each field selector: * `SourceUnpackedness`: whether a field was marked `{-# NOUNPACK #-}`, `{-# UNPACK #-}`, or not * `SourceStrictness`: whether a field was given a strictness (`!`) or laziness (`~`) annotation * `DecidedStrictness`: what strictness GHC infers for a field during compilation, which may be influenced by optimization levels, `-XStrictData`, `-funbox-strict-fields`, etc. Unlike in Phab:D1603, generics does not grant a programmer the ability to "splice" in metadata, so there is no issue including `DecidedStrictness` with `Bang` (whereas in Template Haskell, it had to be split off). One consequence of this is that `MetaNoSel` had to be removed, since it became redundant. The `NoSelector` empty data type was also removed for similar reasons. Fixes #10716. Test Plan: ./validate Reviewers: dreixel, goldfire, kosmikus, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1646 GHC Trac Issues: #10716 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:10:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:10:10 -0000 Subject: [GHC] #11274: Confused type checker with typed holes and a missing instance (also panic) Message-ID: <047.3aac9820202d22f04c45aac647f76c83@haskell.org> #11274: Confused type checker with typed holes and a missing instance (also panic) -------------------------------------+------------------------------------- Reporter: Xandaros | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- If your file contains a typed hole and a case where an instance is missing, the type checker will not find the missing instance and only report the hole. If -fdefer-typed-holes is set, this results in a panic. (Using ghci, the panic occurs when any definition of the module is being evaluated) Minimal working example: {{{#!hs {-# OPTIONS_GHC -fdefer-typed-holes #-} data Asd = Asd someHole = _asd missingInstance :: Asd -> Asd -> Bool missingInstance x y = x == y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:12:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:12:52 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O In-Reply-To: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> References: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> Message-ID: <058.134ae367121c7b6f85db918c34247bfe@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): > Are you saying that you want GHC to do all the checks that it would have done if it had been optimising, even though it will then ignore the results? Yes! In my opinion -Wall should check for all the warnings, no matter which optimization setting is used. Why? Because in my experience, this happens a lot: Programs are developed with -O0 or a similar parameter that reduces compilation times, to be able to iterate faster. Then programs would be compiled with -O before distribution (or before testing etc.). Currently what happens is you develop a program using -O0, but just when you think you're done and you can move to the testing you start getting warnings. This is very annoying IMO. We can improve the warning messages by maybe saying something like: "Unusable UNPACK ... Note that UNPACK pragmas are only effective with -O or higher". (the second part is only printed in -O0) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:14:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:14:09 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.9ea00c88751b188691e79476a6cee9e7@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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 osa1): * owner: => osa1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:16:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:16:33 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.2765f3fc19bbf1d9744fea62f4089535@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | 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): Phab:1646 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:44:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:44:57 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O In-Reply-To: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> References: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> Message-ID: <058.9907ddb4770f316b499898fd63107c19@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Don't make `-O0` slow please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:50:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:50:56 -0000 Subject: [GHC] #11047: Provide call stacks in GHCi In-Reply-To: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> References: <047.3eb9c7a7d6579e45d15f3dffd3ade555@haskell.org> Message-ID: <062.dd7ca11cf194451acbbe1d78371a3fc7@haskell.org> #11047: Provide call stacks in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #545, #4837, | Differential Rev(s): Phab:D1407 #11100 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"c8c44fd91b509b9eb644c826497ed5268e89363a/ghc" c8c44fd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8c44fd91b509b9eb644c826497ed5268e89363a" Maintain cost-centre stacks in the interpreter Summary: Breakpoints become SCCs, so we have detailed call-stack info for interpreted code. Currently this only works when GHC is compiled with -prof, but D1562 (Remote GHCi) removes this constraint so that in the future call stacks will be available without building your own GHCi. How can you get a stack trace? * programmatically: GHC.Stack.currentCallStack * I've added an experimental :where command that shows the stack when stopped at a breakpoint * `error` attaches a call stack automatically, although since calls to `error` are often lifted out to the top level, this is less useful than it might be (ImplicitParams still works though). * Later we might attach call stacks to all exceptions Other related changes in this diff: * I reduced the number of places that get ticks attached for breakpoints. In particular there was a breakpoint around the whole declaration, which was often redundant because it bound no variables. This reduces clutter in the stack traces and speeds up compilation. * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few other small cleanups Test Plan: validate Reviewers: ezyang, bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1595 GHC Trac Issues: #11047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 18:55:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 18:55:22 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O In-Reply-To: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> References: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> Message-ID: <058.477202494a90173bde4a8062827b56fc@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): There is a similar tension with `-fno-code` and incomplete pattern match warnings--or did that change with the new exhaustiveness checking in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:18:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:18:16 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.5de69cc4c3a85aabbc0f451a1be84750@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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): I'd like to give this a try, Richard, where should I start? I don't understand typechecking/ parts too well. As far as I can see, {{{kcTyClGroup}}} is kind checking type declarations, and {{{getInitialKind}}} is generating {{{liftedTypeKind}}} unless a kind signature is given (I don't understand how can kind signatures be used with newtypes, maybe that case is impossible?). Is it possible to do this by just generalizing the current code, instead of adding special cases for newtypes in {{{getInitialKind}}} or {{{kcTyClGroup}}} (or both) ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:22:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:22:25 -0000 Subject: [GHC] #8316: GHCi debugger segfaults when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.56fbba431e26c2fe0afa74ec90b9fb37@haskell.org> #8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a61e717fcff9108337b1d35783ea3afbf591d3c6/ghc" a61e717f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a61e717fcff9108337b1d35783ea3afbf591d3c6" testsuite: Add testcase for #8316 This is still broken but really out to be fixed. At least know we'll know if someone fixes it inadvertently. Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1682 GHC Trac Issues: #8316 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:22:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:22:25 -0000 Subject: [GHC] #11264: Previously compiling example does not compile In-Reply-To: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> References: <046.2fcef77e3e12bab19ecf472b2bed7f6b@haskell.org> Message-ID: <061.40b774ada8cf9efb1920b6bb5ca54b7a@haskell.org> #11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/ClassOperator Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fd1b5ae701bf3f0de5d2a56a7320b68d4f66b510/ghc" fd1b5ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd1b5ae701bf3f0de5d2a56a7320b68d4f66b510" testsuite/ClassOperator: This actually should_fail See #11264 for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:25:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:25:46 -0000 Subject: [GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O In-Reply-To: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> References: <043.247f2344b03eb8823968e7e25e03104e@haskell.org> Message-ID: <058.c10b0a5f13e79ab014c4f6402718d31d@haskell.org> #11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): @thomie, it shouldn't get any slower - all the information is already there. (unless we end up forcing a thunk that otherwise wouldn't be forced. Even in this case there shouldn't be any measurable difference, the code is not doing anything fancy) @rwbarton, good point. I just tried using HEAD: {{{ ? ghc-stage1 -fno-code -fforce-recomp -Wall --make Main.hs [1 of 1] Compiling Main ( Main.hs, nothing ) ? ghc-stage1 -fforce-recomp -Wall --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:6:1: warning: Pattern match(es) are non-exhaustive In an equation for ?showD?: Patterns not matched: C Linking Main ... }}} I think ideally this shouldn't happen, but we should probably discuss this further in the mailing list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:30:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:30:10 -0000 Subject: [GHC] #8316: GHCi debugger segfaults when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.8e8bea3192643c65c596bbdae4a0ab34@haskell.org> #8316: GHCi debugger segfaults when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:46:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:46:57 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.7831c408893225a50c01bf0f5da883e9@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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: #4188, #5217 | Differential Rev(s): Phab:D1465 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"eeecb8647585ad9eea0554b2f97a3645d2c59f88/ghc" eeecb86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eeecb8647585ad9eea0554b2f97a3645d2c59f88" Add proper GADTs support to Template Haskell Until now GADTs were supported in Template Haskell by encoding them using normal data types. This patch adds proper support for representing GADTs in TH. Test Plan: T10828 Reviewers: goldfire, austin, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1465 GHC Trac Issues: #10828 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 19:49:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 19:49:00 -0000 Subject: [GHC] #10828: TH could do a better job of representing GADTs In-Reply-To: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> References: <045.8ead8c05c9800a5f7ba9e24f2356aece@haskell.org> Message-ID: <060.db000513bc66bc80007302f67a90bc5d@haskell.org> #10828: TH could do a better job of representing GADTs -------------------------------------+------------------------------------- Reporter: spinda | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10828, | th/T10828a, th/T10828b Blocked By: | Blocking: Related Tickets: #4188, #5217 | Differential Rev(s): Phab:D1465 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * testcase: => th/T10828, th/T10828a, th/T10828b * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 20:12:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 20:12:05 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.a6b81b318152cb00d48483b6d9adfe22@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1683 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1683 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 20:20:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 20:20:53 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.376c5055670e28d93decf4575a09d08a@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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 this will be quite easy, actually. You're hunting in all the right places. `getInitialKind` does indeed assume a result of kind `*`. (A kind sig ''can'' be provided via `newtype Blah :: * -> * where ...` as if you're defining a GADT. That is, GADT syntax works with newtypes just fine.) But I don't think anyone gets hurt if you assume that the return kind is `TYPE v` for a fresh levity metavariable `v`. You may need to unify that result kind with `*` in the datatype case somewhere. You'd need to check that the result kind of the newtype matches the kind of the representation type. I think this would happen in `kcConDecl`. One annoying bit is that we have no surface syntax (other than `TYPE 'Unlifted`) for `#`. I suppose you could add `type UnliftedType = TYPE 'Unlifted` in `Data.Kind` if you felt it worthwhile. I really don't think it would be much harder than this. Go for it! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 21:44:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 21:44:10 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.96be86aa1d59dad4dd0f6f0d424e26d5@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ff3f918d1c9685857d3ba4bb0dc119616e89cbe6/ghc" ff3f918/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff3f918d1c9685857d3ba4bb0dc119616e89cbe6" Fix #11256 by not immediately erroring if we can't find a module. Test Plan: validate Reviewers: austin, bgamari, thomie Reviewed By: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D1669 GHC Trac Issues: #11256 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 21:44:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 21:44:10 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.3be418066098d862b8b3d435888e0014@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: g Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1626 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2dff6c184f97fa564c72c73374378a65e12984d8/ghc" 2dff6c18/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2dff6c184f97fa564c72c73374378a65e12984d8" Added missing instances for Identity and Const (#11210) The following instances are added instance Bounded a => Bounded (Const a b) instance Enum a => Enum (Const a b) instance Ix a => Ix (Const a b) instance Storable a => Storable (Const a b) instance Bounded a => Bounded (Identity a) instance Enum a => Enum (Identity a) instance Ix a => Ix (Identity a) instance Semigroup a => Semigroup (Identity a) instance Storable a => Storable (Identity a) Reviewers: ekmett, RyanGlScott, rwbarton, hvr, austin, bgamari Reviewed By: RyanGlScott, hvr Subscribers: rwbarton, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D1626 GHC Trac Issues: #11210 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:05:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:05:03 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.ff4a44ee25eb20bcb354b37cafc680f6@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: fixed | Keywords: g Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:05:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:05:19 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.f3af8c6273af1f4a5a84ab69afca6443@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: g => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:05:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:05:28 -0000 Subject: [GHC] #11210: Missing instances for Identity and Const In-Reply-To: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> References: <045.c3bc40f62ff2d0dad2378ca0ef921d4c@haskell.org> Message-ID: <060.7aadcf7b8bdf6ea13a2352e3925cce55@haskell.org> #11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.11 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:D1626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:07:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:07:13 -0000 Subject: [GHC] #11256: ghc --make reports bad import errors too eagerly In-Reply-To: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> References: <045.1d799acc547d2254ddab771e9c644bb5@haskell.org> Message-ID: <060.1ca28fabeab808316c6463e90066d011@haskell.org> #11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:27:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:27:13 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.9a8b30203f32d8fc32e1f5f87dc4d1d1@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 simonpj): That is terrible. I understand what is happening. * Since `overloaded` is recursive you must have an INLINEABLE pragma to have a chance of specialising it in an importing module * Sadly, when compiling A.hs with `{-# INLINEABLE overloaded #-}` I see a mutually recursive group of two functions: {{{ Rec { -- RHS size: {terms: 15, types: 14, coercions: 4} T11272a.$woverloaded [InlPrag=INLINABLE[0], Occ=LoopBreaker] :: forall a_arY. Ord a_arY => a_arY -> a_arY -> () -> (# (), () #) [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 0 0 20] 120 30 Tmpl= \ (@ a8_Xst) (w_X1Me :: Ord a8_Xst) (w1_X1Mg :: a8_Xst) (w2_X1Mi :: a8_Xst) (w3_s1LL [Occ=Once!] :: ()) -> case w3_s1LL of _ [Occ=Dead] { () -> case <= @ a8_Xst w_X1Me w1_X1Mg w2_X1Mi of _ [Occ=Dead] { False -> (# (), () #); True -> T11272a.$woverloaded @ a8_Xst w_X1Me w2_X1Mi w1_X1Mg () } }}] T11272a.$woverloaded = \ (@ a8_Xst) (w_X1Me :: Ord a8_Xst) (w1_X1Mg :: a8_Xst) (w2_X1Mi :: a8_Xst) (w3_s1LL :: () Unf=OtherCon []) -> case (a_r1OI @ a8_Xst w_X1Me w1_X1Mg w2_X1Mi w3_s1LL) `cast` (NTCo:Identity[0] <((), ())>_R :: Identity ((), ()) ~R# ((), ())) of _ [Occ=Dead] { (ww1_s1LX, ww2_s1LY) -> (# ww1_s1LX, ww2_s1LY #) } -- RHS size: {terms: 26, types: 17, coercions: 10} a_r1OI :: forall a_a1zi. Ord a_a1zi => a_a1zi -> a_a1zi -> () -> Identity ((), ()) [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType m] a_r1OI = \ (@ a8_a1zi) (w_s1LP :: Ord a8_a1zi) (w1_s1LQ :: a8_a1zi) (w2_s1LR :: a8_a1zi) (w3_s1LS :: ()) -> case w3_s1LS of _ [Occ=Dead] { () -> case <= @ a8_a1zi w_s1LP w1_s1LQ w2_s1LR of _ [Occ=Dead] { False -> lvl_r1OH `cast` (Sym (NTCo:Identity[0] <((), ())>_R) :: ((), ()) ~R# Identity ((), ())); True -> case T11272a.$woverloaded @ a8_a1zi w_s1LP w2_s1LR w1_s1LQ () of _ [Occ=Dead] { (# ww1_s1M1, ww2_s1M2 #) -> (ww1_s1M1, ww2_s1M2) `cast` (Sym (NTCo:Identity[0] <((), ())>_R) :: ((), ()) ~R# Identity ((), ())) } } } end Rec } }}} That's bad; we'd prefer a tight self-recursive function. * Worse, it doesn't specialise, because the cast makes it look as if it doesn't have top-level lambdas. Need to think about this, but thought I'd jot down what I know so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:51:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:51:14 -0000 Subject: [GHC] #11147: GHC 7.10.3 does not compile on NixOS In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.a4413c7dba8045dcb76403587835f528@haskell.org> #11147: GHC 7.10.3 does not compile on NixOS ----------------------------------------+------------------------------ Reporter: waern | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * status: infoneeded => closed * resolution: => wontfix Comment: A NixOS user has indicated that `master` works fine and the issue has been patch. Apparently the problem was due to an interaction with NixOS's GCC wrapper, {{{ well, there's a bug filed against 7.10.3 #11147 #11147: GHC 7.10.3 does not compile on NixOS - https://ghc.haskell.org/trac/ghc/ticket/11147 that was fixed well, it was patched ahh, the root cause was identified? bgamari: the response file support in SysTools apparently doesn't cooperate with the nix GCC wrapper }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 23:55:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 23:55:55 -0000 Subject: [GHC] #11147: GHC 7.10.3 does not compile on NixOS In-Reply-To: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> References: <044.85d2e27846676d6e2aaab356e8c6dc01@haskell.org> Message-ID: <059.c4428fe5d22250832dba4eca718b32e3@haskell.org> #11147: GHC 7.10.3 does not compile on NixOS ----------------------------------------+------------------------------ Reporter: waern | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by pikajude): For more info, see https://github.com/NixOS/nixpkgs/commit/a421e7bd4a28c69bded8b17888325e31554f61a1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 01:39:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 01:39:07 -0000 Subject: [GHC] #11275: :kind! doesn't reduce type families with poly-kinded return kinds Message-ID: <050.67015c84a74985052d80a10191d057d7@haskell.org> #11275: :kind! doesn't reduce type families with poly-kinded return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Originally discovered [https://mail.haskell.org/pipermail/ghc- devs/2015-December/010831.html here], here is a simplified example: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ?> :set -XPolyKinds -XTypeFamilies ?> type family Hm :: k where Hm = Int ?> :kind! Hm Hm :: k = Hm }}} Giving `Hm` a monomorphic return kind of `*` makes it work with `:kind!`: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help ?> :set -XTypeFamilies ?> type family Hm :: * where Hm = Int ?> :kind! Hm Hm :: * = Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 01:46:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 01:46:29 -0000 Subject: [GHC] #11275: :kind! doesn't reduce type families with poly-kinded return kinds In-Reply-To: <050.67015c84a74985052d80a10191d057d7@haskell.org> References: <050.67015c84a74985052d80a10191d057d7@haskell.org> Message-ID: <065.ff438a24ecdec6f4dd9c38484b19b6cd@haskell.org> #11275: :kind! doesn't reduce type families with poly-kinded return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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): Isn't this correct behavior? In the first case `Hm` could be at any kind, and it's not equal to `Int` for any kind other than `*`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 01:52:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 01:52:34 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program Message-ID: <049.2c7953798565542d8f2944995450a8e6@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 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 was discovered when trying to compile xml-conduit. Here is the standalone test case with a few comments indicating how to make it compile. The program compiles with ghc-7.10.2 but fails with HEAD. {{{#!hs {-# LANGUAGE RankNTypes #-} module Hang where import Control.Monad import Data.Char data Event = EventBeginDocument | EventEndDocument | EventBeginDoctype | EventEndDoctype | EventInstruction | EventBeginElement | EventEndElement | EventContent Content | EventComment | EventCDATA data Content = ContentText String | ContentEntity String peek :: Monad m => Consumer a m (Maybe a) peek = undefined type Consumer i m r = forall o. ConduitM i o m r tag :: forall m a b c o . Monad m => ConduitM Event o m (Maybe c) tag = do _ <- dropWS return undefined where -- Add this and it works -- dropWS :: Monad m => ConduitM Event o m (Maybe Event) dropWS = do -- Swap these two lines and it works -- let x = undefined x <- peek let isWS = case x of -- Remove some of these and it works Just EventBeginDocument -> True Just EventEndDocument -> True Just EventBeginDoctype{} -> True Just EventEndDoctype -> True Just EventInstruction{} -> True Just EventBeginElement{} -> False Just EventEndElement{} -> False Just (EventContent (ContentText t)) | all isSpace t -> True | otherwise -> False Just (EventContent ContentEntity{}) -> False Just EventComment{} -> True Just EventCDATA{} -> False Nothing -> False if isWS then dropWS else return x -- Inlined Instances instance Functor (ConduitM i o m) where fmap f (ConduitM c) = ConduitM $ \rest -> c (rest . f) instance Applicative (ConduitM i o m) where pure x = ConduitM ($ x) {-# INLINE pure #-} (<*>) = ap {-# INLINE (<*>) #-} instance Monad (ConduitM i o m) where return = pure ConduitM f >>= g = ConduitM $ \h -> f $ \a -> unConduitM (g a) h instance Monad m => Functor (Pipe l i o u m) where fmap = liftM {-# INLINE fmap #-} instance Monad m => Applicative (Pipe l i o u m) where pure = Done {-# INLINE pure #-} (<*>) = ap {-# INLINE (<*>) #-} instance Monad m => Monad (Pipe l i o u m) where return = pure {-# INLINE return #-} HaveOutput p c o >>= fp = HaveOutput (p >>= fp) c o NeedInput p c >>= fp = NeedInput (p >=> fp) (c >=> fp) Done x >>= fp = fp x PipeM mp >>= fp = PipeM ((>>= fp) `liftM` mp) Leftover p i >>= fp = Leftover (p >>= fp) i newtype ConduitM i o m r = ConduitM { unConduitM :: forall b. (r -> Pipe i i o () m b) -> Pipe i i o () m b } data Pipe l i o u m r = HaveOutput (Pipe l i o u m r) (m ()) o | NeedInput (i -> Pipe l i o u m r) (u -> Pipe l i o u m r) | Done r | PipeM (m (Pipe l i o u m r)) | Leftover (Pipe l i o u m r) l }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 01:57:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 01:57:29 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.929cf2ed58b3221b7b70ea38c8afddb5@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 02:04:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 02:04:12 -0000 Subject: [GHC] #11275: :kind! doesn't reduce type families with poly-kinded return kinds In-Reply-To: <050.67015c84a74985052d80a10191d057d7@haskell.org> References: <050.67015c84a74985052d80a10191d057d7@haskell.org> Message-ID: <065.01ff9794204262ddc841472e4222074f@haskell.org> #11275: :kind! doesn't reduce type families with poly-kinded return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: invalid | 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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: Oh, that is a very good point, and GHCi agrees with you: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 7.11.20151220: http://www.haskell.org/ghc/ :? for help ?> :set -XPolyKinds -XTypeFamilies ?> type family Hm :: k where Hm = Int ?> :kind! (Hm :: *) (Hm :: *) :: * = Int }}} I just didn't realize that `Hm = Int` forced the return kind to be `*`, which made `Hm` incomplete, since it doesn't have cases for return kinds other than `*`. I'd probably have been less likely to make this mistake if #10116 was fixed, but that's a separate issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 02:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 02:05:11 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.b702bad636ec05d22fcff55878ad96df@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 Dec 22 02:47:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 02:47:45 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.7f004fa4f1c236ec5e2b81493e749848@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 05:21:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 05:21:03 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.5d10bae27ea0da769c90620c33992b76@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1683 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"aa7fb9a64da740eb42e56e085adc445f0103e743/ghc" aa7fb9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa7fb9a64da740eb42e56e085adc445f0103e743" Fix GHCi segfault in Windows 32bit Summary: Add missing calling convention to function pointer, incorrect `cdecl` calling convention which should be `stdcall` on x86 was causing the stack to be corrupted. When it tried to return from the function the return pointer would be invalid. Test Plan: ./validate Reviewers: austin, erikd, bgamari, thomie Reviewed By: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D1683 GHC Trac Issues: #11234 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 05:26:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 05:26:11 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.578b68f0ee7e2e3fe873105df906fbc5@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1683 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed Comment: That should be it for the startup segfault. `prog003` seems to run on HEAD already. So that must have been fix by some other commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 07:57:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 07:57:55 -0000 Subject: [GHC] #10716: Metadata in GHC.Generic should give access to strictness annotation In-Reply-To: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> References: <049.954933c3fdc7ca9d74108b79b667adbd@haskell.org> Message-ID: <064.ba787c2b0b00a8d755fbd74de1f7899b@haskell.org> #10716: Metadata in GHC.Generic should give access to strictness annotation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | 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): Phab:1646 Wiki Page: | -------------------------------------+------------------------------------- Comment (by StefanWehr): This is great news! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 08:16:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 08:16:50 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.b928a35a9cabeebf953f82ae8ddfa025@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => gkaracha Comment: Eek. This is another example of the new pattern-match checker falling into exponential behaviour. Workaround: `-fno-warn-overlapping-patterns -fno-warn-incomplete-patterns` George: here is another for your list Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 08:24:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 08:24:54 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.8cfcb568a39a38701b6e04bdbcec268d@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1683 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Tamar, THANK YOU for sorting this out. Really helpful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 08:55:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 08:55:50 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.f7c96b1a6431814b4cd7cd164964f3b3@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [ticket:11276 mpickering]: > This was discovered when trying to compile xml-conduit. Here is the standalone test case with a few comments indicating how to make it compile. > > The program compiles with ghc-7.10.2 but fails with HEAD. > > {{{#!hs > -- Add this and it works > -- dropWS :: Monad m => ConduitM Event o m (Maybe Event) > }}} Thanks for the comments! If you just add the signature it really does compile? This is a bit strange, since the check runs post-typechecking so I would expect to have the same signature inferred at this point so I would not expect it to make a difference. I'll have to take a closer look, thanks :) George -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 09:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 09:44:41 -0000 Subject: [GHC] #8697: Type rationals In-Reply-To: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> References: <050.5a686d61530f3e6b07142cffaf979586@haskell.org> Message-ID: <065.c9491a77ee3830fa60708f353251ffba@haskell.org> #8697: Type rationals -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Comment (by adamgundry): I was prodded by [https://www.reddit.com/r/haskell/comments/3xoe58/24_days_of_hackage_2015_day_20_dimensional/cy7mdat?context=3 a reddit thread] into thinking about this issue. I agree with Carter that we should treat the syntactic and semantic aspects of this separately. Here's what I said about the syntactic side: Type-level integers/rationals shouldn't be too hard, at least to the level that type-level naturals are currently supported. I think the main thing lacking is a good design for how to write literals (since we don't have `fromInteger` or the `Num` class at the type level). It would be nice if we could have both `42 :: Integer` and `42 :: Nat` in types. One possibility might be to define some (return kind indexed) type families: {{{#!hs type family FromNat (k :: *) (n :: Nat) :: k type instance FromNat Nat n = n type instance FromNat Integer n = ... type instance FromNat Rational n = ... type family FromInteger (k :: *) (i :: Integer) :: k type instance FromInteger Integer i = i type instance FromInteger Rational i = ... type family FromRational (k :: *) (r :: Rational) :: k type instance FromRational Rational r = r }}} Then GHC could translate a numeric literal in a type expression into an application of the appropriate type family (where I'm using suffixes to indicate numeric literals of the underlying kinds): {{{#!hs 42 ~> FromNat k 42n -1 ~> FromInteger k -1i 2.5 ~> FromRational k 2.5r }}} Note that this would allow users to define their own instances of the type families to make use of overloaded numeric literals, for example: {{{#!hs data PNat = Zero | Suc PNat type instance FromNat PNat n = FromPNat n type family FromPNat n where FromPNat 0 = Zero FromPNat n = Suc (FromPNat (n-1)) }}} But perhaps moving the type language further away from the term language isn't such a good idea, considering the general direction of travel towards dependent types... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 09:53:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 09:53:14 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.d70cb51c72d6138a96375e8ac39926de@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): Replying to [comment:3 goldfire]: > I conjecture that getting this completely right for closed type families is a research project of its own, because closed type families allow for repeated variables. Hmmmm, I agree that it is a research project on its own but I have been working on it the past months. If we use the technique we use in the [PAPER] to make the clauses semi-linear (linear but interleaved with guards - every non- linear pattern matching can be transformed this way), the match becomes: {{{#!hs type family F (a :: Bool) (b :: Maybe Bool) :: Nat where F True (Just False) = 0 F False (Just True) = 1 F x (Just z (z ~ x)) = 2 F y Nothing = 3 }}} Hence, by applying the algorithm as is we get (I omit constraints Delta where we don't have any or where they are just variable bindings that do not refer to the same variable): {{{ U1 = { False x1, True Nothing, True (Just True) } U2 = { False Nothing, False (Just False) , True Nothing , True (Just True) } U3 = { False Nothing , False (Just False) |> {x ~ False, z ~ False, not (z ~ x)} -- inconsistent , True Nothing , True (Just True) |> {x ~ True, z ~ True, not (z ~ x)} } -- inconsistent -- and cleaned up U3 = { False Nothing, True Nothing } U4 = {} }}} So, my biggest concern is not the lack of linearity. I also seem to have found a way to treat explicit type applications in patterns. The issues that still bother me a bit are the following: 1. Kind polymorphism is non-parametric and we can also have non-linear kind patterns 2. Haskell is not lazy at the type level so I expect us to miss completeness which we can have at the term level due to laziness. 3. I have no clue yet how to take injectivity annotations into account. I have plenty of ideas for 1 and 2 (at least on paper they seem to work) but I expect the 3rd to be more challenging to address. I am not setting myself as the owner yet, unless I find a way to incorporate the above but I hope to do so in 2016. :) George P.S. And since closed type families are usually MUCH smaller than term level functions and also they do not allow arbitrary guards (yet at least) but only the ones the check will generate, I expect such a check to be performant, in contrast to term-level pattern match checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 10:17:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 10:17:08 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.8555e987cfc90fc747d98b86c0dd6fa6@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nomeata): This is me thinking out aloud about this feature. Ignore me if you want, but if you are curious, feel free to jump in. Widening the scope of this ticket a bit (or shifting it?): Wouldn?t it be nice if we not only link the single-entry thunks, but also find out about missed opportunities for single-entry thunks? Such a counting would subsume the linting above. I?m considering to build on [Debugging/TickyTicky ticky-ticky debugging], as it already provides a lot of the necessary infrastructure. In particular, it counts entries to thunks, when `-ticky-dyn-thunk` is enabled. The number is not quite what we want, though: It seems that if a certain static thunk is created ''n'' times, then it will report ''n'' entries; whereas in the scope of this ticket we want to know that each allocated thunk was entered once. Also, currently a dynamic (i.e. an instance of a static) thunk that is not marked as single-entry will always be reported to be entered 0 or 1 times, as the result is shared. How do we get better numbers here? One way might be a special heap object, let?s call it a ?counting indirection?. It behaves mostly like a regular indirection, i.e. it?s entry code would count a tick and then jump to the entry code of the indirectee, but the crucial difference would be that the garbage collector will 'not' erase it when it evacuates memory. It will, however, evacuate the indirectee as usual. This way, the sharing semantics are preserved, but every entry via the thunk will be counted, not just the first. These counting indirections would be created by the code that creates a thunk. This way, this counting can be done independent of `-ticky-dyn- thunk`. These heap objects can also carry additional data used in counting, e.g. the name of the thunk (in `CorePrep` names) and whether GHC created this thunk as single-entry or not (which would not affect the behaviour of the counting indirection, but be useful for the reporting). I?m not sure yet what?s the best data structure to do the counting, if we indeed want to count uses of each dynamic instance of the thunk (or rather, of the counting indirection) separately. Maybe statically allocate 'm' (maybe 1024) counters per thunk, and an index, and the first 'm' instances of the thunk use the these counter (each, upon first entry, incrementing the index to allocate its slot), and if there are more than 1024 entries, then simply stop counting. I kind-of like this design, but I?m sure I?m missing some rather ugly details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 10:46:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 10:46:59 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.1dd5572b1cfa9c546cc725b99d833647@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonpj): > It seems that if a certain static thunk is created ''n'' times, then it will report ''n'' entries; whereas in the scope of this ticket we want to know that each allocated thunk was entered once. Yes exactly. Let's call the code that allocates the thunk the '''thunk allocation site'''. For some of these sites, cardinality analysis may say "this is a single-entry thunk". Call those the ''single-entry thunk allocation sites''' and the others the '''multi-entry thunk allocation sites'''. * For each single-entry thunk allocation site, we'd like to know if any of the thunks it allocates are entered more than once. (This would mean that the analysis was unsound.) * For each multi-entry allocation site, we'd like to know if all the thunks it allocates are entered at most once. This is a possible missed opportunity to make it a single-entry site. (Only "possible" because in a different run it might be entered more than once.) * For all allocation sites we'd like to know if every thunk allocated there was never entered; that's a possible missed opportunity for absence. A counting indirection sounds like the right kind of thing. I would also like to count lambdas! So for the STG binding {{{ f = \xy. e }}} * How many times do I call f (ie enter the closure)? That is, is it a one-shot lambda. * Do I ever partially apply it, or is it always saturated? Similar technology might do the job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 11:46:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 11:46:03 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.5a519a1b8829b3b3fae7dcea116a4f9a@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 might fall out of the implementation anyways, but a special case to be aware of is non-exhaustiveness in implicit kind variables, such the return kind of a polykinded type family, as arose in #11275: {{{ type family Hm :: k where Hm = Int }}} Despite appearances this type family is not exhaustive: `Hm :: (* -> *)` will not reduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 12:21:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 12:21:38 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.184cbcaf23d5dea810c797091c9a939a@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | 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: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f975b0b10b2971d00b6e1986e0a2af2bf759a4f4/ghc" f975b0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f975b0b10b2971d00b6e1986e0a2af2bf759a4f4" Rework Template Haskell's handling of strictness Currently, Template Haskell's treatment of strictness is not enough to cover all possible combinations of unpackedness and strictness. In addition, it isn't equipped to deal with new features (such as `-XStrictData`) which can change a datatype's fields' strictness during compilation. To address this, I replaced TH's `Strict` datatype with `SourceUnpackedness` and `SourceStrictness` (which give the programmer a more complete toolkit to configure a datatype field's strictness than just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to reify a constructor fields' strictness post-compilation through the `reifyConStrictness` function. Fixes #10697. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1603 GHC Trac Issues: #10697 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:00:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:00:35 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.21ebb39c9f084f64fb53ee7f4b801f9c@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries | Version: (other) | Resolution: | Keywords: stm 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 Herbert Valerio Riedel ): In [changeset:"6eabd93d3cfaffab838830cf9a2618565ff04254/ghc" 6eabd93d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6eabd93d3cfaffab838830cf9a2618565ff04254" Update stm submodule to v2.4.4.1 release This `stm` release also addresses #10967 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:01:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:01:16 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.0c8936138b1cf9fcdd05bdb6c1c7051a@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: libraries | Version: (other) | Resolution: fixed | Keywords: stm 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 hvr): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:28:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:28:35 -0000 Subject: [GHC] #10697: Change template-haskell API to allow NOUNPACK, lazy annotations In-Reply-To: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> References: <050.a6bdd5be72187642ef8374a6f8b97464@haskell.org> Message-ID: <065.87920b52e30eb70e5457b74409f4ae1e@haskell.org> #10697: Change template-haskell API to allow NOUNPACK, lazy annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5290, #8347 | Differential Rev(s): Phab:D1603 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:33:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:33:49 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.89b936ab9d6ea401cbcc7db39c3bf787@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f40e122b7709c11d4ad20fd5cb26bf719235dbf1/ghc" f40e122/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f40e122b7709c11d4ad20fd5cb26bf719235dbf1" Fix typechecking for pattern synonym signatures Various tickets have revealed bad shortcomings in the typechecking of pattern type synonyms. Discussed a lot in (the latter part of) Trac #11224. This patch fixes the most complex issues: - Both parser and renamer now treat pattern synonyms as an ordinary LHsSigType. Nothing special. Hooray. - tcPatSynSig (now in TcPatSyn) typechecks the signature, and decomposes it into its pieces. See Note [Pattern synonym signatures] - tcCheckPatSyn has had a lot of refactoring. See Note [Checking against a pattern signature] The result is a lot tidier and more comprehensible. Plus, it actually works! NB: this patch doesn't actually address the precise target of #11224, namely "inlining pattern synonym does not preserve semantics". That's an unrelated bug, with a separate patch. ToDo: better documentation in the user manual Test Plan: Validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, mpickering, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1685 GHC Trac Issues: #11224 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:35:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:35:03 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.1b206db5f15d7966f653a1a76d6fbad2@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:35:22 -0000 Subject: [GHC] #11225: Unable to provide type signature for pattern synonym In-Reply-To: <049.425cd27fc02a0721cea74f731d7a6321@haskell.org> References: <049.425cd27fc02a0721cea74f731d7a6321@haskell.org> Message-ID: <064.0478c65dd95aaff46678821c08c6b9e5@haskell.org> #11225: Unable to provide type signature for pattern synonym -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: patsyn/T11224 Blocked By: | Blocking: Related Tickets: #11224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:35:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:35:40 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.3599b389aa2214623248067a45c27886@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): Replying to [comment:7 rwbarton]: > This might fall out of the implementation anyways, but a special case to be aware of is non-exhaustiveness in implicit kind variables, such the return kind of a polykinded type family, as arose in #11275: > {{{ > type family Hm :: k where Hm = Int > }}} > Despite appearances this type family is not exhaustive: `Hm :: (* -> *)` will not reduce. Yes, this makes a lot of sense, it really is non-exhaustive. If you think of the full type, I think that `Hm` would look like the following: {{{ type family Hm (k :: BOX) where Hm * = Int }}} Hence, we can compute the uncovered set to be: {{{ U1 = { k |> not (k ~ *) } }}} I think this is the only *clean* way to treat this, pretty close to what already happens with GADTs: Have both kind and type arguments explicit (kinds first) and represent the non-matched cases with kind inequalities. I suspect that proper kind inequalities (See [http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f /axioms-extended.pdf]) will be needed in order for the results of the check to be properly used by the type checker but I think that just for the warning it can be done in a simpler way. Can't be sure though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 13:59:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 13:59:10 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.b28b4afb8572a34cc435966719c87a9f@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | patsyn/should_run/T11224 Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_run/T11224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 14:00:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 14:00:38 -0000 Subject: [GHC] #11224: Program doesn't preserve semantics after pattern synonym inlining. In-Reply-To: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> References: <052.0e88dfcc1c4328e2f98c2a5296a41d5b@haskell.org> Message-ID: <067.59ed1dad1787a1bebb3a996eaa2b7c15@haskell.org> #11224: Program doesn't preserve semantics after pattern synonym inlining. -------------------------------------+------------------------------------- Reporter: anton.dubovik | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | patsyn/should_run/T11224 Blocked By: | Blocking: Related Tickets: #11225 | Differential Rev(s): Phab:D1632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This commit is the one that fixes the original (semantic) problem {{{ 29928f29d53cfc7aceb7e8ab81967f784cf06159 compiler/deSugar/Match.hs | 86 +++++++++++++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 32 deletions(-) diff --git a/compiler/deSugar/Match.hs b/compiler/deSugar/Match.hs index f551fa4..b5a50e7 100644 --- a/compiler/deSugar/Match.hs +++ b/compiler/deSugar/Match.hs @@ -196,15 +196,15 @@ match vars@(v:_) ty eqns -- Eqns *can* be empty match_group [] = panic "match_group" match_group eqns@((group,_) : _) = case group of - PgCon _ -> matchConFamily vars ty (subGroup [(c,e) | (PgCon c, e) <- eqns]) - PgSyn _ -> matchPatSyn vars ty (dropGroup eqns) - PgLit _ -> matchLiterals vars ty (subGroup [(l,e) | (PgLit l, e) <- eqns]) - PgAny -> matchVariables vars ty (dropGroup eqns) - PgN _ -> matchNPats vars ty (dropGroup eqns) - PgNpK _ -> matchNPlusKPats vars ty (dropGroup eqns) - PgBang -> matchBangs vars ty (dropGroup eqns) - PgCo _ -> matchCoercion vars ty (dropGroup eqns) - PgView _ _ -> matchView vars ty (dropGroup eqns) + PgCon {} -> matchConFamily vars ty (subGroup [(c,e) | (PgCon c, e) <- eqns]) + PgSyn {} -> matchPatSyn vars ty (dropGroup eqns) + PgLit {} -> matchLiterals vars ty (subGroup [(l,e) | (PgLit l, e) <- eqns]) + PgAny -> matchVariables vars ty (dropGroup eqns) + PgN {} -> matchNPats vars ty (dropGroup eqns) + PgNpK {} -> matchNPlusKPats vars ty (dropGroup eqns) + PgBang -> matchBangs vars ty (dropGroup eqns) + PgCo {} -> matchCoercion vars ty (dropGroup eqns) + PgView {} -> matchView vars ty (dropGroup eqns) PgOverloadedList -> matchOverloadedList vars ty (dropGroup eqns) -- FIXME: we should also warn about view patterns that should be @@ -789,7 +789,7 @@ data PatGroup = PgAny -- Immediate match: variables, wildcards, -- lazy patterns | PgCon DataCon -- Constructor patterns (incl list, tuple) - | PgSyn PatSyn + | PgSyn PatSyn [Type] -- See Note [Pattern synonym groups] | PgLit Literal -- Literal patterns | PgN Literal -- Overloaded literals | PgNpK Literal -- n+k patterns @@ -828,7 +828,28 @@ subGroup group -- pg_map :: Map a [EquationInfo] -- Equations seen so far in reverse order of appearance -{- +{- Note [Pattern synonym groups] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +If we see + f (P a) = e1 + f (P b) = e2 + ... +where P is a pattern synonym, can we put (P a -> e1) and (P b -> e2) in +the same group? We can if P is a constructor, but /not/ if P is a pattern synonym. +Consider (Trac #11224) + -- readMaybe :: Read a => String -> Maybe a + pattern PRead :: Read a => () => a -> String + pattern PRead a <- (readMaybe -> Just a) + + f (PRead (x::Int)) = e1 + f (PRead (y::Bool)) = e2 +This is all fine: we match the string by trying to read an Int; if that +fails we try to read a Bool. But clearly we can't combine the two into +a single match. + +Conclusion: we can combine when we invoke PRead /at the same type/. +Hence in PgSyn we record the instantiaing types, and use them in sameGroup. + Note [Take care with pattern order] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the subGroup function we must be very careful about pattern re- ordering, @@ -841,14 +862,15 @@ sameGroup :: PatGroup -> PatGroup -> Bool -- Same group means that a single case expression -- or test will suffice to match both, *and* the order -- of testing within the group is insignificant. -sameGroup PgAny PgAny = True -sameGroup PgBang PgBang = True -sameGroup (PgCon _) (PgCon _) = True -- One case expression -sameGroup (PgSyn p1) (PgSyn p2) = p1==p2 -sameGroup (PgLit _) (PgLit _) = True -- One case expression -sameGroup (PgN l1) (PgN l2) = l1==l2 -- Order is significant -sameGroup (PgNpK l1) (PgNpK l2) = l1==l2 -- See Note [Grouping overloaded literal patterns] -sameGroup (PgCo t1) (PgCo t2) = t1 `eqType` t2 +sameGroup PgAny PgAny = True +sameGroup PgBang PgBang = True +sameGroup (PgCon _) (PgCon _) = True -- One case expression +sameGroup (PgSyn p1 t1) (PgSyn p2 t2) = p1==p2 && eqTypes t1 t2 + -- eqTypes: See Note [Pattern synonym groups] +sameGroup (PgLit _) (PgLit _) = True -- One case expression +sameGroup (PgN l1) (PgN l2) = l1==l2 -- Order is significant +sameGroup (PgNpK l1) (PgNpK l2) = l1==l2 -- See Note [Grouping overloaded literal patterns] +sameGroup (PgCo t1) (PgCo t2) = t1 `eqType` t2 -- CoPats are in the same goup only if the type of the -- enclosed pattern is the same. The patterns outside the CoPat -- always have the same type, so this boils down to saying that @@ -956,19 +978,19 @@ viewLExprEq (e1,_) (e2,_) = lexp e1 e2 eq_list eq (x:xs) (y:ys) = eq x y && eq_list eq xs ys patGroup :: DynFlags -> Pat Id -> PatGroup -patGroup _ (WildPat {}) = PgAny -patGroup _ (BangPat {}) = PgBang -patGroup _ (ConPatOut { pat_con = con }) = case unLoc con of - RealDataCon dcon -> PgCon dcon - PatSynCon psyn -> PgSyn psyn -patGroup dflags (LitPat lit) = PgLit (hsLitKey dflags lit) -patGroup _ (NPat (L _ olit) mb_neg _) - = PgN (hsOverLitKey olit (isJust mb_neg)) -patGroup _ (NPlusKPat _ (L _ olit) _ _) = PgNpK (hsOverLitKey olit False) -patGroup _ (CoPat _ p _) = PgCo (hsPatType p) -- Type of innelexp pattern -patGroup _ (ViewPat expr p _) = PgView expr (hsPatType (unLoc p)) -patGroup _ (ListPat _ _ (Just _)) = PgOverloadedList -patGroup _ pat = pprPanic "patGroup" (ppr pat) +patGroup _ (ConPatOut { pat_con = L _ con + , pat_arg_tys = tys }) + | RealDataCon dcon <- con = PgCon dcon + | PatSynCon psyn <- con = PgSyn psyn tys +patGroup _ (WildPat {}) = PgAny +patGroup _ (BangPat {}) = PgBang +patGroup _ (NPat (L _ olit) mb_neg _) = PgN (hsOverLitKey olit (isJust mb_neg)) +patGroup _ (NPlusKPat _ (L _ olit) _ _) = PgNpK (hsOverLitKey olit False) +patGroup _ (CoPat _ p _) = PgCo (hsPatType p) -- Type of innelexp pattern +patGroup _ (ViewPat expr p _) = PgView expr (hsPatType (unLoc p)) +patGroup _ (ListPat _ _ (Just _)) = PgOverloadedList +patGroup dflags (LitPat lit) = PgLit (hsLitKey dflags lit) +patGroup _ pat = pprPanic "patGroup" (ppr pat) {- Note [Grouping overloaded literal patterns] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 14:40:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 14:40:33 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.70ad07d9ddf0572ab891a53ec83a9a1a@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8128 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #8128 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 17:27:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 17:27:26 -0000 Subject: [GHC] #11098: PartialTypeSignatures mishandles type variables that begin with an underscore In-Reply-To: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> References: <047.b5765eda4c6ccd25def49af6cea2bd07@haskell.org> Message-ID: <062.9298889a2d436ff94645df1966df30c6@haskell.org> #11098: PartialTypeSignatures mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: msosn Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11098, | NamedWildcardsAsTyVars, | NamedWildcardExplicitForall Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"575a98e4d245c1e60526ed6d6711d96cea08e9d2/ghc" 575a98e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="575a98e4d245c1e60526ed6d6711d96cea08e9d2" Refactor named wildcards (again) Michal's work on #10982, #11098, refactored the handling of named wildcards by making them more like ordinary type variables. This patch takes the same idea to its logical conclusion, resulting in a much tidier, tighter implementation. Read Note [The wildcard story for types] in HsTypes. Changes: * Named wildcards are ordinary type variables, throughout * HsType no longer has a data constructor for named wildcards (was NamedWildCard in HsWildCardInfo). Named wildcards are simply HsTyVars * Similarly named wildcards disappear from Template Haskell * I refactored RnTypes to avoid polluting LocalRdrEnv with something as narrow as named wildcards. Instead the named wildcard set is carried in RnTyKiEnv. There is a submodule update for Haddock. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 17:27:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 17:27:26 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families In-Reply-To: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> References: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> Message-ID: <063.30c35e8b0b107667d1da255d8a41b760@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: msosn Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | UnusedTyVarWarnings, | UnusedTyVarWarningsNamedWCs Blocked By: | Blocking: Related Tickets: #11098 | Differential Rev(s): Phab:D1576 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"575a98e4d245c1e60526ed6d6711d96cea08e9d2/ghc" 575a98e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="575a98e4d245c1e60526ed6d6711d96cea08e9d2" Refactor named wildcards (again) Michal's work on #10982, #11098, refactored the handling of named wildcards by making them more like ordinary type variables. This patch takes the same idea to its logical conclusion, resulting in a much tidier, tighter implementation. Read Note [The wildcard story for types] in HsTypes. Changes: * Named wildcards are ordinary type variables, throughout * HsType no longer has a data constructor for named wildcards (was NamedWildCard in HsWildCardInfo). Named wildcards are simply HsTyVars * Similarly named wildcards disappear from Template Haskell * I refactored RnTypes to avoid polluting LocalRdrEnv with something as narrow as named wildcards. Instead the named wildcard set is carried in RnTyKiEnv. There is a submodule update for Haddock. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 19:19:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 19:19:07 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build Message-ID: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unregisterised build currently fails with: {{{ "inplace/bin/ghc-stage1" -static -prof -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 c rts/PrimOps.cmm -o rts/dist/build/PrimOps.p_o /tmp/ghc12993_0/ghc_3.hc: In function ?clB_entry?: /tmp/ghc12993_0/ghc_3.hc:2983:24: error: error: ?CCS_MAIN? undeclared (first use in this function) *((P_)(_cly+8)) = (W_)&CCS_MAIN; ^ /tmp/ghc12993_0/ghc_3.hc:2983:24: error: note: each undeclared identifier is reported only once for each function it appears in /tmp/ghc12993_0/ghc_3.hc: In function ?stg_mkApUpd0zh?: /tmp/ghc12993_0/ghc_3.hc:3031:24: error: error: ?CCS_MAIN? undeclared (first use in this function) *((P_)(_clP+8)) = (W_)&CCS_MAIN; ^ /tmp/ghc12993_0/ghc_3.hc: In function ?stg_clearCCSzh?: /tmp/ghc12993_0/ghc_3.hc:3323:40: error: error: ?CCS_MAIN? undeclared (first use in this function) CCCS = (struct CostCentreStack_ *)(W_)&CCS_MAIN; }}} which is almost certainly a result of commit c8c44fd91b509b9eb6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 19:29:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 19:29:21 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.e6da59d7d97adcb7d2e76085d88946ed@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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:6 gkaracha]: > > So, my biggest concern is not the lack of linearity. Yes. Your argument above is convincing. > 1. Kind polymorphism is non-parametric and we can also have non-linear kind patterns I see how this can be troublesome. For example {{{ data Proxy (a :: k) = P type family F (a :: k) where F 'P = Bool }}} elaborates to {{{ type family F k (a :: k) where F (Proxy k a) ('P k a) = Bool }}} That last bit surely looks non-linear and incomplete, but it's actually OK because the type-system forces the `k`s and the `a`s to be the same. I actually think I have the solution to this, but it's a rather large change (actually originally motivated by other problems): invent a new type `TyPat` that stores type patterns (instance LHSs), something like this: {{{ data TyPat = TyVarPat TyVar | AppTyPat TyPat TyPat | TyConTyPat TyCon [TyPat] | DataConTyPat DataCon [TyPat] | LitTyPat TyLit | CoercionTyPat CoVar }}} This is quite like `Type`, but with a few notable changes: 1. Though you can't see it above, the `[TyPat]` argument to `DataConTyPat` includes only ''existentials'', not universals. It is the universal arguments that are redundant in the polykinded case, and so skipping the universals means that the problem George brings up here goes away. It also solves an unrelated problem about type family applications appearing in universals -- these are harmless but are currently rejected because there should be no type family applications in type patterns. 2. Casts are just missing, as they make no sense in patterns. 3. Coercions (which will be datacon arguments always) are just bare coercion variables, as structurally matching coercions is bogus. 4. There are no polytypes, as these never appear in patterns. These patterns would be used for type family LHSs and also class instance heads. I conjecture that the pure unifier (in the `Unify` module) could be written to take a `TyPat` and a `Type` instead of two `Type`s. Note that there isn't really a notion of a pattern's kind, due to the missing universals and casts. But I think that's OK. (Type variables in type patterns still have kinds, of course.) Anyway, sorry for this longish digression, but I do think it solves the problem here nicely and is a general improvement I wish to make. > > 2. Haskell is not lazy at the type level so I expect us to miss completeness which we can have at the term level due to laziness. Can you give an example? I don't understand. > > 3. I have no clue yet how to take injectivity annotations into account. Neither do I. But let's not let this stop us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 21:35:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 21:35:53 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.ddc471691d7ddbb64f5abc71846acea7@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.7 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): So I think this turned out to be more complicated than we first thought (as usual). Richard, could you tell me if I'm going in the right direction? Here's what I did so far: {{{#!diff --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -1490,7 +1490,7 @@ tcGadtSigType doc name ty@(HsIB { hsib_vars = vars }) tcHsTyVarBndrs gtvs $ \ _ -> do { ctxt <- tcHsContext cxt ; btys <- tcConArgs DataType hs_details - ; ty' <- tcHsLiftedType res_ty + ; ty' <- tcHsOpenType res_ty ; field_lbls <- lookupConstructorFields name ; let (arg_tys, stricts) = unzip btys bound_vars = allBoundVariabless ctxt `unionVarSet` }}} Second change: {{{#!diff --- a/compiler/typecheck/TcHsType.hs +++ b/compiler/typecheck/TcHsType.hs @@ -1862,8 +1862,7 @@ tcDataKindSig :: Kind -> TcM [TyVar] -- We use it also to make up argument type variables for for data instances. -- Never emits constraints. tcDataKindSig kind - = do { checkTc (isLiftedTypeKind res_kind) (badKindSig kind) - ; span <- getSrcSpanM + = do { span <- getSrcSpanM ; us <- newUniqueSupply ; rdr_env <- getLocalRdrEnv ; let uniqs = uniqsFromSupply us @@ -1880,11 +1879,6 @@ tcDataKindSig kind mk_tv loc uniq occ kind = mkTyVar (mkInternalName uniq occ loc) kind -badKindSig :: Kind -> SDoc -badKindSig kind - = hang (ptext (sLit "Kind signature on data type declaration has non-* return kind")) - 2 (ppr kind) - {- Note [Avoid name clashes for associated data types] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ }}} Those are all for accepting this program: {{{#!haskell {-# LANGUAGE MagicHash, KindSignatures, GADTs #-} module Main where import GHC.Types import GHC.Prim import GHC.Exts newtype Blah :: TYPE 'Unlifted where Blah :: Int# -> Blah main = return () }}} For now I'm not trying to infer unlifted types, I'm trying to make cases with explicit kind signatures working. With these changes, GHC is failing with this panic: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20151222 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcTyClsDecls.hs, line 1630 }}} This is because we have some code that assume result types of ... I think GADTs? ... are lifted. (I think newtypes defined this way are type checked using GADT type checker?) Am I doing this right? How should I proceed after this point? I feel like I shouldn't lift these restrictions and instead I need some special cases for newtypes. Am I right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 22 23:23:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Dec 2015 23:23:11 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.9e97515850f5cfc816d6688f601d0eea@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1661 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"1faf1fcaebb2871f8085b01d0c6d19eec11dc808/ghc" 1faf1fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1faf1fcaebb2871f8085b01d0c6d19eec11dc808" Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244 Summary: The basic idea is that we have a new set of "exposed modules" which are /only/ used for plugins, i.e. -fplugin Foo and --frontend Foo. You can interact with this namespace using the flags -plugin-package-id and -plugin-package. By default, this namespace contains all modules in the user namespace (as before), but you can toggle that using -hide-all-plugin-packages. There is one nasty hack: GhcMake respects -fplugin in GHC_OPTIONS to make local plugins work correctly. It also bails out of you have an import of a module which doesn't exist locally or in the package database. The upshot is that we need to be sure to check in the plugin modules too, so we don't give a spurious failure when a plugin is in the plugin namespace but not the main namespace. A better way to fix this would be to distinguish between plugin and normal dependencies in ModSummary. I cheated a little and tweaked a few existing plugins tests to exercise the new code paths. TODO: Documentation Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: bgamari, austin, simonpj, duncan Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1661 GHC Trac Issues: #11244 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 01:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 01:29:14 -0000 Subject: [GHC] #11244: Compiler plugins should not have visibility controlled by -package In-Reply-To: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> References: <045.32dce0cd2ada24944a317fbed809d9b8@haskell.org> Message-ID: <060.a56682d32a59fc1ccdba33f0b691eba3@haskell.org> #11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1661 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed Comment: Needs Cabal support though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 02:35:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 02:35:21 -0000 Subject: [GHC] #11278: Spurious potential superclass cycle with constraint synonyms Message-ID: <045.be2c65cf9b1dd69e38face52c6049d47@haskell.org> #11278: Spurious potential superclass cycle with constraint synonyms -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (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 superclass cycle detector isn't smart enough to deal with constraint synonyms: {{{ {-# LANGUAGE ConstraintKinds #-} module A where type K a = (Show a, Read a) class K a => C a where }}} On HEAD I get: {{{ A.hs:4:1: error: ? Potential superclass cycle for ?C? one of whose superclasses is ?GHC.Classes.(%,%)? one of whose superclass constraints is headed by a type variable: ?c1? Use UndecidableSuperClasses to accept this ? In the class declaration for ?C? }}} The error goes away if the constraint synonym only has one constraint in it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 07:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 07:45:55 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.2fb8c1aa96d386ca3fa4b3ca29af98d7@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.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): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"48e06346805ab882a54088e01e5224111182f5df/ghc" 48e0634/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48e06346805ab882a54088e01e5224111182f5df" Revert "Allow as-patterns in pattern synonym declarations." I'm reverting this until we agree a design. See comment:5 in Trac #9793. Incidentally the reference to Trac #9739 in the reverted patch is bogus; it shold have said #9793. This reverts commit 44640af7afa1a01ff2e2357f7c1436b4804866fc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 07:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 07:45:55 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.5a42c2e122fa266c32d2cdbc29f26268@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T9739 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"48e06346805ab882a54088e01e5224111182f5df/ghc" 48e0634/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48e06346805ab882a54088e01e5224111182f5df" Revert "Allow as-patterns in pattern synonym declarations." I'm reverting this until we agree a design. See comment:5 in Trac #9793. Incidentally the reference to Trac #9739 in the reverted patch is bogus; it shold have said #9793. This reverts commit 44640af7afa1a01ff2e2357f7c1436b4804866fc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 07:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 07:45:55 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.066127b62fd74ede3d2a4617a6df0ea0@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10426 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1665 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b55ad1b33a30996a2ec4f85382f9c1cdca42e30f/ghc" b55ad1b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b55ad1b33a30996a2ec4f85382f9c1cdca42e30f" Wibble to error message in Trac #10426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 07:45:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 07:45:55 -0000 Subject: [GHC] #11274: Confused type checker with typed holes and a missing instance (also panic) In-Reply-To: <047.3aac9820202d22f04c45aac647f76c83@haskell.org> References: <047.3aac9820202d22f04c45aac647f76c83@haskell.org> Message-ID: <062.d013076879e499ee0f4cbff3d1057d7c@haskell.org> #11274: Confused type checker with typed holes and a missing instance (also panic) -------------------------------------+------------------------------------- Reporter: Xandaros | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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:"ed213ead5e92aa3c2ae830a00f06684a1028d3ad/ghc" ed213ead/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed213ead5e92aa3c2ae830a00f06684a1028d3ad" Test Trac #11274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 08:02:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 08:02:43 -0000 Subject: [GHC] #11274: Confused type checker with typed holes and a missing instance (also panic) In-Reply-To: <047.3aac9820202d22f04c45aac647f76c83@haskell.org> References: <047.3aac9820202d22f04c45aac647f76c83@haskell.org> Message-ID: <062.7aad6573f428a4334723076d98c663a8@haskell.org> #11274: Confused type checker with typed holes and a missing instance (also panic) -------------------------------------+------------------------------------- Reporter: Xandaros | Owner: 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: Compile-time | Test Case: crash | typecheck/should_fail/T11274 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T11274 * status: new => closed * resolution: => fixed Comment: This works in HEAD (and hence 8.0), but I've added a regression test. We rightly get {{{ T11274.hs:10:25: error: ? No instance for (Eq Asd) arising from a use of ?==? ? In the expression: x == y In an equation for ?missingInstance?: missingInstance x y = x == y }}} I have not tested 7.10.3, but I assume you are right about it failing there. Honestly, even if we release 7.10.4 I doubt we'll fix this bug on that branch -- it's not a show-stopper, and it'd be fresh work to do so. So I'll close this as fixed. Thanks for reporting such a nice small case! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 08:04:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 08:04:57 -0000 Subject: [GHC] #11265: Internal error, using pattern synonym as instance head In-Reply-To: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> References: <051.a9e50adfdabc12fd5b6ce0138e39c6ea@haskell.org> Message-ID: <066.c003d2794167c77ffa1fdf7dd1a929e9@haskell.org> #11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: simonpj 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: | patsyn/should_fail/T11265 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_fail/T11265 * status: new => closed * resolution: => fixed Comment: Thanks for reporting this, with a nice small repro case. Fixed by {{{ commit c069be815aa0bce2eb2c9621a36f114badda2318 Author: Simon Peyton Jones Date: Mon Dec 21 14:18:32 2015 +0000 Add a pattern-syn form of PromotionErr The main change is to add PatSynPE to PromotionErr, so that when we get an ill-staged use of a pattern synonym we get a civilised error message. We were already doing this in half-baked form in tcValBinds, but this patch tidies up the impl (which previously used a hack rather than APromotionErr), and does it in tcTyClsInstDecls too. >--------------------------------------------------------------- c069be815aa0bce2eb2c9621a36f114badda2318 compiler/hsSyn/HsBinds.hs | 15 ---- compiler/typecheck/TcBinds.hs | 53 +++-------- compiler/typecheck/TcEnv.hs | 103 +++++++++++++++++++++- compiler/typecheck/TcHsType.hs | 1 + compiler/typecheck/TcRnDriver.hs | 80 ++++++----------- compiler/typecheck/TcRnTypes.hs | 5 ++ testsuite/tests/patsyn/should_fail/T11265.hs | 6 ++ testsuite/tests/patsyn/should_fail/T11265.stderr | 6 ++ testsuite/tests/patsyn/should_fail/T9161-1.stderr | 7 +- testsuite/tests/patsyn/should_fail/T9161-2.stderr | 3 +- testsuite/tests/patsyn/should_fail/all.T | 1 + 11 files changed, 163 insertions(+), 117 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 08:11:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 08:11:12 -0000 Subject: [GHC] #11279: Parsing of complex QuasiQuote expression fails Message-ID: <044.18170ed8601ee5587513bd64790e880c@haskell.org> #11279: Parsing of complex QuasiQuote expression fails -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | 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 file {{{#!hs {-# LANGUAGE QuasiQuotes #-} testComplex = assertBool "" ([$istr| ok #{Foo 4 "Great!" : [Foo 3 "Scott!"]} then |] == ("\n" ++ " ok\n" ++ "[Foo 4 \"Great!\",Foo 3 \"Scott!\"]\n" ++ " then\n")) }}} parses (with renamer errors) under 7.10.3, but fails with {{{#!hs /home/alanz/tmp/Foo.hs:5:1: error: parse error (possibly incorrect indentation or mismatched brackets) }}} using current master (721d56d596848f9c772d08ef8693dff8ab9417b6) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 08:37:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 08:37:48 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.f0063c63a773698de1cbf1798cfaf94e@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): Phab:D1691 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D1691 Comment: I tested again and now it seems that the code in original bug report as well as Simon's code in comment 1 are accepted. I added a regression test. Once it validates on Phab I think we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:03:31 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.287c127861fd4b330e610086cf729ac3@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): Phab:D1691 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific, thanks. Yes, pls add regression and close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:04:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:04:48 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.ce95e3a6cf01c52799efc85f36e33306@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7ed0da6cde909e662d09e1f39c3fccfa10f91a7f/ghc" 7ed0da6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7ed0da6cde909e662d09e1f39c3fccfa10f91a7f" Modify Nmax to maxN Trac #10728 Added test and changed -Nmax to -maxN, -n was taken Noticed strange -m behavoir and fixed -m from quietly ignoring being passed invalid opts, e.g. "-msasd" Reviewers: simonmar, hvr, austin, thomie, bgamari Reviewed By: hvr, thomie, bgamari Subscribers: bgamari, hvr, thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1677 GHC Trac Issues: #10728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:52:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:52:25 -0000 Subject: [GHC] #11137: configure is broken for the unix package In-Reply-To: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> References: <042.888db3b96dcad1b1fa54d5554235ba60@haskell.org> Message-ID: <057.c9d25a7d60a1261272d377ed2143d2f7@haskell.org> #11137: configure is broken for the unix package -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pgj): * status: upstream => closed * resolution: => fixed Comment: Thank you very much, the build has now been unbroken on FreeBSD, so I am closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:59:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:59:12 -0000 Subject: [GHC] #10362: Make tuple constraints into a class In-Reply-To: <046.37ffd03861c08e5d28fe4001f4a37725@haskell.org> References: <046.37ffd03861c08e5d28fe4001f4a37725@haskell.org> Message-ID: <061.0a60ed3462c5bc4d69d785507f56bae4@haskell.org> #10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: This has been done, some time ago! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 10:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 10:13:14 -0000 Subject: [GHC] #11278: Spurious potential superclass cycle with constraint synonyms In-Reply-To: <045.be2c65cf9b1dd69e38face52c6049d47@haskell.org> References: <045.be2c65cf9b1dd69e38face52c6049d47@haskell.org> Message-ID: <060.1cefb13667a0dfdf0306207c891ce6c2@haskell.org> #11278: Spurious potential superclass cycle with constraint synonyms -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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 Simon Peyton Jones ): In [changeset:"f13de71b4684ab7702de3ad01eb212d81f7c4a5d/ghc" f13de71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f13de71b4684ab7702de3ad01eb212d81f7c4a5d" Fix super-class cycle check Fixes Trac #11278 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 10:13:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 10:13:14 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.9a7ad29a377297df9c4d5e70bb1dfca6@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: patsyn/T10897 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"78248702b0b8189d73f08c89d86f5cb7a3c6ae8c/ghc" 78248702/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="78248702b0b8189d73f08c89d86f5cb7a3c6ae8c" Fix ASSERT in buildPatSyn, and T10897 test This closes Trac #10897 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 10:15:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 10:15:32 -0000 Subject: [GHC] #10897: Incorrect ASSERT for buildPatSyn In-Reply-To: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> References: <045.72f9540a916b61c61568cdbdec70fba4@haskell.org> Message-ID: <060.3b45f57261dd4eb1cf6224d2e415e289@haskell.org> #10897: Incorrect ASSERT for buildPatSyn -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: patsyn/T10897 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Works fine now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 10:16:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 10:16:03 -0000 Subject: [GHC] #11278: Spurious potential superclass cycle with constraint synonyms In-Reply-To: <045.be2c65cf9b1dd69e38face52c6049d47@haskell.org> References: <045.be2c65cf9b1dd69e38face52c6049d47@haskell.org> Message-ID: <060.f5896c63fdd8451e266c07c7ffed3d01@haskell.org> #11278: Spurious potential superclass cycle with constraint synonyms -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11278 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T11278 * resolution: => fixed Comment: Thank you; fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 10:30:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 10:30:28 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.93f67cbd857e2a82a3aa627fa2bd7f66@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: feature request | Status: new 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"380b25ea4754c2aea683538ffdb179f8946219a0/ghc" 380b25e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="380b25ea4754c2aea683538ffdb179f8946219a0" Allow CallStacks to be frozen This introduces "freezing," an operation which prevents further locations from being appended to a CallStack. Library authors may want to prevent CallStacks from exposing implementation details, as a matter of hygiene. For example, in ``` head [] = error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` including the call-site of `error` in `head` is not strictly necessary as the error message already specifies clearly where the error came from. So we add a function `freezeCallStack` that wraps an existing CallStack, preventing further call-sites from being pushed onto it. In other words, ``` pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack ``` Now we can define `head` to not produce a CallStack at all ``` head [] = let ?callStack = freezeCallStack emptyCallStack in error "head: empty list" ghci> head [] *** Exception: head: empty list CallStack (from implicit params): error, called at ... ``` --- 1. We add the `freezeCallStack` and `emptyCallStack` and update the definition of `CallStack` to support this functionality. 2. We add `errorWithoutStackTrace`, a variant of `error` that does not produce a stack trace, using this feature. I think this is a sensible wrapper function to provide in case users want it. 3. We replace uses of `error` in base with `errorWithoutStackTrace`. The rationale is that base does not export any functions that use CallStacks (except for `error` and `undefined`) so there's no way for the stack traces (from Implicit CallStacks) to include user-defined functions. They'll only contain the call to `error` itself. As base already has a good habit of providing useful error messages that name the triggering function, the stack trace really just adds noise to the error. (I don't have a strong opinion on whether we should include this third commit, but the change was very mechanical so I thought I'd include it anyway in case there's interest) 4. Updates tests in `array` and `stm` submodules Test Plan: ./validate, new test is T11049 Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1628 GHC Trac Issues: #11049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 11:25:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 11:25:09 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.a34bf067884000490c97d496802ba494@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I suspect the fix might indeed be to implement the equivalent of `reinitializeGlobals` for the `TcPluginM` and `GHC` monads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:09:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:09:16 -0000 Subject: [GHC] #11039: Panic with incorrect pattern synonym signature In-Reply-To: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> References: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> Message-ID: <064.929925c45a599d6be2844bf8bb7ab648@haskell.org> #11039: Panic with incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T11039 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d1e9f827c36f6f552a643c2e537abdf74d87c893/ghc" d1e9f82/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1e9f827c36f6f552a643c2e537abdf74d87c893" Update tests for Trac #11039 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:09:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:09:45 -0000 Subject: [GHC] #11039: Panic with incorrect pattern synonym signature In-Reply-To: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> References: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> Message-ID: <064.6efb60fc7aa2019b7674712153dcf390@haskell.org> #11039: Panic with incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T11039, T11039a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: patsyn/should_fail/T11039 => patsyn/should_fail/T11039, T11039a * resolution: => fixed Comment: Fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:11:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:11:35 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.1135607e84eaccd28e56f7612cab475a@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): Phab:D1691 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f141f416714acf9a88e89bcde49fe79d59395d00/ghc" f141f416/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f141f416714acf9a88e89bcde49fe79d59395d00" Test #10432 Summary: A regression test for #10432, which seems to already be fixed. Test Plan: ./validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1691 GHC Trac Issues: #10432 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:12:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:12:31 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.5e4814852fe06dc81560321c0a576ccd@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10432 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1691 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => typecheck/should_compile/T10432 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:17:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:17:31 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.7b255d5220b5a53540cbf321e0639315@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Well #11039 is fixed so I think I'll close this too. Everything else here looks right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 12:20:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 12:20:02 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym In-Reply-To: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> References: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> Message-ID: <062.8be75666b20d09d4f5a43d8f12ee774a@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | PatternSynonyms 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): OK Matthew, you're all set to look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 13:36:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 13:36:51 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.da4c719fcc118232862ec2fbc2aa0895@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf 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 adamgundry): * owner: => adamgundry * cc: agundry (removed) * cc: adamgundry (added) Comment: I'll try to take another look at this soon. (Sadly I didn't spot this ticket earlier, because I need to be CCd as `adamgundry` rather than `agundry`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 13:59:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 13:59:15 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.c564541adfd62374e4eabafdd8019f83@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bravit): This was fixed already in [https://phabricator.haskell.org/D867] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 14:17:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 14:17:14 -0000 Subject: [GHC] #11049: Allow CallStacks to be hidden or cut In-Reply-To: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> References: <046.99c74047c61a8c0886c2d3ab954b8b7d@haskell.org> Message-ID: <061.07ffa4a7b0c205c443fa4cf48a9632f7@haskell.org> #11049: Allow CallStacks to be hidden or cut -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | 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: #11035 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 15:42:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 15:42:25 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.56a9d9ac128cb42758d634a75163a20a@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9975 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: => #9975 Comment: It turns out that trying to make use of duplicate fields belonging to pattern synonyms triggers a `find_tycon` panic, similar to #9975. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 15:43:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 15:43:44 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.7bd71032ee4074a581bead617ea9ac26@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: watashi (added) Comment: Hi bravit, thanks for having a look. After a `:reload`, the interactive printer doesn't work anymore. Here is an example. {{{ $ cat Test.hs module SpecPrinter where import System.IO sprint a = putStrLn $ show a ++ "!" }}} {{{ $ ~/ghc-devel2/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151216 }}} {{{ $ ~/ghc-devel2/inplace/bin/ghc-stage2 --interactive -interactive- print=SpecPrinter.sprint Test GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling SpecPrinter ( Test.hs, interpreted ) Ok, modules loaded: SpecPrinter. *SpecPrinter> "hi" "hi"! *SpecPrinter> :reload Ok, modules loaded: SpecPrinter. *SpecPrinter> "hi" "hi" }}} Note that after the `:reload`, the exclamation mark (`!`) isn't printed anymore. Do you agree this is not working as expected? I'm seeing the same behaviour with ghc-7.10.3 as with HEAD. CC @watashi, as the author of D867. I also note that a test was missing from that Diff, so maybe it recently got broken again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 16:01:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 16:01:55 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.5dcf2d2e2c31b9c754c380788ecc48be@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bravit): Hi thomie, If interactive printing function is defined in external package then it is kept after reloading (thanks to D867, now in HEAD). If it is defined locally then it is no more effective after reloading, it's a new function in some way. I consider this behaviour as reasonable. Don't you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 17:28:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 17:28:11 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.5c0da029d9e8af06b38750f3448defb7@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_spliceE5_prof Blocked By: | Blocking: Related Tickets: #5554 | Differential Rev(s): Phab:D1692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => th/TH_spliceE5_prof * differential: => Phab:D1692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 18:10:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 18:10:22 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.a9ccfc87aa5f8d3c95883ea12c0a3dd3@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 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): Well, I had previously thought one could get away with not considering `Invariant`, but after thinking about it some more, having `Invariant` is crucial for this new feature to be compositional. We'd add two new data types: {{{#!hs infixr 4 :->:, :->-: newtype (f :->: r) p = ContraArrow1 { unContraArrow1 :: f p -> r } newtype (f :->-: g) p = InvArrow1 { unInvArrow1 :: f p -> g p } }}} And, if we [https://ghc.haskell.org/trac/ghc/ticket/7492 change] `Rec1 f` to `f :.: Par1`, then we can also define the following for symmetry: {{{#!hs infixr 4 :>-: type (r :>-: f) = ((->) r) :.: f }}} (I've adopted a pretty arbitrary naming scheme where hyphens (`-`) denote occurrences of the type parameter. Feel free to suggest other names.) Then we can generate instances for data types no matter which side of an arrow a type parameter might occur. Here is an example: {{{#!hs newtype Endo a = Endo (a -> a) deriving Generic1 instance Invariant Endo where invmap f g (Endo x) = Endo (f . x . g) ==> instance Generic1 Endo where type Rep1 Endo = D1 ... (C1 ... (S1 ... (Par1 :->-: Par1))) to1 (M1 (M1 (M1 c))) = Endo ((.) (invCompose unPar1 Par1) unInvArrow1 c) from1 (Endo c) = M1 (M1 (M1 ((.) InvArrow1 (invCompose Par1 unPar1) c))) invCompose :: (c -> d) -> (a -> b) -> (b -> c) -> a -> d invCompose = \f g h x -> f (h (g x)) }}} So far, so good. But if we define something like this: {{{#!hs newtype Endo2 a = Endo2 (Endo a) deriving Generic1 }}} Then things become awkward. GHC would attempt to generate an instance like this: {{{#!hs instance Generic1 Endo2 where type Rep1 Endo2 = D1 ... (C1 ... (S1 ... (Endo :.: Par1))) to1 (M1 (M1 (M1 c))) = Endo2 ((.) (fmap unPar1) unComp1 c) from1 (Endo2 c) = M1 (M1 (M1 ((.) Comp1 (fmap Par1) c))) }}} But this will never work, because it assumes `Endo` is a `Functor` instance, which can't happen. This is quite a problem: we can make one datatype a `Generic1` instance, but we can't make a simple `newtype` wrapper around it a `Generic1` instance! However, if we changed the way GHC generated code for the `:.:` case to assume that the outermost datatype is an `Invariant` instance, not a `Functor` instance, then it would work: {{{#!hs instance Generic1 Endo where type Rep1 Endo = D1 ... (C1 ... (S1 ... (Par1 :->-: Par1))) to1 (M1 (M1 (M1 c))) = Endo ((.) (invCompose unPar1 Par1) unInvArrow1 c) from1 (Endo c) = M1 (M1 (M1 ((.) InvArrow1 (invCompose Par1 unPar1) c))) }}} Of course, this would mean bringing in `Invariant` to `base`, and it makes an assumption that most datatypes you'd find in the wild are `Invariant` instances already. As I mentioned above, trying to make `Invariant` a superclass of `Functor` is a hard sell. Futhermore, I'm not sure if we'd really gain anything after all this breakage besides being able to derive `Functor` and `Invariant` instances generically. I'm not convinced the benefits outweigh the potential heartburn in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 18:21:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 18:21:06 -0000 Subject: [GHC] #11262: Test print022: wrong stdout on powerpc64 In-Reply-To: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> References: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> Message-ID: <062.90def8889444b61b75ea35eee9680edb@haskell.org> #11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: print022 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): The test passes on powerpc64le. Could this be a big endian issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 18:51:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 18:51:58 -0000 Subject: [GHC] #11280: getCurrentDirectory should raise better error string when cwd doesn't exist Message-ID: <045.4baa55fc0d14cd014b96f19ac9b41514@haskell.org> #11280: getCurrentDirectory should raise better error string when cwd doesn't exist -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: | Version: 7.11 libraries/directory | Keywords: easy | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Run this script in a directory which no longer exists: {{{ import System.Directory main = getCurrentDirectory >>= putStrLn }}} Currently the error looks like: {{{ ezyang at sabre:~/test$ ./test bash: ./test: No such file or directory }}} It would be nicer to give a better message in this case. Originally reported https://github.com/haskell/cabal/issues/2902 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 21:18:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 21:18:50 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.35afadaed2d188a89b68538eafd15f24@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: new 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"7cddcde52cf27c55223b1dbb995df623498d0f70/ghc" 7cddcde/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cddcde52cf27c55223b1dbb995df623498d0f70" Docs: -interactive-print should reside in registered package Since commit 03c4893e355948fe865bc52c744359c42e4b06d7, ic_int_print is retained from registered packages after `:reload`. Fixes #11159. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 21:20:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 21:20:31 -0000 Subject: [GHC] #11159: '-interactive-print myPrint' forgotten after :load or :reload In-Reply-To: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> References: <047.19d5e013133e4a4a3625570eba477ff1@haskell.org> Message-ID: <062.cdf1fcbb7c67a63626657d340f6d9839@haskell.org> #11159: '-interactive-print myPrint' forgotten after :load or :reload -------------------------------------+------------------------------------- Reporter: hukarere | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | 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: #5461 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * component: GHCi => Documentation * milestone: => 8.0.1 Comment: Ah, ok, I missed the "external package" part. Sounds reasonable. I updated the User's Guide to mention this. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 21:59:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 21:59: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.9f241ee75407295b6584d017e8131de4@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 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 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"32215996528779f71a636350a36c01a8b3ccb1bf/ghc" 32215996/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32215996528779f71a636350a36c01a8b3ccb1bf" Make testsuite work again with Py3 Python 3 support seems to have mildly bitrotten since #9184 was closed. Luckily, only some minor tweaks seem necessary. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 22:51:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 22:51:46 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.a0607499e2cdfc59d034123ae7e9bf3c@haskell.org> #10376: arm/linux linking failure -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------- Comment (by Ben Gamari ): In [changeset:"353e97a37da98ccd174429fad348efbf01ace96c/ghc" 353e97a3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="353e97a37da98ccd174429fad348efbf01ace96c" config.mk.in: Disable stripping by default on ARM The Cortex A8 hardware apparently has a bug which ld.gold will try to correct; however in order to do so it must have unstripped executables lest we see warnings of the form (see #10376, #10464), /usr/bin/ld.gold: warning: cannot scan executable section 1 of ... for Cortex-A8 erratum because it has no mapping symbols. Consequently we disabling stripping by default on this architecture. A bit more discussion about this issue can be found in this [Android issue](http://code.google.com/p/android/issues/detail?id=40794). Test Plan: Try validating on ARM Reviewers: erikd, austin, thomie Reviewed By: austin, thomie Differential Revision: https://phabricator.haskell.org/D1599 GHC Trac Issues: #10376, #10464 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 22:51:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 22:51:46 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.bd877dfff539c9add99ff79d8e275aa7@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+----------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10376 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Ben Gamari ): In [changeset:"353e97a37da98ccd174429fad348efbf01ace96c/ghc" 353e97a3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="353e97a37da98ccd174429fad348efbf01ace96c" config.mk.in: Disable stripping by default on ARM The Cortex A8 hardware apparently has a bug which ld.gold will try to correct; however in order to do so it must have unstripped executables lest we see warnings of the form (see #10376, #10464), /usr/bin/ld.gold: warning: cannot scan executable section 1 of ... for Cortex-A8 erratum because it has no mapping symbols. Consequently we disabling stripping by default on this architecture. A bit more discussion about this issue can be found in this [Android issue](http://code.google.com/p/android/issues/detail?id=40794). Test Plan: Try validating on ARM Reviewers: erikd, austin, thomie Reviewed By: austin, thomie Differential Revision: https://phabricator.haskell.org/D1599 GHC Trac Issues: #10376, #10464 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 00:27:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 00:27:37 -0000 Subject: [GHC] #11281: Way to run --make and -M simultaneously Message-ID: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> #11281: Way to run --make and -M simultaneously -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 some cases, users would like to build their projects `--make` and also print out dependency information `-M` (so that they can sanity check file lists, etc.) It shouldn't be too difficult to arrange for `--make` and `-M file` to mean, put the Makefile information in `file`. Cabal's request: https://github.com/haskell/cabal/issues/2982 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 00:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 00:27:56 -0000 Subject: [GHC] #11281: Way to run --make and -M simultaneously In-Reply-To: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> References: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> Message-ID: <060.e378d0ce5615a24ad47b8223f181f90a@haskell.org> #11281: Way to run --make and -M simultaneously -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: easy 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: => easy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 02:33:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 02:33:14 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.3dca74aa22f873f22528b2d984e81f41@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Phab:D1693 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bernalex): * status: new => patch * differential: => Phab:D1693 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 03:43:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 03:43:49 -0000 Subject: [GHC] #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family Message-ID: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 I say {{{ {-# LANGUAGE TypeFamilies, RankNTypes #-} module Bug where import GHC.Exts type family F a = r | r -> a type family G a :: Constraint meth :: (G a => F a) -> () meth = undefined }}} I get {{{ Bug.hs:10:9: error: ? Could not deduce: F a ~ F a0 from the context: G a0 bound by the type signature for: meth :: G a0 => F a0 at Bug.hs:10:9-26 NB: ?F? is a type function, and may not be injective The type variable ?a0? is ambiguous ? In the ambiguity check for ?meth? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: meth :: (G a => F a) -> () }}} The presence of `G a` is critical for exhibiting this bug. If I replace `G a` with `Show a` the problem disappears. This one was actually encountered in an attempt to do Useful Work, not just idle typecheckery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 04:16:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 04:16:15 -0000 Subject: [GHC] #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family In-Reply-To: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> References: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> Message-ID: <062.49386c62809df991dbde61ba8264f0cb@haskell.org> #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Actually, this has nothing to do with injective type families. If I change the code to {{{ meth :: (G a => a) -> () }}} I get an error. That error explains that `a` is untouchable, which makes some small degree of sense, given that `G a` might reduce to an equality constraint. But the original error message is quite unfortunate, because `F` is indeed injective! So this bug is really about the error message, not the rejection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 08:49:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 08:49:53 -0000 Subject: [GHC] #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family In-Reply-To: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> References: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> Message-ID: <062.0363324d079e1a485e8ec6a4fe70e956@haskell.org> #11282: Injectivity annotation fails in the presence of higher-rank use of constraint family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Yes, this is unfortunate. Here's a bit more detail. The ambiguity check does a subsumption check {{{ forall a. (G a => F a) -> () <= forall b. (G b => F b) -> () }}} So we skolemise `b` and instantiate `b` to `beta`: {{{ forall a. ( (G a => F a) -> () <= (G beta => F beta) -> () ) }}} Now we do co/contravariance (see `Note [Co/contra-variance of subsumption checking]` in TcUnify) to get {{{ forall a. (G beta => F beta) <= (G a -> F a) }}} Now we skolemise and instantiate again (in this case there are no foralls, but we still get an implication constraint: {{{ forall a. (forall. G beta => (F a ~ F beta)) }}} Now as you point out beta is untouchable, and we can't float out the equality because `G beta` might have equalities in it. Alas. I'm not sure what to do about this. But that's what's happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 10:55:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 10:55:45 -0000 Subject: [GHC] #11283: PatternSynonms and DisambiguateRecordFields causes panic Message-ID: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> #11283: PatternSynonms and DisambiguateRecordFields causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9975 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following module causes a panic in HEAD: {{{#!hs {-# LANGUAGE PatternSynonyms, DisambiguateRecordFields #-} data P a = MkP a pattern S{x} = MkP x e = S{x = 3} }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151223 for x86_64-unknown-linux): find_tycon S [S pattern synonym defined at PatSynBug.hs:3:1] }}} This is essentially the same bug as #9975; for some reason it became slightly harder to tickle. Fix incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:05:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:05:46 -0000 Subject: [GHC] #11205: Validation on ARM fails to due Corex-A8 erratum check In-Reply-To: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> References: <046.bbc26b019759bcef81638dbd5ab77451@haskell.org> Message-ID: <061.0a62bd6b6f23eda7d33a30e08469d6e7@haskell.org> #11205: Validation on ARM fails to due Corex-A8 erratum check ---------------------------------------+---------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1599 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was closed with Phab:D1599. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:21:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:21:48 -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.0706dacb13501f428f18747c5852ba58@haskell.org> #4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: VictorDenisov => Comment: Unassigning, because of lack of progress. Maybe somebody else wants to give this a shot? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:22:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:22:59 -0000 Subject: [GHC] #2258: ghc --cleanup In-Reply-To: <044.6a7e7db2214398b58538f207783c755e@haskell.org> References: <044.6a7e7db2214398b58538f207783c755e@haskell.org> Message-ID: <059.7988e8493bc0d92e35e907562c588a4e@haskell.org> #2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4114 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: VictorDenisov => Comment: Unassigning, because of lack of progress. Maybe somebody else wants to give this a shot? @bheklilr? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:23:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:23:09 -0000 Subject: [GHC] #11283: PatternSynonms and DisambiguateRecordFields causes panic In-Reply-To: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> References: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> Message-ID: <064.55a1ff27a4111d140655737fe42f8b31@haskell.org> #11283: PatternSynonms and DisambiguateRecordFields causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T11283 Blocked By: | Blocking: Related Tickets: #9975 | Differential Rev(s): Phab:D1695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * testcase: => patsyn/should_compile/T11283 * differential: => Phab:D1695 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:37:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:37:10 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.e75da620884b18d4dd6f0adf03ea693e@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9975, #11283 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: adamgundry => * related: #9975 => #9975, #11283 Comment: The panic was actually caused by the combination of pattern synonyms and `DisambiguateRecordFields` or `RecordWildCards`, without needing `DuplicateRecordFields`. See #11283. The more general question of the interaction of `DuplicateRecordFields` and record pattern synonyms looks like it will be rather intricate. At the moment, record pattern synonym constructors and fields are not distinguished by the `Avail` or `Parent` types, but constructors and fields will need to be handled differently. This will require significant refactoring. We need to track the pattern synonym to which a field belongs, so that we can disambiguate fields properly. This doesn't even require `DuplicateRecordFields`: merely using `DisambiguateRecordFields` fails when the constructor is a record pattern synonym. However, the pattern synonym isn't a "parent" for the field in the same way that a datatype is. And pattern synonyms have the added complexity of being able to be associated with arbitrary parent datatypes. In addition, once `DuplicateRecordFields` is involved we need to keep track of the `FieldLabelString` separately from the `Name` when representing fields (e.g. in `AvailTC` or `FldParent`). I'm not going to be able to address this in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:38:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:38:00 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.c7669bed4973c72ab660b798a1c33fdc@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: | RecordWildcards PatternSynonyms Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T9975a,b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): See also #11283, which is essentially the same bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 11:48:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 11:48:10 -0000 Subject: [GHC] #11281: Way to run --make and -M simultaneously In-Reply-To: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> References: <045.ee8644e0c62daea7cb7ef629e4c7ff68@haskell.org> Message-ID: <060.d141ccb92a92087f63ca5b090c6e9625@haskell.org> #11281: Way to run --make and -M simultaneously -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: easy 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): https://mail.haskell.org/pipermail/glasgow-haskell- users/2014-November/025452.html ("Discovery of source dependencies without --make") is relevant, although it culminated in a very different ticket: #9846 ("GHC --make should also look for .hi, not only for .hs"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:18:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:18:47 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example Message-ID: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 example, {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:33:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:33:03 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.ebf7e00e76e371e696fb18243862f090@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari): * failure: None/Unknown => Runtime performance bug Old description: > Consider the example, > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > }}} New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} `longestWord` here produces the simplified Core`, {{{#!hs Rec { Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } end Rec } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop traversing `dt_a4jP :: ByteArray#` until it finds whitespace. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:42:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:42:32 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.03ce428121d09f5c521413b8a17d192c@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Rec { > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > end Rec } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop traversing > `dt_a4jP :: ByteArray#` until it finds whitespace. However, GHC fails to > lambda-lift this closure, thereby turning it into an allocating > operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} `longestWord` here produces the simplified Core`, {{{#!hs Rec { Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } end Rec } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:45:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:45:16 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.04513ee1a22a16f8e7aad802114a82b6@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Rec { > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > end Rec } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 }}} `longestWord` here produces the simplified Core`, {{{#!hs Rec { Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } end Rec } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:47:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:47:03 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.85947147ee19faf8574897083be5772f@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Rec { > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > end Rec } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Rec { Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } end Rec } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:48:01 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.468e0e72ba1c758c5d4cb98f824e35fc@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Rec { > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > end Rec } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > UTF-8 characters in `dt_a4jP :: ByteArray#` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Rec { Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } end Rec } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:49:42 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.aad492c208b4d01858e4222f397c48f7@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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): For the full Core see https://gist.github.com/bgamari/3187fe64531b19fcf37f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:52:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:52:43 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.a130ed526ba9dec02607104301ba49b2@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Rec { > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > end Rec } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > Unicode characters in the array `dt_a4jP` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [T.Text] Ticket.$wgo = ... -- > $wgo1 xs n = foldl' max n xs Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 16:53:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 16:53:22 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.17a6f7f98041cbf1427574ebb9a00efd@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> > [T.Text] > Ticket.$wgo = ... > > -- > $wgo1 xs n = foldl' max n xs > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > Unicode characters in the array `dt_a4jP` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [T.Text] Ticket.$wgo = ... -- > $wgo1 xs n = foldl' max n xs Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 17:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 17:22:52 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.23c73f5932a4860ee2cdc2357e03d09c@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> > [T.Text] > Ticket.$wgo = ... > > -- > $wgo1 xs n = foldl' max n xs > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > Unicode characters in the array `dt_a4jP` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [T.Text] Ticket.$wgo = ... -- > $wgo1 xs n = foldl' (\a b -> max a $ T.length b) n xs Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it finds the end of the `Text`. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 18:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 18:52:28 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.2c93a354c01c4a2368e1c63528777452@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_spliceE5_prof Blocked By: | Blocking: Related Tickets: #5554 | Differential Rev(s): Phab:D1692 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"48db13d279d592ed3044cbaf3513854bcb0d3dce/ghc" 48db13d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48db13d279d592ed3044cbaf3513854bcb0d3dce" Don't drop last char of file if -osuf contains dot Given: * `file = "foo.a.b"` * `osuf = ".a.b"` -- Note the initial dot. * `new_osuf = "c"` Before (bad, the last character of the filename is dropped): `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"` After (good): `stripExtension osuf file <.> new_osuf` == "foo.c" This regression was introduced in commit c489af73 (#5554). That commit fixed a similar but different bug, and care has been taken to not reintroduce it (using the the newly introduced `System.Filepath.stripExtension`). Given: * `file = "foo.a.b"` * `osuf = "a.b"` * `new_osuf = "c"` Before c489af73 (bad, the full suffix should get replaced): `replaceExtension file new_osuf == "foo.a.c"` After c489af73 (good): `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"` After this commit (still good): `stripExtension osuf file <.> new_osuf == "foo.c"` Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1692 GHC Trac Issues: #9760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 18:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 18:52:28 -0000 Subject: [GHC] #5554: Strange interaction between "-osuf", profiling and TemplateHaskell In-Reply-To: <045.98793be8f0ae5a8b509829a16dbcdafa@haskell.org> References: <045.98793be8f0ae5a8b509829a16dbcdafa@haskell.org> Message-ID: <060.3dfbd4998fefeed1c557002f0c225bf9@haskell.org> #5554: Strange interaction between "-osuf", profiling and TemplateHaskell -------------------------------------+--------------------------------- Reporter: iustin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Template Haskell | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Thomas Miedema ): In [changeset:"48db13d279d592ed3044cbaf3513854bcb0d3dce/ghc" 48db13d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48db13d279d592ed3044cbaf3513854bcb0d3dce" Don't drop last char of file if -osuf contains dot Given: * `file = "foo.a.b"` * `osuf = ".a.b"` -- Note the initial dot. * `new_osuf = "c"` Before (bad, the last character of the filename is dropped): `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"` After (good): `stripExtension osuf file <.> new_osuf` == "foo.c" This regression was introduced in commit c489af73 (#5554). That commit fixed a similar but different bug, and care has been taken to not reintroduce it (using the the newly introduced `System.Filepath.stripExtension`). Given: * `file = "foo.a.b"` * `osuf = "a.b"` * `new_osuf = "c"` Before c489af73 (bad, the full suffix should get replaced): `replaceExtension file new_osuf == "foo.a.c"` After c489af73 (good): `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"` After this commit (still good): `stripExtension osuf file <.> new_osuf == "foo.c"` Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1692 GHC Trac Issues: #9760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:06:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:06:25 -0000 Subject: [GHC] #11285: Static linking is really slow sometimes Message-ID: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> #11285: Static linking is really slow sometimes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 testing on Cabal `Setup.hs`, which links against Cabal. On a beefy machine with many cores and lots of RAM, I see a x2 regression in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld (not gold): {{{ [ezyang at hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m1.273s user 0m0.990s sys 0m0.210s [ezyang at hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce- recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.270s user 0m2.727s sys 0m0.523s }}} On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10 (with not much change with 8.0) {{{ ezyang at sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp rm: cannot remove ?A?: No such file or directory [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m3.058s user 0m1.860s sys 0m1.164s ezyang at sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp [1 of 1] Compiling Main ( A.hs, A.o ) Linking A ... real 0m7.139s user 0m4.616s sys 0m2.488s }}} There must be something which is causing the linker to run slowly in one case, and quickly in the other. It would be really good to figure out what this is. Slow linking is NOT NICE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:08:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:08:08 -0000 Subject: [GHC] #11285: Static linking is really slow sometimes In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.85a66acb5007d4592086ccf5792290f7@haskell.org> #11285: Static linking is really slow sometimes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 ezyang): * priority: normal => high * failure: None/Unknown => Compile-time performance bug * version: 7.10.3 => 7.11 * component: Compiler => Compiler (Linking) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:37:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:37:06 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.b5e6cf610658f575d47782d67364af4f@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2db18b8135335da2da9918b722699df684097be9/ghc" 2db18b81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2db18b8135335da2da9918b722699df684097be9" Visible type application This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:37:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:37:06 -0000 Subject: [GHC] #10619: Order matters when type-checking In-Reply-To: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> References: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> Message-ID: <062.b932dfddaa4c503036b3a19108586bb2@haskell.org> #10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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): -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2db18b8135335da2da9918b722699df684097be9/ghc" 2db18b81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2db18b8135335da2da9918b722699df684097be9" Visible type application This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:37:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:37:06 -0000 Subject: [GHC] #10589: Core Lint error with LambdaCase In-Reply-To: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> References: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> Message-ID: <062.2ae84123c68a1780e90f3d9bfdc97faa@haskell.org> #10589: Core Lint error with LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2db18b8135335da2da9918b722699df684097be9/ghc" 2db18b81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2db18b8135335da2da9918b722699df684097be9" Visible type application This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 19:39:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 19:39:35 -0000 Subject: [GHC] #5296: Add explicit type applications In-Reply-To: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> References: <042.d7f5be0512efad8881e5f10e7830add1@haskell.org> Message-ID: <057.f249267559f122a009409220a5d31900@haskell.org> #5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/Vta{1,2} typecheck/should_fail/VtaFail * status: new => closed * resolution: => fixed Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 22:21:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 22:21:11 -0000 Subject: [GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot In-Reply-To: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> References: <042.a8450b48a35343a6f047a80fcb9a70ec@haskell.org> Message-ID: <057.aa9db3c551c6a6f9ffed29a12c818945@haskell.org> #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_spliceE5_prof Blocked By: | Blocking: Related Tickets: #5554 | Differential Rev(s): Phab:D1692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: The testcase from https://github.com/nh2/ghc-osuf-lost-character- regression now reports: {{{ Myfile.hs:5:5: fatal: cannot find object file ?./Other.dyn_o? while linking an interpreted expression make: *** [check] Error 1 }}} So I think this issue is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 22:45:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 22:45:38 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.1ecbfe14b3be40bb371f3df221369d5f@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> > [T.Text] > Ticket.$wgo = ... > > -- > $wgo1 xs n = foldl' (\a b -> max a $ T.length b) n xs > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > Unicode characters in the array `dt_a4jP` until it finds the end of the > `Text`. However, GHC fails to lambda-lift this closure, thereby turning > it into an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core`, {{{#!hs Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [T.Text] Ticket.$wgo = ... -- > $wgo1 xs n = foldl' (\a b -> max a $ T.length b) n xs Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- Why must you allocate? For the love of all that is good, why? -- -- This loop is just `T.length`, the first argument being the -- length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) -- bounds check of _ { False -> { ... -- in this body there are few cases analyses with -- recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it arrives at its end. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 22:47:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 22:47:09 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow (was: Static linking is really slow sometimes) In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.342907e06da0a2113e5c3fea4fdb9707@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 ezyang): * type: bug => feature request Old description: > I'm testing on Cabal `Setup.hs`, which links against Cabal. > > On a beefy machine with many cores and lots of RAM, I see a x2 regression > in linking time from GHC 7.10.2 to GHC 8.0 (a recent HEAD) using GNU ld > (not gold): > > {{{ > [ezyang at hs01 ezyang]$ rm A; time ghc --make A.hs -fforce-recomp > [1 of 1] Compiling Main ( A.hs, A.o ) > Linking A ... > > real 0m1.273s > user 0m0.990s > sys 0m0.210s > > [ezyang at hs01 ezyang]$ rm A; time ghc-8.0/usr/bin/ghc --make A.hs -fforce- > recomp > [1 of 1] Compiling Main ( A.hs, A.o ) > Linking A ... > > real 0m3.270s > user 0m2.727s > sys 0m0.523s > }}} > > On a puny eight year-old laptop, I see a x2 regression from 7.6 to 7.10 > (with not much change with 8.0) > > {{{ > ezyang at sabre:~$ rm A; time ghc --make -O0 A.hs -fforce-recomp > rm: cannot remove ?A?: No such file or directory > [1 of 1] Compiling Main ( A.hs, A.o ) > Linking A ... > > real 0m3.058s > user 0m1.860s > sys 0m1.164s > ezyang at sabre:~$ rm A; time ghc-7.10 --make -O0 A.hs -fforce-recomp > [1 of 1] Compiling Main ( A.hs, A.o ) > Linking A ... > > real 0m7.139s > user 0m4.616s > sys 0m2.488s > > }}} > > There must be something which is causing the linker to run slowly in one > case, and quickly in the other. It would be really good to figure out > what this is. Slow linking is NOT NICE. New description: Here's a comparison of a few builds of `Setup.hs` using GHC 7.10.3. In the first case, I am building using a version of GHC with split objects disabled on all libraries. In the second, split objects were enabled but Cabal was compiled without split objects. In the third, Cabal was built with split objects. {{{ [ezyang at hs01 ezyang]$ rm Setup; time ghc-7.10-nosplitobjs/inplace/bin/ghc- stage2 --make Setup.hs -O0 rm: cannot remove ?Setup?: No such file or directory [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... real 0m0.950s user 0m0.757s sys 0m0.163s [ezyang at hs01 ezyang]$ rm Setup; time ghc --make Setup.hs -O0 Linking Setup ... real 0m1.209s user 0m0.973s sys 0m0.177s [ezyang at hs01 ezyang]$ rm Setup; time ghc -no-user-package-db --make Setup.hs -O0 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) [Distribution.Simple changed] Linking Setup ... real 0m3.136s user 0m2.693s sys 0m0.407s }}} In my experience, Cabal is the MOST expensive library to compile with split objects (on my laptop, this is an x2 difference in link time); among base libraries, ld.gold visibly hitches when it has to link base. Slow link times make for unpleasant experience for users, especially since we don't compile executables as dynamic by default. To make matters worse, split object compiled boot libraries represent a mandatory tax for anyone using static linking, because it's *not possible* to swap out those static archives with non-split objects ones. Could we enhance GHC to support running the linker in a "fast mode", where we ask the linker to treat archives as atomic units and not try to optimize for binary size? We can keep the current slow mode for production executables that people want to ship. -- Comment: I've diagnosed that split objects is the problem. I've rewritten the description to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 23:47:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 23:47:33 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.59f6d6a384f72ef09748ce4ad8e6db76@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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): 8.0 has the `-ffunction-sections`-style replacement for `-split-objs`, right? Is that better or worse? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 24 23:50:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Dec 2015 23:50:29 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.a95263d6d09ba431d1e161018e44c298@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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): For what it's worth, this binding is caught by the `AnnRec` pattern of `SetLevels.lvlBinds` by the `not (profitableFloat ...)` guard. `dest_lvl = <1,4>` and `bind_lvl = <1,5>`. `-ffloat-all-lams` and `-ffloat-lam- args=10` here doesn't seem to make any difference on the produced Core; while the binding gets floated out as one would expect, later simplifier phases later push it back in. Even after float-out, however, we still have an inner binding, {{{#!hs poly_$wloop_length_s7fV :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# poly_$wloop_length_s7fV = \ (dt_a6OV :: GHC.Prim.ByteArray#) (a_a6OU :: GHC.Prim.Int#) (ww_s7bR :: GHC.Prim.Int#) (ww_s7bV :: GHC.Prim.Int#) -> (letrec { $wloop_length_s7fT :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s7fT = \ (ww_X7c8 :: GHC.Prim.Int#) (ww_X7cd :: GHC.Prim.Int#) -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww_X7cd a_a6OU) of wild1_a6P4 { False -> ... True -> ww_X7c8 }; } in $wloop_length_s7fT) ww_s7bR ww_s7bV }}} Which later gets inlined back into `$wgo`. Looking at this Core, I suppose it's plausible that there really are too many free variables in this function to beneficially lambda-lift. It would be nice to have a second opinion here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 01:31:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 01:31:57 -0000 Subject: [GHC] #11286: ghc-pkg library Message-ID: <045.22d17f72b66a09d12b43646557f43709@haskell.org> #11286: ghc-pkg library -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 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: -------------------------------------+------------------------------------- On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672 No such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the "correct" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there. It seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 04:16:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 04:16:18 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.360aeb84d51fe73c94c59450322a2474@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 ezyang): Ha! On a quick and dirty test, `-ffunction-sections` is FOUR times worse for compiling `Setup.hs` on `ld.bfd`. However, it is TWO times better with `ld.gold`. (But not using split objects with gold is still the fastest.) {{{ [ezyang at hs01 ezyang]$ rm Setup; time ghc-8.0-nosplitobjs/inplace/bin/ghc- stage2 -no-user-package-db --make Setup.hs -O0 -optl-fuse-ld=gold [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... real 0m1.429s user 0m1.250s sys 0m0.163s sys 0m0.583s [ezyang at hs01 ezyang]$ rm Setup; time ghc-8.0/usr/bin/ghc -no-user-package- db --make Setup.hs -O0 -optl-fuse-ld=gold Linking Setup ... real 0m2.537s user 0m2.310s sys 0m0.220s [ezyang at hs01 ezyang]$ rm Setup; time ghc-8.0-nosplitobjs/inplace/bin/ghc- stage2 -no-user-package-db --make Setup.hs -O0 Linking Setup ... real 0m11.349s user 0m10.823s sys 0m0.553s [ezyang at hs01 ezyang]$ rm Setup; time ghc-8.0/usr/bin/ghc -no-user-package- db --make Setup.hs -O0 [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking Setup ... real 0m3.380s user 0m2.867s sys 0m0.500s }}} I don't think we can generally assume people will be using gold, so switching this on by default probably is unacceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 04:20:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 04:20:22 -0000 Subject: [GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables) In-Reply-To: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> References: <045.ff128453c9ddce6d07b91486f573635a@haskell.org> Message-ID: <060.822f1945c61505296d4bb931bf66e9db@haskell.org> #8405: experiment with using function-sections for linking (for smaller libs and executables) -------------------------------------+------------------------------------- Reporter: carter | Owner: olsner Type: task | Status: closed Priority: normal | Milestone: 8.0.1 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): Phab:D1242 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Link-time performance observation here: #11285; when compiling `Setup.sh`, split sections makes ld.bfd run four times slower than split objects, but ld.gold two times faster than split objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 11:48:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 11:48:56 -0000 Subject: [GHC] #11248: Ambiguous Types with Constraint Synonyms In-Reply-To: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> References: <047.dacba0ae71bd345ecac6da9db40d9b3d@haskell.org> Message-ID: <062.b898a179964e9fef5d98b7f6d7b84bd4@haskell.org> #11248: Ambiguous Types with Constraint Synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11248 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 11:49:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 11:49:39 -0000 Subject: [GHC] #11249: Type Synonyms cause Ambiguous Types In-Reply-To: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> References: <047.36b82b4f97ab5774bcc1be05303bd58a@haskell.org> Message-ID: <062.8bbbffc5189af0c84328f8732600a550@haskell.org> #11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 13:21:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 13:21:39 -0000 Subject: [GHC] #11279: Parsing of complex QuasiQuote expression fails In-Reply-To: <044.18170ed8601ee5587513bd64790e880c@haskell.org> References: <044.18170ed8601ee5587513bd64790e880c@haskell.org> Message-ID: <059.5d199654b1955c47a0027371851f828d@haskell.org> #11279: Parsing of complex QuasiQuote expression fails -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | 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 Thomas Miedema ): In [changeset:"2032635b80d8fc34dc168e2c22f51f8a69d97a1c/ghc" 2032635/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2032635b80d8fc34dc168e2c22f51f8a69d97a1c" Testsuite: fix qq005 and qq006 (#11279) With 399a5b46591dfbee0499d6afa1bb80ad2fd52598, the old `[$foo| ... |]` syntax for quasi-quotes is no longer allowed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 13:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 13:26:14 -0000 Subject: [GHC] #11279: Parsing of complex QuasiQuote expression fails In-Reply-To: <044.18170ed8601ee5587513bd64790e880c@haskell.org> References: <044.18170ed8601ee5587513bd64790e880c@haskell.org> Message-ID: <059.847bcdd7de6d2843226d87608f05e148@haskell.org> #11279: Parsing of complex QuasiQuote expression fails -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | 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 thomie): * status: new => closed * resolution: => invalid Comment: This just fails because it uses the old quasi quotes syntax. Replace `[$istr` by `[istr|`, and it will work. This is mentioned here: [wiki:Migration/8.0#OldQuasiQuotesyntax]. See also commit 399a5b46591dfbee0499d6afa1bb80ad2fd52598: {{{ Author: Matthew Pickering Date: Fri Nov 27 16:16:39 2015 +0100 Remove deprecated quasiquoter syntax. In spirit, this reverts 9ba922ee06b048774d7a82964867ff768a78126e The syntax has been deprecated with a warning since 2010. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1530 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 13:30:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 13:30:41 -0000 Subject: [GHC] #11258: Add Location to RdrName in FieldOcc In-Reply-To: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> References: <044.bb2ec9683ea65cfee10ae8fc24e1d59c@haskell.org> Message-ID: <059.6c595f55cbede049be1aa7808f2d60ab@haskell.org> #11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11019 | Differential Rev(s): Phab:D1670 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: I guess this is done now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 14:05:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 14:05:03 -0000 Subject: [GHC] #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs Message-ID: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: th/T7681 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Validate on Travis (in the configuration that defines `GhcStage2HcOpts += -DDEBUG`) [https://s3.amazonaws.com/archive.travis- ci.org/jobs/98713762/log.txt reports] , since 2db18b8135335da2da9918b722699df684097be9: {{{ Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151224 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcMatches.hs, line 223 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7681(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 14:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 14:12:06 -0000 Subject: [GHC] #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs In-Reply-To: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> References: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> Message-ID: <060.59e86944c21ec19128ff7c34a4b3c0eb@haskell.org> #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T7681 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bc8cac12f54bf032eb8578f6b112403bee5cb2de/ghc" bc8cac1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc8cac12f54bf032eb8578f6b112403bee5cb2de" Testsuite: mark T7681 expect_broken (#11287) When compiler_debugged only. This makes the Travis build green again. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 25 21:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Dec 2015 21:17:02 -0000 Subject: [GHC] #9176: GHC not generating dyn_hi files In-Reply-To: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> References: <047.f2af3ca10220c8e34e059cd35cbd3ddd@haskell.org> Message-ID: <062.cf419e13e5d8f700949933226d5b09ec@haskell.org> #9176: GHC not generating dyn_hi files -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: dynamic Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, let's see if we can get this straight: 1. In principle, it would be better if we didn't have any `dyn_hi` files. We should only have an `hi` file which everyone uses for typechecking. Because `-dynamic` does not affect type-checking/core optimization (it only affects the backend), any `dyn_hi` file you generate SHOULD be the same as `hi`. I'm pretty sure there isn't anything that is affected by this, and if there IS something we should kill it. 2. In practice, if `-dynamic-too` does not work (as claimed on Windows), you have to run the compiler twice (once with `-dynamic` and once without) to actually get both dynamic and normal object files. Now, GHC is nondeterministic, so we're not guaranteed to get the same interface each time. That's trouble. Additionally, if you don't call GHC with exactly the same flags as the first time, you will end up with different interface files easily. The moral of the story is that you should not be allowed compile static objects, and THEN compile dynamic objects in a separate GHC invocation. Then the nondeterminism problem goes away and we can kill `dyn_hi` files with fire. It seems to me that `-dynamic-too`, even for platforms which "don't support it". I am not exactly sure how `-dynamic-too` is implemented, but in the worst case scenario it should be sufficient to just run the entire backend pipeline twice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 02:02:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 02:02:57 -0000 Subject: [GHC] #11234: GHCi on Windows segfaults In-Reply-To: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> References: <044.2b0b25978d9d93b79878aa1e42161b3d@haskell.org> Message-ID: <059.9455348dbb73c2816964d5677380f55d@haskell.org> #11234: GHCi on Windows segfaults -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1683 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Cheers :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 08:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 08:14:26 -0000 Subject: [GHC] #11288: Thread blocked indefinitely in a Mvar operation Message-ID: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> #11288: Thread blocked indefinitely in a Mvar operation --------------------------------+------------------------------------------ Reporter: ygor_2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Installing GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------------ During the stack upgrade process the following error occurred: A specified local key could not be updated from keyserver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 08:15:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 08:15:35 -0000 Subject: [GHC] #11288: Thread blocked indefinitely in a Mvar operation In-Reply-To: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> References: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> Message-ID: <060.af679a78d60e6df0c91bdd6663ad6175@haskell.org> #11288: Thread blocked indefinitely in a Mvar operation ------------------------------------------+------------------------------ Reporter: ygor_2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Changes (by ygor_2): * Attachment "Error.gif" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 08:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 08:18:37 -0000 Subject: [GHC] #11288: Thread blocked indefinitely in a Mvar operation In-Reply-To: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> References: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> Message-ID: <060.7504cad511464f7351b36b065fb68e46@haskell.org> #11288: Thread blocked indefinitely in a Mvar operation ------------------------------------------+------------------------------ Reporter: ygor_2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by ygor_2): The same error and in a typical stack setup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 10:09:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 10:09:39 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.ccf214cbb58b291e5d7562efc03c40a1@haskell.org> #11206: ARM is generally a disaster ---------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by bgamari): #11205 is now closed and the world is a much rosier place. As of 353e97a37da98ccd174429fad348efbf01ace96c, {{{ Unexpected results from: TEST="T2431 recomp011 dynCompileExpr joao-circular T5313 T8274 CmmSwitchTest ghci004 ghci006 T7478 Roles4 Roles3 T8958 Roles14 Roles13 Roles2 Roles1 parseTree T10313 annotations comments listcomps TH_Roles2 T10828 T10518 T10052 prog001 outofmem T5435_v_asm linker_unload T5435_v_gcc T8628 T9015 T9595 T10508_api T1094 2 T8639_api T8726 T9430 T10359 T9203 T7257 lazy-bs-alloc haddock.Cabal haddock.compiler haddock.base T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961" OVERALL SUMMARY for test run started at Thu Dec 24 04:59:15 2015 CET 1:40:31 spent to go through 4945 total tests, which gave rise to 15671 test cases, of which 10775 were skipped 72 had missing libraries 4657 expected passes 105 expected failures 1 caused framework failures 0 unexpected passes 40 unexpected failures 22 unexpected stat failures Unexpected failures: codeGen/should_compile T10518 [exit code non-0] (normal) codeGen/should_run CmmSwitchTest [bad stdout] (normal,g1) deSugar/should_compile T2431 [stderr mismatch] (normal) driver T5313 [bad exit code] (normal) driver/recomp011 recomp011 [bad stdout] (normal) ghc-api T10508_api [exit code non-0] (normal) ghc-api T10942 [exit code non-0] (normal) ghc-api T8628 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api T9015 [exit code non-0] (normal) ghc-api T9595 [exit code non-0] (normal) ghc-api/T10052 T10052 [bad exit code] (normal) ghc-api/T7478 T7478 [bad exit code] (normal) ghc-api/annotations T10313 [bad exit code] (normal) ghc-api/annotations annotations [bad exit code] (normal) ghc-api/annotations comments [bad exit code] (normal) ghc-api/annotations listcomps [bad exit code] (normal) ghc-api/annotations parseTree [bad exit code] (normal) ghc-api/dynCompileExpr dynCompileExpr [exit code non-0] (normal) ghci/prog001 prog001 [bad exit code] (ghci-ext) ghci/scripts ghci004 [bad exit code] (ghci-ext) ghci/scripts ghci006 [bad exit code] (ghci-ext) numeric/should_run T8726 [bad exit code] (normal) primops/should_run T9430 [bad exit code] (normal) programs/joao-circular joao-circular [exit code non-0] (normal) roles/should_compile Roles1 [stderr mismatch] (normal) roles/should_compile Roles13 [stderr mismatch] (normal) roles/should_compile Roles14 [stderr mismatch] (normal) roles/should_compile Roles2 [stderr mismatch] (normal) roles/should_compile Roles3 [stderr mismatch] (normal) roles/should_compile Roles4 [stderr mismatch] (normal) roles/should_compile T8958 [stderr mismatch] (normal) rts T5435_v_asm [bad exit code] (normal) rts T5435_v_gcc [bad exit code] (normal) rts linker_unload [bad exit code] (normal) rts outofmem [bad stdout] (normal) simplCore/should_compile T8274 [bad stdout] (normal) th T10828 [stderr mismatch] (normal) th TH_Roles2 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5837 [stat too good] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9233 [stat not good enough] (normal) perf/compiler T9872a [stat not good enough] (normal) perf/compiler T9872b [stat not good enough] (normal) perf/compiler T9872c [stat not good enough] (normal) perf/compiler T9872d [stat not good enough] (normal) perf/compiler T9961 [stat not good enough] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat not good enough] (normal) perf/should_run T10359 [stat too good] (normal) perf/should_run T7257 [stat too good] (normal) perf/should_run T9203 [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat not good enough] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 10:10:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 10:10:20 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.a445051a0ae87a630fce36b6de24a270@haskell.org> #11206: ARM is generally a disaster ---------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by bgamari): As of bc8cac12f54bf032eb8578f6b112403bee5cb2de, {{{ Unexpected results from: TEST="literals parsed landmines dynCompileExpr joao-circular T5313 T8274 CmmSwitchTest ghci004 ghci006 T7478 parseTree T10313 annotations comments listcomps outofmem T5435_v_asm linker_unload T5435_v_gcc T10518 T10052 prog001 recomp011 T8628 T10942 T9595 T10508_api T9015 T6145 T8639_api T8726 T9430 T10359 T9203 T725 7 lazy-bs-alloc haddock.Cabal haddock.compiler haddock.base T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961" OVERALL SUMMARY for test run started at Sat Dec 26 05:11:08 2015 CET 1:59:58 spent to go through 4951 total tests, which gave rise to 15693 test cases, of which 10791 were skipped 72 had missing libraries 4669 expected passes 105 expected failures 1 caused framework failures 0 unexpected passes 34 unexpected failures 22 unexpected stat failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 10:42:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 10:42:11 -0000 Subject: [GHC] #11289: T8628 fails on ARM Message-ID: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- The `ghc-api/T8628` testcase fails on ARM with a runtime linker abort, {{{ $ ./T8628 /mnt/work/arm/ghc/ghc-nightly/inplace/lib T8628: internal error: checkProddableBlock: invalid fixup in runtime linker: 0xb6238ce0 (GHC version 7.11.20151225 for arm_unknown_linux) 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 Sat Dec 26 10:42:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 10:42:34 -0000 Subject: [GHC] #11289: T8628 fails on ARM In-Reply-To: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> References: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> Message-ID: <061.680084c7b6998f95799312d53f0d0542@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => arm Comment: The backtrace looks like this, {{{ Program received signal SIGABRT, Aborted. __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do- syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory. (gdb) bt #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do- syscall.S:44 #1 0xb6db5ec6 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #2 0xb6db6bce in __GI_abort () at abort.c:89 #3 0x02de1c94 in rtsFatalInternalErrorFn (s=0x0, ap=...) at rts/RtsMessages.c:182 #4 0x02de1d90 in barf (s=0x31204c8 "checkProddableBlock: invalid fixup in runtime linker: %p") at rts/RtsMessages.c:46 #5 0x02de49c8 in checkProddableBlock (size=4, oc=, addr=0xb627fce0) at rts/Linker.c:2584 #6 do_Elf_Rel_relocations (shnum=, shdr=, ehdrC=, oc=0x0) at rts/Linker.c:5041 #7 ocResolve_ELF (oc=0x0) at rts/Linker.c:5617 #8 resolveObjs_ () at rts/Linker.c:2433 #9 resolveObjs () at rts/Linker.c:2475 #10 0x02628534 in ghcizm0_GHCiziObjLink_resolveObjs1_info$def () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 10:42:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 10:42:57 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.9148a40d0ce08aff56b76746e85909c8@haskell.org> #11206: ARM is generally a disaster -----------------------------------+------------------------------ Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289 | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------ Changes (by bgamari): * related: => #11205, #11289 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 12:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 12:10:04 -0000 Subject: [GHC] #7653: incorrect handling of StackOverflow exception in the event manager In-Reply-To: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> References: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> Message-ID: <057.157ed41a88baad94f57a3e49898644a6@haskell.org> #7653: incorrect handling of StackOverflow exception in the event manager -------------------------------------+------------------------------------- Reporter: nus | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit 2d5eccdf1cfb389074cc2e5b52ae40b535c3b235: {{{ Author: Ian Lynagh Date: Sat Jun 8 20:19:59 2013 +0100 IO manager: Edit the timeout queue directly, rather than using an edit list Fixes #7653. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 12:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 12:10:43 -0000 Subject: [GHC] #7653: incorrect handling of StackOverflow exception in the event manager In-Reply-To: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> References: <042.be95d33a48a39c0da3d08d74cdb29185@haskell.org> Message-ID: <057.f663707a5f66e9e680c0ceddf546249d@haskell.org> #7653: incorrect handling of StackOverflow exception in the event manager -------------------------------------+------------------------------------- Reporter: nus | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): commit bbf6c025cdccd1f64166f273f9899c7d60a4a222 {{{ Author: Ian Lynagh Date: Sat Jun 8 21:09:59 2013 +0100 Add a test for #7653 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 13:33:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 13:33:30 -0000 Subject: [GHC] #11282: Error warns about non-injectivity of injective type family (was: Injectivity annotation fails in the presence of higher-rank use of constraint family) In-Reply-To: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> References: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> Message-ID: <062.026dd8f0fa619804ed7802378565f3c3@haskell.org> #11282: Error warns about non-injectivity of injective type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: | -------------------------------------+------------------------------------- Old description: > When I say > > {{{ > {-# LANGUAGE TypeFamilies, RankNTypes #-} > > module Bug where > > import GHC.Exts > > type family F a = r | r -> a > type family G a :: Constraint > > meth :: (G a => F a) -> () > meth = undefined > }}} > > I get > > {{{ > Bug.hs:10:9: error: > ? Could not deduce: F a ~ F a0 > from the context: G a0 > bound by the type signature for: > meth :: G a0 => F a0 > at Bug.hs:10:9-26 > NB: ?F? is a type function, and may not be injective > The type variable ?a0? is ambiguous > ? In the ambiguity check for ?meth? > To defer the ambiguity check to use sites, enable > AllowAmbiguousTypes > In the type signature: > meth :: (G a => F a) -> () > }}} > > The presence of `G a` is critical for exhibiting this bug. If I replace > `G a` with `Show a` the problem disappears. > > This one was actually encountered in an attempt to do Useful Work, not > just idle typecheckery. New description: When I say {{{ {-# LANGUAGE TypeFamilies, RankNTypes #-} module Bug where import GHC.Exts type family F a = r | r -> a type family G a :: Constraint meth :: (G a => F a) -> () meth = undefined }}} I get {{{ Bug.hs:10:9: error: ? Could not deduce: F a ~ F a0 from the context: G a0 bound by the type signature for: meth :: G a0 => F a0 at Bug.hs:10:9-26 NB: ?F? is a type function, and may not be injective The type variable ?a0? is ambiguous ? In the ambiguity check for ?meth? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: meth :: (G a => F a) -> () }}} The presence of `G a` is critical for exhibiting this bug. If I replace `G a` with `Show a` the problem disappears. This one was actually encountered in an attempt to do Useful Work, not just idle typecheckery. EDIT: Actually, I understand why this program should be rejected (comment:1), but the error message is surely misleading and should be fixed. -- Comment (by goldfire): I had figured that out (in rather less detail) by looking at the case without the injective type family. But the original error message is still warning me about a type family that isn't injective! So I think this boils down to adding a bit more logic to !TcErrors to print out an error about untouchable variables here instead of non-injective type families. I've modified the title and description to make this more clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 13:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 13:52:10 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** Message-ID: <045.dcc3b755524fc239874d7187491be2de@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: deriving/should_compile/T6031 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ make test TEST=T6031 WAY=optasm TEST_HC=ghc-7.11.20151225 ... =====> T6031(optasm) 1 of 1 [0, 0, 0] cd ./deriving/should_compile && "/opt/ghc/head/bin/ghc-head" --make T6031 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno- ghci-history -O -fasm -v0 > T6031.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Common sub-expression *** : warning: [in body of lambda with binder x_aSX :: Empty] No alternatives for a case scrutinee not known to diverge for sure: lvl_sUb *** Offending Program *** lvl_sTZ :: [Char] [LclId, Str=DmdType] lvl_sTZ = unpackCString# "error"# lvl_sU0 :: [Char] [LclId, Str=DmdType] lvl_sU0 = unpackCString# "main"# lvl_sU1 :: [Char] [LclId, Str=DmdType] lvl_sU1 = unpackCString# "T6031"# lvl_sU2 :: [Char] [LclId, Str=DmdType] lvl_sU2 = unpackCString# "T6031.hs"# lvl_sU3 :: Int [LclId, Str=DmdType] lvl_sU3 = I# 7# lvl_sU4 :: Int [LclId, Str=DmdType] lvl_sU4 = I# 1# lvl_sU5 :: Int [LclId, Str=DmdType] lvl_sU5 = lvl_sU3 lvl_sU6 :: Int [LclId, Str=DmdType] lvl_sU6 = I# 29# lvl_sU7 :: SrcLoc [LclId, Str=DmdType] lvl_sU7 = SrcLoc lvl_sU0 lvl_sU1 lvl_sU2 lvl_sU3 lvl_sU4 lvl_sU3 lvl_sU6 lvl_sU8 :: ([Char], SrcLoc) [LclId, Str=DmdType] lvl_sU8 = (lvl_sTZ, lvl_sU7) lvl_sU9 :: CallStack [LclId, Str=DmdType] lvl_sU9 = PushCallStack lvl_sU8 EmptyCallStack lvl_sUa :: [Char] [LclId, Str=DmdType] lvl_sUa = unpackCString# "Void showsPrec"# $cshowsPrec_aQD :: Int -> Empty -> ShowS [LclId, Str=DmdType b] $cshowsPrec_aQD = error @ 'Lifted @ (Int -> Empty -> ShowS) (lvl_sU9 `cast` (Sym (NTCo:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack))) lvl_sUa lvl_sUb :: Empty -> ShowS [LclId, Str=DmdType] lvl_sUb = case $cshowsPrec_aQD of wild_00 { } $cshowList_aQR :: [Empty] -> ShowS [LclId, Arity=2, Str=DmdType] $cshowList_aQR = showList__ @ Empty lvl_sUb $cshow_aQN :: Empty -> String [LclId, Arity=1, Str=DmdType b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] -> case $cshowsPrec_aQD of _ [Occ=Dead] { }}] $cshow_aQN = \ _ [Occ=Dead] -> case $cshowsPrec_aQD of wild_00 { } $fShowEmpty [InlPrag=[ALWAYS] CONLIKE] :: Show Empty [LclIdX[DFunId], Str=DmdType m, Unf=DFun: \ -> D:Show TYPE: Empty $cshowsPrec_aQD $cshow_aQN $cshowList_aQR] $fShowEmpty = D:Show @ Empty $cshowsPrec_aQD $cshow_aQN $cshowList_aQR $sshows_sTu :: Empty -> String -> String [LclId, Str=DmdType b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=False) Tmpl= case $cshowsPrec_aQD of _ [Occ=Dead] { }}] $sshows_sTu = lvl_sUb $s$dmshow_sTv :: Empty -> String [LclId, Arity=1, Str=DmdType b, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=-1,unsat_ok=True,boring_ok=False) Tmpl= \ _ [Occ=Dead] -> case lvl_sUb of _ [Occ=Dead] { }}] $s$dmshow_sTv = $cshow_aQN a_sT8 :: TrName [LclId, Str=DmdType m1] a_sT8 = TrNameS "main"# a_sT9 :: TrName [LclId, Str=DmdType m1] a_sT9 = TrNameS "T6031"# $trModule :: Module [LclIdX[ReflectionId], Str=DmdType m] $trModule = Module a_sT8 a_sT9 *** End of Offense *** : error: Compilation had errors *** unexpected failure for T6031(optasm) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 14:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 14:15:27 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.e99c27f8bd138d464474c855c9e769b4@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: deriving/should_compile/T6031 => deriving/should_compile/T6031, deriving/should_run/T7931 (WAY=hpc) Comment: T7931 fails as well, with `WAY=hpc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 14:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 14:25:32 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs Message-ID: <045.7e427084bf60386398394c8c253ebec9@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: typecheck/should_compile/DfltProb1 | (optasm) | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The program looks like this: {{{ module DfltProb1 where import Control.Monad.ST import Prelude hiding (traverse) traverse :: a -> ST s [a] traverse = undefined -- WORKS with signature test :: Num a => [a] test = runST (traverse 1) main = print test }}} This is the failure: {{{ $ ghc-7.11.20151225 -O DfltProb1.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151224 for x86_64-unknown-linux): CoreToStg.myCollectArgs (case traverse of _ [Occ=Dead] { }) realWorld# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 14:34:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 14:34:28 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing Message-ID: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ make TEST=GEq1 WAY=optasm TEST_HC=ghc-7.11.20151225 ... cd ./generics/GEq && ./GEq1 GEq1.run.stdout 2> GEq1.run.stderr Actual stdout output differs from expected: --- ./generics/GEq/GEq1.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 +++ ./generics/GEq/GEq1.run.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 @@ -3,5 +3,5 @@ True True False -True -True \ No newline at end of file +False +False \ No newline at end of file *** unexpected failure for GEq1(optasm) }}} The test was last touched by Ryan in 6cde981a8788b225819be28659caddc35b77972d (#10868) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 15:05:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 15:05:57 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.9583f04be39b0d101f161cb87149f19b@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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 monoidal): I like this idea, however, a proper implementation will have some consequences. Can you review? The intended result is that GADTs becomes a synonym for three extensions (GADTSyntax, EqualityConstraints and ExistentialQuantification), and the compiler never checks for -XGADTs, but always for one of the three flags. 1) Make GADTs imply ExistentialQuantification This will mean that GADTs will enable syntax `data A = forall a. A a`. 2) Add EqualityConstraints extension This extension will imply `MonoLocalBinds` and be implied by `GADTs` and `TypeFamilies`. It will be checked in `check_eq_pred`. The remaining work is removing two places where the compiler reads `-XGADTs` flag. 3) Allow pattern matches on GADTs without `-XGADTs` Currently pattern matching on GADTs requires `-XGADTs` or `-XTypeFamilies` due to #2905. This restriction was made due to `-XRelaxedPolyRec` flag. However, `-XRelaxedPolyRec` cannot be disabled since GHC 7.0, the original motivation is lost. I suggest to remove the check altogether - generally we check for flags at definition sites but not call sites. 4) Check for EqualityConstraints when defining a GADT This step is optional and I'm not sure about it. Consider this code {{{ {-# LANGUAGE GADTSyntax, ExistentialQuantification #-} data Eq a b where Eq :: Eq a a }}} Currently this code compiles, however, it might be argued that `-XEqualityConstraints` is needed here, since the same datatype in non- GADT syntax requires it (`data Eq a b = a ~ b => Eq`) and `-XGADTSyntax` is not supposed to add extra expressiveness. However, this change is not backwards compatible and would probably require a deprecation period. The rule would be that existentials and contexts require `-XExistentialQuantification`, but if there is a specialized result type it would require both `-XExistentialQuantification` and `-XEqualityConstraints`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 17:06:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 17:06:26 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.ab439d22b3edfa477b44f900fb772f6b@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 17:50:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 17:50:37 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.bfb2ee44401852aad25d9f5af272b7f5@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 olsner): ghc could very well default to use gold if it's available, I think. There are a few reasons to explicitly need bfd-ld (e.g. when using linker scripts), but for linking normal programs it shouldn't matter either way. To support "special" use cases, we'd just need to make sure `-optl-fuse- ld=bfd` overrides ghc's setting. > Could we enhance GHC to support running the linker in a "fast mode" I think this is not entirely up to the linking stage, as both split objects and function-sections are compile-time rather than link-time settings. Something that could be done at the linking stage is linking against the incrementally linked libraries-for-ghci - both split objects and split sections are undone by the incremental linking step. That might just run into different bottlenecks though :) Since #8405, `--gc-sections` is sent to the linker too. IIRC my previous experiments didn't find that it affected link times much unless actually using `-split-sections` for the installed libraries, but it could be moved to an explicit flag if need be. The downside of that is that users then have to learn a new flag to get smaller binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 18:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 18:08:30 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.431cdd08284f478a6715ef5308728d1f@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 ezyang): olsner: It's not, unless we install both "slow to link" and "quick to link" versions of static libraries. As you mention, this might be helpful anyway for loading statically linked libraries to GHCi. I *believe* my experiments showed that `--gc-sections` didn't really cost you anything if you weren't using `-split-sections`. So it should be fine to continue to pass it. Disabling it didn't really help with link times anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 18:28:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 18:28:02 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.95f5233c80540c4f364a681ea7a639c7@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Matt => Phyx- * testcase: => T11072gcc T11072msvc * differential: Phab:D1564 => Phab:D1564 Phab:D1696 * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:28:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:28:28 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.8138dcb2b2f72e87efac44958788c3ae@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): Replying to [comment:9 goldfire]: > I actually think I have the solution to this, but it's a rather large change (actually originally motivated by other problems): invent a new type `TyPat` that stores type patterns (instance LHSs) I really like this, having a separate data type for type patterns would certainly be a nice change and make things a lot easier. > > 2. Haskell is not lazy at the type level so I expect us to miss completeness which we can have at the term level due to laziness. > > Can you give an example? I don't understand. Hmmm, I have the following in mind: {{{#!hs data G = MkG G -- term level f :: G -> G f x = x -- non-redundant (inhabited by _|_, MkG _|_, etc) -- type level type family F (a :: G) :: G where F x = x -- redundant? }}} The way I see it, we can never construct a type of kind `G`, in contrast to the term level where every type is inhabited by bottom. Hence, at the term level, the checker does not need to unfold `x` to `MkG (MkG (...))`, for checking whether the clause is redundant. At the type level, I would expect the check to try this, and of course diverge. Does this make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:31:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:31:48 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.ff985f065717b47f49abeb17598880c0@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): `G` is inhabited at the type level, by `Any` for example. And by {{{#!hs type family Loopy :: G where Loopy = MkG Loopy }}} Normally, using something like `Loopy` in a program will cause GHC to issue an error, but sufficient cleverness can get this past the type- checker. So I would say your `F`'s equation is not redundant at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:48:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:48:46 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.61d03797dcafe0a63dbd56dbd4c21bd8@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): FTR: This is just a lint warning, and not an error, and as such not always correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:51:24 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.a7fa517a0db6d4645ee12b23592c9378@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think it says `warning`, but if it stops compilation, then it's a real error. And it should be: `case` expressions must have all possible alternative listed, or we have a potential type error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:52:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:52:39 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.4d28fe3063385cbfef7c0b350ff1672e@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): In this case, the lint error is a false alarm: {{{ lvl_sUb :: Empty -> ShowS [LclId, Str=DmdType] lvl_sUb = case $cshowsPrec_aQD of wild_00 { } $cshowList_aQR :: [Empty] -> ShowS }}} is indeed diverging for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 19:55:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 19:55:45 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.9725afb05fb4abe64ae93109b663b052@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I think it says warning, but if it stops compilation, then it's a real error. Right, the intention for the warning is to complain, but keep going, so this needs fixing. (I wouldn?t miss this warning if it were gone completely, as it cannot be complete) > And it should be: case expressions must have all possible alternative listed, or we have a potential type error. Not if the scrutinee diverges, as it is the case here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 20:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 20:15:34 -0000 Subject: [GHC] #11293: Compiler plugins don't work with profiling Message-ID: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> #11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 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: -------------------------------------+------------------------------------- Suppose I have a normally built compiler plugin, and I'd like to use it while building some profiled code. This doesn't work: (non-profiled) GHC searches for the profiled version of the plugin. This is wrong wrong wrong: plugin searches should be with respect to how GHC was compiled. (Test case: take the `plugins01` test and add `-prof` to it) Now that we have `-plugin-package`, it should be a simple matter to ensure that plugin lookups follow a different codepath, though I'm not sure how to figure out what GHC is built with; this should just be however TH does it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 20:48:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 20:48:37 -0000 Subject: [GHC] #11294: T9430 fails on ARM Message-ID: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> #11294: T9430 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (LLVM) | Keywords: | Operating System: Linux Architecture: arm | Type of failure: Incorrect result | at runtime Test Case: T9430 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The primops testcase for `timesWord2#` in `T9430` fails on ARM. {{{ cd ./primops/should_run && ./T9430 T9430.run.stdout 2> T9430.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T9430: Error for timesWord2# : Expected 1 and 0 but got 0 and 0 CallStack (from ImplicitParams): error, called at T9430.hs:55:22 in main:Main }}} It looks like this is probably an LLVM code generator bug although I have yet to confirm this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 20:51:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 20:51:39 -0000 Subject: [GHC] #11294: T9430 fails on ARM In-Reply-To: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> References: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> Message-ID: <061.3833210526b80e74822f9cd60a66d037@haskell.org> #11294: T9430 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T9430 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The primops testcase for `timesWord2#` in `T9430` fails on ARM. > {{{ > cd ./primops/should_run && ./T9430 T9430.run.stdout 2> > T9430.run.stderr > Wrong exit code (expected 0 , actual 1 ) > Stdout: > > Stderr: > T9430: Error for timesWord2# : Expected 1 and 0 but got 0 and 0 > CallStack (from ImplicitParams): > error, called at T9430.hs:55:22 in main:Main > }}} > It looks like this is probably an LLVM code generator bug although I have > yet to confirm this. New description: The primops testcase for `timesWord2#` in `T9430` fails on ARM. {{{ cd ./primops/should_run && ./T9430 T9430.run.stdout 2> T9430.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T9430: Error for timesWord2# : Expected 1 and 0 but got 0 and 0 CallStack (from ImplicitParams): error, called at T9430.hs:55:22 in main:Main }}} It looks like this is probably an 32-bit LLVM code generator bug although I have yet to confirm this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 20:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 20:52:10 -0000 Subject: [GHC] #11289: T8628 fails on ARM In-Reply-To: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> References: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> Message-ID: <061.4ca2d41c784e6f93cde7e4c0cd546603@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: I believe this is addressed by Phab:D1700. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 20:54:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 20:54:18 -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.cc01ec4124b49782ba6c796bdc826410@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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This isn't happening any time soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:01:58 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful Message-ID: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (LLVM) | 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: -------------------------------------+------------------------------------- Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce # -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:05 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.42be0162354b9190a5de0eaecee5476e@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:33 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMTI1NTogRXhwZWN0ZWQga2luZCDigJhrMA==?= =?utf-8?b?4oCZLCBidXQgaGFzIGtpbmQg4oCYKGZvcmFsbCBrLiBrLCBmb3Jh?= =?utf-8?b?bGwgay4gaynigJk=?= In-Reply-To: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> References: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> Message-ID: <059.109c60f5403f3f15710e7f1647e8df94@haskell.org> #11255: Expected kind ?k0?, but has kind ?(forall k. k, forall k. k)? -------------------------------------+------------------------------------- Reporter: atnnn | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 Richard Eisenberg ): In [changeset:"5e4e9e00dd36bf6316a406a14bc9482c7bcff527/ghc" 5e4e9e00/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e4e9e00dd36bf6316a406a14bc9482c7bcff527" Fix #11255. We need to instantiate types in tuples. Quite straightforward. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:33 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.c8d28640185be848d6f0418ae2414e82@haskell.org> #11254: GHC panic ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"bd7ab66875bb567693020279df2f8b5834bd24bb/ghc" bd7ab668/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd7ab66875bb567693020279df2f8b5834bd24bb" Test #11254 in typecheck/should_compile/T11254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:33 -0000 Subject: [GHC] #10589: Core Lint error with LambdaCase In-Reply-To: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> References: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> Message-ID: <062.5669fdb2d6d4e20396448f9a61a9df7c@haskell.org> #10589: Core Lint error with LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"b218241d6ba8c1a8dff3e9dbb461dbbc1d2ab412/ghc" b218241d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b218241d6ba8c1a8dff3e9dbb461dbbc1d2ab412" Test #10589 in typecheck/should_compile/T10589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:33 -0000 Subject: [GHC] #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs In-Reply-To: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> References: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> Message-ID: <060.ba5c02cdc587e73324df58c8d9d47cbd@haskell.org> #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T7681 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"da69358bfb1b71c6455c420399fd6a18a02ee5df/ghc" da69358b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da69358bfb1b71c6455c420399fd6a18a02ee5df" Fix #11287. Happily, the fix is simply deleting some old code. I love it when that happens. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:33 -0000 Subject: [GHC] #10619: Order matters when type-checking In-Reply-To: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> References: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> Message-ID: <062.766c939af5b7b073b5bd68f89d334fea@haskell.org> #10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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): -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"05e35414219c29d2eaf4bb29b6dd6fb8a8388e9b/ghc" 05e3541/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="05e35414219c29d2eaf4bb29b6dd6fb8a8388e9b" Test #10619 in typecheck/should_fail/T10619 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:02:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:02:45 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.ef8e5ea6b87c8d2ee2e7713f13b9ba8d@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11205, #11289 => #11205, #11289, #11294, #11295 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:08:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:08:41 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.3cbceead29fbc60153def57b2a91730a@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Builds using GHC's LLVM backend are currently substantially slower than > GHC's own native code generator. There are a few possible reasons for > this, > > 1. the cost of forking processes and serializing/parsing LLVM's > intermediate representation > 2. the cost of the more powerful optimizations responsible for LLVM's > (hopefully) better code generation > 3. the cost of redundant optimizations overlapping effort already > expended by GHC > > Given that some architecture (e.g. ARM) are only supported by LLVM and > therefore suffer considerably at the hand of our slow builds, we should > try to reduce # New description: Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce #3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:09:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:09:01 -0000 Subject: [GHC] #11289: T8628 fails on ARM In-Reply-To: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> References: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> Message-ID: <061.d9c2f3f230da9fe2a8c8b6f442d0652e@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:14:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:14:40 -0000 Subject: [GHC] #11296: T8726 fails on arm Message-ID: <046.3ee2000436c67657710ffa438a38a441@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Incorrect result | at runtime Test Case: T8726 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ cd ./numeric/should_run && ./T8726 T8726.run.stdout 2> T8726.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T8726: user error (divMod0 -2 79228162514264337593543950336) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:16:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:16:43 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on arm Message-ID: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> #11297: CmmSwitchTest fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: CmmSwitchTest | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Actual stdout output differs from expected: --- /dev/null 2015-12-26 13:34:29.750000000 +0100 +++ ./codeGen/should_run/CmmSwitchTest.run.stdout.normalised 2015-12-26 22:14:17.937137588 +0100 @@ -0,0 +1,57 @@ +ERR: aj (-1) is 1337 and not 41. +ERR: ak (-11) is 1337 and not 36. +ERR: ak (-10) is 1337 and not 37. +ERR: ak (-9) is 1337 and not 37. +ERR: ak (-8) is 1337 and not 38. +ERR: ak (-7) is 1337 and not 38. +ERR: ak (-6) is 1337 and not 39. +ERR: ak (-5) is 1337 and not 39. +ERR: ak (-4) is 1337 and not 40. +ERR: ak (-3) is 1337 and not 40. +ERR: ak (-2) is 1337 and not 41. +ERR: ak (-1) is 1337 and not 41. +ERR: al (0) is 1337 and not 42. +ERR: al (1) is 1337 and not 42. +ERR: al (2) is 1337 and not 43. +ERR: al (3) is 1337 and not 43. +ERR: al (4) is 1337 and not 44. +ERR: al (5) is 1337 and not 44. +ERR: al (6) is 1337 and not 45. +ERR: al (7) is 1337 and not 45. +ERR: al (8) is 1337 and not 46. +ERR: al (9) is 1337 and not 46. +ERR: al (10) is 1337 and not 47. +ERR: al (-11) is 1337 and not 36. +ERR: al (-10) is 1337 and not 37. +ERR: al (-9) is 1337 and not 37. +ERR: al (-8) is 1337 and not 38. +ERR: al (-7) is 1337 and not 38. +ERR: al (-6) is 1337 and not 39. +ERR: al (-5) is 1337 and not 39. +ERR: al (-4) is 1337 and not 40. +ERR: al (-3) is 1337 and not 40. +ERR: al (-2) is 1337 and not 41. +ERR: al (-1) is 1337 and not 41. +ERR: ay (4294967295) is 1337 and not 41. +ERR: az (4294967285) is 1337 and not 36. +ERR: az (4294967286) is 1337 and not 37. +ERR: az (4294967287) is 1337 and not 37. +ERR: az (4294967288) is 1337 and not 38. +ERR: az (4294967289) is 1337 and not 38. +ERR: az (4294967290) is 1337 and not 39. +ERR: az (4294967291) is 1337 and not 39. +ERR: az (4294967292) is 1337 and not 40. +ERR: az (4294967293) is 1337 and not 40. +ERR: az (4294967294) is 1337 and not 41. +ERR: az (4294967295) is 1337 and not 41. +ERR: ba (4294967285) is 1337 and not 36. +ERR: ba (4294967286) is 1337 and not 37. +ERR: ba (4294967287) is 1337 and not 37. +ERR: ba (4294967288) is 1337 and not 38. +ERR: ba (4294967289) is 1337 and not 38. +ERR: ba (4294967290) is 1337 and not 39. +ERR: ba (4294967291) is 1337 and not 39. +ERR: ba (4294967292) is 1337 and not 40. +ERR: ba (4294967293) is 1337 and not 40. +ERR: ba (4294967294) is 1337 and not 41. +ERR: ba (4294967295) is 1337 and not 41. \ No newline at end of file *** unexpected failure for CmmSwitchTest(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:17:02 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.9f0dc01377298137e109f057db4ebf65@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11205, #11289, #11294, #11295 => #11205, #11289, #11294, #11295, #11296, #11297 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:33:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:33:41 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.cdb7e0703a74c3579e006b610f3b50d4@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T11254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:34:46 -0000 Subject: [GHC] #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs In-Reply-To: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> References: <045.4e35d40d1809a8590c78c8d6f4fbf4b6@haskell.org> Message-ID: <060.ee55f3fe1a14f615f50958fdd849ac9d@haskell.org> #11287: Visible type application: ASSERT failed! file compiler/typecheck/TcMatches.hs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T7681 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Thanks for finding this, @thomie, and for making such a perspicuous bug title for me to find. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:35:22 -0000 Subject: [GHC] #10589: Core Lint error with LambdaCase In-Reply-To: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> References: <047.e92627c402f6d1706c28de3a321bc37c@haskell.org> Message-ID: <062.46c4d4a93c7f955a98d6ddcd84c7e08f@haskell.org> #10589: Core Lint error with LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10589 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T10589 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:35:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:35:55 -0000 Subject: [GHC] #10619: Order matters when type-checking In-Reply-To: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> References: <047.c2e45977ca8a75932617b490ff36950d@haskell.org> Message-ID: <062.5fcc9e480d83ca25261161d5a686df40@haskell.org> #10619: Order matters when type-checking -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T10619 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_fail/T10619 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:36:59 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMTI1NTogRXhwZWN0ZWQga2luZCDigJhrMA==?= =?utf-8?b?4oCZLCBidXQgaGFzIGtpbmQg4oCYKGZvcmFsbCBrLiBrLCBmb3Jh?= =?utf-8?b?bGwgay4gaynigJk=?= In-Reply-To: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> References: <044.88009019ef9d9865594bcfb5353ffa94@haskell.org> Message-ID: <059.7c678cfd93e4e0701fe4d744cbc48f43@haskell.org> #11255: Expected kind ?k0?, but has kind ?(forall k. k, forall k. k)? -------------------------------------+------------------------------------- Reporter: atnnn | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11255 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => polykinds/T11255 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 21:44:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 21:44:57 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.0fbd62d23375274fe0644cb52f305713@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I previously fixed `T10518` in the `ghc-7.10` branch (in 3b718b7abb544aa788779dce36e96b0bfae03ebf) but apparently never applied the fix to `master`. What a pleasant surprise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 22:25:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 22:25:08 -0000 Subject: [GHC] #11294: T9430 fails on ARM In-Reply-To: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> References: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> Message-ID: <061.ebf1c6799e3e956135b18b5bfc3c0497@haskell.org> #11294: T9430 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T9430 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1702 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1702 Comment: This was actually a matter of the test itself being incorrect, assuming that a host word size of 64 bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 22:42:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 22:42:53 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.50b61e07cdc275e504c5ff7ad460c9ec@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I don't think the scrutinee is diverging here, I think the problem is something else. I tried to debug this a little bit, here's some more info about the error: {{{ : warning: [in body of lambda with binder x_aT4 :: Empty] No alternatives for a case scrutinee not known to diverge for sure: lvl_sUi The whole expression: case lvl_sUi of _ [Occ=Dead] { } Scrutinee type: Empty -> ShowS Expression type: String }}} Here from the type of the scrutinee we can't say it's diverging, because that type has inhabitants like {{{const ""}}} etc. One weird thing about this error message is that in the printed module {{{x_aT4}}} is not used at all, so I'm not sure where did the linter find that variable. Too bad we don't have stack traces.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 26 23:02:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Dec 2015 23:02:37 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.c6b3eb2895a602f993312b1b57191705@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm... {{{#!hs n,d :: Integer (n,d) = (-2, 79228162514264337593543950337) f :: Integer -> Integer -> Integer f n d = (n `div` d) * d + (n `mod` d) main :: IO () main = let r = f n d in print (n, r, r-n, r==n, r/=n) }}} results in, {{{ $ inplace/bin/ghc-stage2 -O Hello.hs [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... $ ./Hello (-2,-2,0,False,True) }}} What a world we live in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:42:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:42:18 -0000 Subject: [GHC] #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 In-Reply-To: <047.efd17d599edaee400b6320c08d507412@haskell.org> References: <047.efd17d599edaee400b6320c08d507412@haskell.org> Message-ID: <062.84c720ac133a07724715d09f69f33022@haskell.org> #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1680 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"e8672e5e6cd4db6bbe3a1183f4fbf5496292621c/ghc" e8672e5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8672e5e6cd4db6bbe3a1183f4fbf5496292621c" libraries/ghci: Implement mkJumpToAddr for ppc64 Test Plan: validated on powerpc64 and powerpc64le Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1680 GHC Trac Issues: #11257 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:42:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:42:18 -0000 Subject: [GHC] #11289: T8628 fails on ARM In-Reply-To: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> References: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> Message-ID: <061.38bd7579adbee329989a63f0b748d6d2@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"909bbdb59700b7d5c8aa6a3f9b4797003d9e62bd/ghc" 909bbdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="909bbdb59700b7d5c8aa6a3f9b4797003d9e62bd" Linker(ELF): Fix addProddableBlocks usage The range marked as proddable didn't actually match the range that we mapped. This fixed `ghc-api/T8628` et al on ARM. Test Plan: Validate Reviewers: austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1700 GHC Trac Issues: #11289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:42:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:42:18 -0000 Subject: [GHC] #11294: T9430 fails on ARM In-Reply-To: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> References: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> Message-ID: <061.c450c595d702d3ce05b3aa3adb26bae6@haskell.org> #11294: T9430 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T9430 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1702 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0b0652f1e9183e92be10de5aa2b44d9c12c5a68e/ghc" 0b0652f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b0652f1e9183e92be10de5aa2b44d9c12c5a68e" testsuite/T9430: Fix word-size dependence Summary: This test was wrong. Test Plan: Validate Reviewers: erikd, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1702 GHC Trac Issues: #11294 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:46:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:46:16 -0000 Subject: [GHC] #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 In-Reply-To: <047.efd17d599edaee400b6320c08d507412@haskell.org> References: <047.efd17d599edaee400b6320c08d507412@haskell.org> Message-ID: <062.1c045d87d95a0773b31c5da38f6478c7@haskell.org> #11257: GHCi: InfoTable.hs: Unknown architecture on powerpc64 ----------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1680 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:49:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:49:13 -0000 Subject: [GHC] #11294: T9430 fails on ARM In-Reply-To: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> References: <046.23f0bf9fecb16b2b386ec2fd876ac619@haskell.org> Message-ID: <061.b7e89fd26c922c9ed789978cb1e31909@haskell.org> #11294: T9430 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T9430 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1702 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:50:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:50:40 -0000 Subject: [GHC] #10464: ghc 7.8.4 on arm In-Reply-To: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> References: <051.d5878ed901f03828231ecea66d3e9618@haskell.org> Message-ID: <066.71eb4e6298c1642dca6a252226f843c6@haskell.org> #10464: ghc 7.8.4 on arm ---------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10376 | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe this has been fixed in the resolution for #11205, Phab:D1599. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 00:52:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 00:52:37 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.d33bfdae49ddcb796022965b242425ae@haskell.org> #10376: arm/linux linking failure -------------------------------------+------------------------------ Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe this has been fixed with the resolution of #11205, Phab:D1599. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 01:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 01:19:41 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.ad9edc03c0cea3d982cb972507465976@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+---------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Phab:D1704 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1704 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 01:20:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 01:20:39 -0000 Subject: [GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI In-Reply-To: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> References: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> Message-ID: <062.df73475c32e014f6d19cb3a6bd0e8b29@haskell.org> #9414: GHC 7.8.3 compilation fails on Raspberry PI ---------------------------------+------------------------------ Reporter: ipuustin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by bgamari): * status: infoneeded => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 01:23:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 01:23:38 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.7244eb335a062bea46eb90ca6cb67dcc@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+---------------------------------- Reporter: muhmuhten | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: => 7.10.3 Comment: muhmuhten, can you confirm that this has been fixed in 7.10.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 01:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 01:25:44 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.6acf48549dccadf83b4b4832c2a34de6@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by bgamari): I think the solution here is to reenable Thumb linkage and fix up any issues that we reveal. I'm working on this currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 01:29:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 01:29:49 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.97d64f682541b42b40bbcb93f162739b@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+---------------------------------- Reporter: muhmuhten | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by muhmuhten): I don't currently have the resources to confirm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 06:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 06:34:46 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations Message-ID: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 06:35:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 06:35:31 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.1beebacc1fd2434a75b3eadd2950baf0@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 pikajude: Old description: > Given the following code: > > {{{#!hs > {-# LANGUAGE ImplicitParams #-} > > import GHC.Stack > > class Foo a where > foo :: a -> String > > main = putStrLn $ foo () > }}} > > In GHC 7.11.20151216, the following instances result in no output: > > {{{#!hs > instance Foo () where > foo () = prettyCallStack ?loc > }}} > > {{{#!hs > fooHelper = prettyCallStack ?loc > > instance Foo () where > foo () = fooHelper > }}} > > Though this one does: > > {{{#!hs > fooHelper () = prettyCallStack ?loc > > instance Foo () where > foo = fooHelper > }}} > > The aforementioned instances all yield output with GHC 7.10.3 (after > replacing `prettyCallStack` with `showCallStack`). New description: Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} Including explicit signatures with `-XInstanceSigs` has no effect. The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 06:36:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 06:36:21 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.f3fe4719004453a5885405522f6500ba@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 pikajude: Old description: > Given the following code: > > {{{#!hs > {-# LANGUAGE ImplicitParams #-} > > import GHC.Stack > > class Foo a where > foo :: a -> String > > main = putStrLn $ foo () > }}} > > In GHC 7.11.20151216, the following instances result in no output: > > {{{#!hs > instance Foo () where > foo () = prettyCallStack ?loc > }}} > > {{{#!hs > fooHelper = prettyCallStack ?loc > > instance Foo () where > foo () = fooHelper > }}} > > Though this one does: > > {{{#!hs > fooHelper () = prettyCallStack ?loc > > instance Foo () where > foo = fooHelper > }}} > > Including explicit signatures with `-XInstanceSigs` has no effect. > > The aforementioned instances all yield output with GHC 7.10.3 (after > replacing `prettyCallStack` with `showCallStack`). New description: Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper }}} Including explicit signatures with `-XInstanceSigs` has no effect. The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`): {{{ ?loc, called at implicit.hs:9:28 in main:Main }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 06:38:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 06:38:06 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.9bc0558b86e2c0af4ca6b90de8f259ca@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 pikajude: Old description: > Given the following code: > > {{{#!hs > {-# LANGUAGE ImplicitParams #-} > > import GHC.Stack > > class Foo a where > foo :: a -> String > > main = putStrLn $ foo () > }}} > > In GHC 7.11.20151216, the following instances result in no output: > > {{{#!hs > instance Foo () where > foo () = prettyCallStack ?loc > }}} > > {{{#!hs > fooHelper = prettyCallStack ?loc > > instance Foo () where > foo () = fooHelper > }}} > > Though this one does: > > {{{#!hs > fooHelper () = prettyCallStack ?loc > > instance Foo () where > foo = fooHelper > }}} > > Including explicit signatures with `-XInstanceSigs` has no effect. > > The aforementioned instances all yield output with GHC 7.10.3 (after > replacing `prettyCallStack` with `showCallStack`): > > {{{ > ?loc, called at implicit.hs:9:28 in main:Main > }}} New description: Given the following code: {{{#!hs {-# LANGUAGE ImplicitParams #-} import GHC.Stack class Foo a where foo :: a -> String main = putStrLn $ foo () }}} In GHC 7.11.20151216, the following instances result in no output: {{{#!hs instance Foo () where foo () = prettyCallStack ?loc }}} {{{#!hs fooHelper = prettyCallStack ?loc instance Foo () where foo () = fooHelper }}} Though this one does: {{{#!hs fooHelper () = prettyCallStack ?loc instance Foo () where foo = fooHelper {- CallStack (from ImplicitParams): fooHelper, called at implicit.hs:11:11 in main:Main -} }}} Including explicit signatures with `-XInstanceSigs` has no effect. The aforementioned instances all yield output with GHC 7.10.3 (after replacing `prettyCallStack` with `showCallStack`): {{{ ?loc, called at implicit.hs:9:28 in main:Main }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 06:38:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 06:38:29 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.225513479a2099ee036d098c769fc619@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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 ak3n): Is it okay that GHC (master head) compiles it without problems now? Build of fork with test: https://travis-ci.org/ak3n/ghc/jobs/98938720 Commit: https://github.com/ak3n/ghc/commit/aee63f611b30164cc1c828a66d22e6e7302af385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 08:36:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 08:36:45 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.62a0c5ad65a957da2fcd5663669505f3@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks for the experiment. I was attempting to get an interim version out for GHC `8.0` hence the attempt to re-use weak-symbols to get specifically `libmingwex` to link. As I have missed that Window anyway I will instead target `8.2` and do a proper fix of the link behavior along with other changes that are required for other tickets. The behavior you described is correct, `ld` is using `libBFD` for symbol resolving. So the resolution behavior is described there. http://ftp.gnu.org/old-gnu/Manuals/bfd-2.9.1/html_mono/bfd.html#SEC149 Describes how the different kind of symbols are resolved. Also you can just ask `ld` directly. `--print-map` will print out how it's resolving symbols. (If called via `GCC` use `-Wl,--print-map`). > I think because of this 2nd difference we end up with all kinda strange unresolved symbols like __image_base and similar which cause so much problems. We'll have to resolve this symbol in any case. `__image_base` is an `ld` symbol that it inserts during linking, if we want to load `mingw` object files we have to deal with it. This is easy to resolve anyway. It's just `IMAGE_DOS_HEADER` in the final link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 10:23:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 10:23:46 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.324a69e51642a4ea18f7a1da3588af35@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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): The error should now be triggered by switching around the constraints. {{{ {-# LANGUAGE PatternSynonyms #-} pattern Pat :: () => Show a => a -> Maybe a pattern Pat a = Just a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 10:50:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 10:50:11 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.f9c2f4755a881f349d9abd04b23aca76@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): More trimmed down repro-case: {{{#!hs {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -O0 #-} import GHC.Integer.GMP.Internals import GHC.Exts main :: IO () main = do print (x, isValidInteger x) print (y, isValidInteger y) print (z, isValidInteger z) -- reports (-2,False) on 32bit where z = x + y x = 0x0ffffffffffffffffffffffff :: Integer -- 3 limbs y = -0x1000000000000000000000001 :: Integer -- 4 limbs isValidInteger i = isTrue# (isValidInteger# i) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 10:51:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 10:51:10 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on arm In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.4f2283e736bdb3f3b6b9d279f9f53fc9@haskell.org> #11297: CmmSwitchTest fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nomeata (added) Comment: It actually appears that this test is generally broken on 32-bit platforms due to its use of 64-bit literals. I'm going to mark this as `expect_broken` on 32-bit platforms for now. Ccing nomeata who is the original author. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 10:54:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 10:54:17 -0000 Subject: [GHC] #11289: T8628 fails on ARM In-Reply-To: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> References: <046.d8352b9a45f83a945a6ea517f6a1f14a@haskell.org> Message-ID: <061.9a48382369c521098e93e8aa2e23e961@haskell.org> #11289: T8628 fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 11:00:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 11:00:14 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.25026cd676459027d568d51e11902099@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted ---------------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Description changed by bgamari: Old description: > i tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian > jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF > Cortex A20) and get in file NLP.Corpora.Conll a panic: > > [ 9 of 23] Compiling NLP.Corpora.Conll ( src/NLP/Corpora/Conll.hs, > dist/build/NLP/Corpora/Conll.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for arm-unknown-linux): > Simplifier ticks exhausted > When trying UnfoldingDone $fGSerialize:*:_$s<$> > 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: 2748218 > > i do not notice anything particular in the code, except a very long data > type with enumerated values. I tried with a higher value for tick-factor > (1000) with no improvement. > > i will now try to run 7.10.2-2 from experimental. New description: i tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF Cortex A20) and get in file `NLP.Corpora.Conll` a panic: {{{ [ 9 of 23] Compiling NLP.Corpora.Conll ( src/NLP/Corpora/Conll.hs, dist/build/NLP/Corpora/Conll.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for arm-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fGSerialize:*:_$s<$> 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: 2748218 }}} i do not notice anything particular in the code, except a very long data type with enumerated values. I tried with a higher value for tick-factor (1000) with no improvement. i will now try to run 7.10.2-2 from experimental. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 12:49:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 12:49:45 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.e8d227647b5ae609598f1a2c5a3074f8@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As of a3b34b64136143fc117e572fab81e7b564b26f8e (with `CmmSwitchTest` marked as broken), {{{ Unexpected results from: TEST="T11255 dynamic-paper T8726 outofmem linker_unload T5435_v_gcc recomp011 T10359 T9203 T7257 lazy-bs-alloc T5321FD T5030 T4801 T5631 T5837 T9872a T9872d T9872b T3064 T9872c T1969 T5321Fun T783 T9233 T9961 haddock.Cabal haddock.compiler haddock.base" OVERALL SUMMARY for test run started at Sun Dec 27 12:38:36 2015 CET 1:05:53 spent to go through 4955 total tests, which gave rise to 15703 test cases, of which 10797 were skipped 72 had missing libraries 4697 expected passes 108 expected failures 1 caused framework failures 0 unexpected passes 7 unexpected failures 22 unexpected stat failures Unexpected failures: dependent/should_compile dynamic-paper [exit code non-0] (normal) driver/recomp011 recomp011 [bad stdout] (normal) numeric/should_run T8726 [bad exit code] (normal) polykinds T11255 [exit code non-0] (normal) rts T5435_v_gcc [bad exit code] (normal) rts linker_unload [bad exit code] (normal) rts outofmem [bad stdout] (normal) }}} Progress! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 12:54:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 12:54:33 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on arm In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.df3932b2d9e5825d16aed9355215f61e@haskell.org> #11297: CmmSwitchTest fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1ebbb0c5929038d0eeb28009bd03c18262dce7d/ghc" d1ebbb0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1ebbb0c5929038d0eeb28009bd03c18262dce7d" testsuite/CmmSwitchTest: Mark as broken on 32-bit platforms As pointed out in #11297 this test is broken on 32-bit platforms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 12:54:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 12:54:57 -0000 Subject: [GHC] #11260: Re-compilation tests fail on powerpc64 In-Reply-To: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> References: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> Message-ID: <062.106e6799ad41fdcf058ebaedfeb5c2bc@haskell.org> #11260: Re-compilation tests fail on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I am seeing this same thing on ARM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 13:14:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 13:14:24 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM Message-ID: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `rts/T5435_gcc_v` testcase fails on ARM. As far as I can tell there are two principle failure modes: hanging and segmentation faulting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 13:15:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 13:15:23 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.6e59d4a83111fd0a1cb83fb1c1743e11@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by bgamari): A segmentation fault look like this, {{{ $ gdb --args ./T5435_v_gcc v ./T5435_load_v_gcc.o ... (gdb) run Starting program: /mnt/ext/exp/ghc/testsuite/tests/rts/T5435_v_gcc v ./T5435_load_v_gcc.o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". initializer run Program received signal SIGSEGV, Segmentation fault. __GI__IO_fflush (fp=0xe3403000) at iofflush.c:40 40 iofflush.c: No such file or directory. (gdb) bt #0 __GI__IO_fflush (fp=0xe3403000) at iofflush.c:40 #1 0xb6ff6150 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 13:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 13:15:37 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.13a7f71f03931eed2210801d4d5bfe4d@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Description changed by bgamari: Old description: > The `rts/T5435_gcc_v` testcase fails on ARM. As far as I can tell there > are two principle failure modes: hanging and segmentation faulting. New description: The `rts/T5435_gcc_v` testcase sometimes fails on ARM. As far as I can tell there are two principle failure modes: hanging and segmentation faulting. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 13:19:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 13:19:00 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.0facf9612d78c345921bbd74fb684fcb@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The first bad commit appears to be, {{{ commit 9e8562ae02701270e2c1dfcee3279d862dc5b7b6 Author: Ben Gamari Date: Fri Aug 21 10:37:39 2015 +0200 Implement getSizeofMutableByteArrayOp primop Now since ByteArrays are mutable we need to be more explicit about when the size is queried. Test Plan: Add testcase and validate Reviewers: goldfire, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1139 GHC Trac Issues: #9447 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 14:07:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 14:07:54 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.a5d69b954681218fced3d85ab7c71213@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by bgamari): Here's another outcome with a useful backtrace due to compiling with `-debug`, {{{ (gdb) run Starting program: /mnt/ext/exp/ghc/testsuite/tests/rts/T5435_v_gcc v ./T5435_load_v_gcc.o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". post-initLinker post-if Program received signal SIGILL, Illegal instruction. 0xb6ff7000 in ?? () (gdb) bt #0 0xb6ff7000 in ?? () #1 0x002be160 in ocRunInit_ELF (oc=0x0) at rts/Linker.c:5685 #2 0x002be160 in ocRunInit_ELF (oc=0x38e9d8) at rts/Linker.c:5685 #3 0x002b9ea4 in resolveObjs_ () at rts/Linker.c:2447 #4 0x002b9f30 in resolveObjs () at rts/Linker.c:2475 #5 0x0000ad3c in r3ze_info$def () Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 14:23:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 14:23:44 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.692bb2914351c116545f48c4ca585203@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I don't think the scrutinee is diverging here Sure it is! The error says the scrutinee is `lvl_sUi`. We have `lvl_sUb = case $cshowsPrec_aQD of wild_00 { }` and {{{ $cshowsPrec_aQD :: Int -> Empty -> ShowS [LclId, Str=DmdType b] $cshowsPrec_aQD = error @ 'Lifted @ (Int -> Empty -> ShowS) (lvl_sU9 `cast` (Sym (NTCo:IP[0] <"callStack">_N _N) :: CallStack ~R# (?callStack::CallStack))) lvl_sUa }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 14:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 14:26:14 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on arm In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.2f27016c5a946144a177191bd0bdfb4e@haskell.org> #11297: CmmSwitchTest fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer Comment: Yes, as you write on the mailing list, it would make sense to have tests for both platform, guarded by CPP. Note that the test case is actually produced by `CmmSwitchTestGen.hs` in the same directory. I won?t get to it immediately, so marking this as newcomer. Not a very ?hip? task, but a nice small thing for anyone who wants to easily get a GHC commit with his name on it :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:17:43 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.ca7282a2536ab1e8d0aa2abbe951f57a@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1707 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1707 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:18:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:18:29 -0000 Subject: [GHC] #11297: CmmSwitchTest fails on 32-bit platforms (was: CmmSwitchTest fails on arm) In-Reply-To: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> References: <046.bbf13a9102a88aa01c80eb4863e3217f@haskell.org> Message-ID: <061.9b516cf87e1050fab4656e70b12faed7@haskell.org> #11297: CmmSwitchTest fails on 32-bit platforms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: CmmSwitchTest Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:22:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:22:10 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.27192efb84464889b36d5cf596130828@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by bgamari): I believe the issue here may be incomplete instruction cache flushing. With this patch, {{{#!patch diff --git a/rts/Linker.c b/rts/Linker.c index aadd8d4..1101dea 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -2748,8 +2748,10 @@ static void ocFlushInstructionCache( ObjectCode *oc ) { // Object code + printf("Flushed %p - %p\n", oc->image, oc->image + oc->fileSize); __clear_cache(oc->image, oc->image + oc->fileSize); // Jump islands + printf("Flushed %p - %p\n", oc->symbol_extras, &oc->symbol_extras[oc->n_symbol_extras]); __clear_cache(oc->symbol_extras, &oc->symbol_extras[oc->n_symbol_extras]); } @@ -5706,6 +5708,7 @@ static int ocRunInit_ELF( ObjectCode *oc ) init_start = (init_t*)init_startC; init_end = (init_t*)(init_startC + shdr[i].sh_size); for (init = init_start; init < init_end; init++) { + printf("init %p\n", init); (*init)(argc, argv, envv); } } }}} I see the following output on failure, {{{ Flushed 0xb6ff7000 - 0xb6ff753c Flushed 0xb6ff6008 - 0xb6ff6138 init 0xb6ff6190 Program received signal SIGILL, Illegal instruction. 0xb6ff7000 in ?? () }}} Indeed it looks like the location with the initializer (0xb6ff6190) was never flushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:40:50 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.a4e0d0472e9080cc09109ba1cc182ca0@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1708 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1708 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:43:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:43:43 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.e56c0f826469b037a9506e2c3be78762@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1708 Wiki Page: | -------------------------------------+---------------------------------- Comment (by bgamari): The test survives 500 runs without failure with Phab:D1708. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 15:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 15:47:57 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.d13d0b4dab415d2d9a7cbd3fd50aa03f@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1708 Wiki Page: | -------------------------------------+---------------------------------- Comment (by bgamari): It also seems that this fixed the `linker_unload` test! Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 16:21:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 16:21:23 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.521a2f269ac872536f8006f26feb134f@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One additional issue that would be of great help to ARM is to speed up the LLVM backend a bit by eliminating redundant passes. See #11295. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 16:22:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 16:22:47 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM Message-ID: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> #11300: outofmem RTS testcase fails on ARM --------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------- The `outofmem` RTS testcase fails on ARM, {{{ =====> outofmem(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory outofmem outofmem.run.stdout 2> outofmem.run.stderr Actual stdout output differs from expected: --- ./outofmem.stdout.normalised 2015-12-27 17:21:08.718240403 +0100 +++ ./outofmem.run.stdout.normalised 2015-12-27 17:21:08.718240403 +0100 @@ -1 +1 @@ -exit(251) \ No newline at end of file +exit(1) \ No newline at end of file *** unexpected failure for outofmem(normal) }}} In particular, {{{ $ make outofmem make[1]: Entering directory '/mnt/ext/exp/ghc/testsuite/tests/rts' '/mnt/ext/exp/ghc/inplace/test spaces/ghc-stage2' -fforce-recomp -dcore- lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn- tabs -fno-warn-missed-specialisations -v0 --make -fforce-recomp outofmem.hs -o outofmem make[1]: Leaving directory '/mnt/ext/exp/ghc/testsuite/tests/rts' outofmem: out of memory (requested 1074790400 bytes) exit(1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 16:28:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 16:28:32 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.9dfa7b5d1c33e4f2b868110674fb7ca2@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by bgamari): The problem appears to be that the RTS is failing to allocate, {{{ $ gdb ./outofmem ... Reading symbols from ./outofmem...done. (gdb) break stg_exit Breakpoint 1 at 0x32a378: file rts/RtsStartup.c, line 533. (gdb) run Starting program: /mnt/ext/exp/ghc/testsuite/tests/rts/outofmem [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". outofmem: out of memory (requested 1074790400 bytes) Breakpoint 1, stg_exit (n=1) at rts/RtsStartup.c:533 533 if (exitFn) (gdb) bt #0 stg_exit (n=1) at rts/RtsStartup.c:533 #1 0x0034d5a8 in my_mmap_or_barf (addr=0x76900000, size=1074790400, operation=3) at rts/posix/OSMem.c:225 #2 0x0034d710 in osGetMBlocks (n=1025) at rts/posix/OSMem.c:285 #3 0x00370e68 in getCommittedMBlocks (n=1025) at rts/sm/MBlock.c:534 #4 0x00370f68 in getMBlocks (n=1025) at rts/sm/MBlock.c:580 #5 0x0033facc in alloc_mega_group (mblocks=1025) at rts/sm/BlockAlloc.c:327 #6 0x0033fbdc in allocGroup (n=262145) at rts/sm/BlockAlloc.c:354 #7 0x0034a0c8 in allocate (cap=0x3f02c0 , n=268435459) at rts/sm/Storage.c:818 #8 0x00353070 in stg_newByteArrayzh$def () Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 16:31:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 16:31:35 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.e882ad7f47d644ed920a94c52b97be27@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by thomie): * cc: Phyx (added) Comment: Fails on Windows as well. See this addition of `testsuite/tests/rts/outofmem.stdout-i386-unknown- mingw32` in https://phabricator.haskell.org/D1340?vs=on&id=4578#788ffc72. And this discussion on irc: {{{ "15-10-21T18:56:56"< thomie > Phyx-: the only comment I have now is, are you sure about updated output for outofmem? Last time I checked, I didn't quite understand what that test was supposed to do. "15-10-21T18:57:38"< Phyx- > thomie: I am, but I was actually going to undo it and see if I can't het it to output the expected error code. "15-10-21T18:58:13"< Phyx- > thomie: the problem is that when the exception is thrown, it's hitting the VEH handlers, which call stg_exit(1); "15-10-21T18:58:32"< Phyx- > so it never enters main again. "15-10-21T18:58:54"< thomie > ok, I'll look at it later. "15-10-21T18:59:37"< Phyx- > it's a bit unrelated to the patch I changed it in, so i was going to make anothe diff for it. and see what the exception i get is and see how to handle it in the VEH stuff. "15-10-21T19:00:02"< Phyx- > I don't know how the errors are handled under linux, but I find it odd that it can return to main.. "15-10-21T19:08:52"< Phyx- > thomie: Basically, the test is checking to see if this line is hit https://github.com/ghc/ghc/blob/master/rts/RtsMain.c#L80 but on Windows it just won't get there as it exits here https://github.com/ghc/ghc/blob/master/rts/win32/veh_excn.c#L65 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 16:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 16:34:05 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.0f3528924137581f2f4d44a3a31b6d58@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: Simonmar, perhaps you could shed some light on how this is supposed to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 17:46:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 17:46:59 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.5900e7dad56b4e8ba8deaa428681a979@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1707 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"11778f74da669b13e3748191e89e3c3cafed903b/ghc" 11778f7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="11778f74da669b13e3748191e89e3c3cafed903b" Add testcase for getSizeofMutableByteArray# In an attempt to track down #11296. Unfortunately the primop appears to be working as expected. Test Plan: validate Reviewers: hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1706 GHC Trac Issues: #11296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 17:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 17:47:00 -0000 Subject: [GHC] #11296: T8726 fails on arm In-Reply-To: <046.3ee2000436c67657710ffa438a38a441@haskell.org> References: <046.3ee2000436c67657710ffa438a38a441@haskell.org> Message-ID: <061.dfa30a156ff63bb91af9708807e566a2@haskell.org> #11296: T8726 fails on arm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: T8726 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1707 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"07b3be76a14a061a43846ef41f1dd7819603be4e/ghc" 07b3be76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07b3be76a14a061a43846ef41f1dd7819603be4e" integer-gmp: Fix #11296 This was introduced by a mental fumble in 9e8562ae02701270e2c1dfcee3279d862dc5b7b6 wherein I replaced `getSizeofMutableByteArray` with `getSizeofMutBigNat`. This was noticed by invalid integers being produced on 32-bit machines in #11296. Test Plan: Validate Reviewers: hvr, goldfire, austin Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1707 GHC Trac Issues: #11296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 17:59:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 17:59:54 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.386d15d0247c976c8bdf957fa58e1494@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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): I just tried this with a recent version of HEAD and there is still the same bad error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 18:00:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 18:00:10 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.47a895a6ee34028770c24d3dc7798fa1@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > Consider the following program > > {{{ > {-# LANGUAGE PatternSynonyms #-} > > pattern Pat :: Show a => () => a -> Maybe a > pattern Pat a = Just a > }}} > > GHC complains that > > {{{ > test.hs:4:9: No instance for (Show a) arising from a pattern > }}} > > I think this is quite difficult to understand. The problem is that > matching on `Just a` doesn't provide the show constraint (it provides no > constraints). A better error message here would explain this fact and > maybe a short explanation of the difference between prov/req in a pattern > synonym signature. New description: Consider the following program {{{ {-# LANGUAGE PatternSynonyms #-} pattern Pat :: () => Show a => a -> Maybe a pattern Pat a = Just a }}} GHC complains that {{{ test.hs:4:9: No instance for (Show a) arising from a pattern }}} I think this is quite difficult to understand. The problem is that matching on `Just a` doesn't provide the show constraint (it provides no constraints). A better error message here would explain this fact and maybe a short explanation of the difference between prov/req in a pattern synonym signature. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 18:58:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 18:58:37 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.3b7bcbd49a8e822f03a5f4f371b327a5@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 bgamari: Old description: > Consider the example (which uses `Text`; I'm working on finding a more > minimal example), > {{{#!hs > import Data.Char (isSpace) > import Data.List (foldl') > import GHC.Exts (build) > import qualified Data.Text as T > > longestWord :: T.Text -> Int > longestWord t = foldl' max 0 $ map T.length $ fusedWords t > > fusedWords :: T.Text -> [T.Text] > fusedWords t0 = build $ \cons nil -> > let go !t > | T.null t = nil > | otherwise = let (w, rest) = T.span (not . isSpace) t > in cons w (go $ T.dropWhile isSpace rest) > in go t0 > > -- For reference > data Text = Text > {-# UNPACK #-} !A.Array -- payload (Word16 elements) > {-# UNPACK #-} !Int -- offset (units of Word16, not > Char) > {-# UNPACK #-} !Int -- length (units of Word16, not > Char) > }}} > > `longestWord` here produces the simplified Core`, > > {{{#!hs > Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> > [T.Text] > Ticket.$wgo = ... > > -- > $wgo1 xs n = foldl' (\a b -> max a $ T.length b) n xs > Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# > Ticket.$wgo1 = > \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> > case w_s4GJ of _ { > [] -> ww_s4GN; > : y_a4vC ys_a4vD -> > case y_a4vC > of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> > let { > a_a4jO :: GHC.Prim.Int# > a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in > letrec { > -- Why must you allocate? For the love of all that is good, > why? > -- > -- This loop is just `T.length`, the first argument being the > -- length accumulator and the second being an index into the > -- ByteArray# > $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> > GHC.Prim.Int# > $wloop_length_s4GI = > \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD > a_a4jO) -- bounds check > of _ { > False -> { > ... > -- in this body there are few cases analyses with > -- recursive calls of the form > $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) > (GHC.Prim.+# ww2_s4GD 1) > ... > True -> ww1_s4Gz > }; } in > case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> > case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) > of _ { > False -> Ticket.$wgo1 ys_a4vD ww_s4GN; > True -> Ticket.$wgo1 ys_a4vD ww1_s4GH > } > } > } > } > > longestWord :: T.Text -> Int > longestWord = > \ (w_s4GT :: T.Text) -> > case w_s4GT > of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> > case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 > of ww4_s4H2 { __DEFAULT -> > GHC.Types.I# ww4_s4H2 > } > } > }}} > > Notice `$wloop_length_s4GI`: It should be a nice tight loop counting > Unicode characters in the array `dt_a4jP` until it arrives at its end. > However, GHC fails to lambda-lift this closure, thereby turning it into > an allocating operation! Oh no! New description: Consider the example (which uses `Text`; I'm working on finding a more minimal example), {{{#!hs import Data.Char (isSpace) import Data.List (foldl') import GHC.Exts (build) import qualified Data.Text as T longestWord :: T.Text -> Int longestWord t = foldl' max 0 $ map T.length $ fusedWords t fusedWords :: T.Text -> [T.Text] fusedWords t0 = build $ \cons nil -> let go !t | T.null t = nil | otherwise = let (w, rest) = T.span (not . isSpace) t in cons w (go $ T.dropWhile isSpace rest) in go t0 -- For reference data Text = Text {-# UNPACK #-} !A.Array -- payload (Word16 elements) {-# UNPACK #-} !Int -- offset (units of Word16, not Char) {-# UNPACK #-} !Int -- length (units of Word16, not Char) }}} `longestWord` here produces the simplified Core, {{{#!hs Ticket.$wgo :: GHC.Prim.ByteArray# -> GHC.Prim.Int# -> GHC.Prim.Int# -> [T.Text] Ticket.$wgo = ... -- > $wgo1 xs n = foldl' (\a b -> max a $ T.length b) n xs Ticket.$wgo1 :: [T.Text] -> GHC.Prim.Int# -> GHC.Prim.Int# Ticket.$wgo1 = \ (w_s4GJ :: [T.Text]) (ww_s4GN :: GHC.Prim.Int#) -> case w_s4GJ of _ { [] -> ww_s4GN; : y_a4vC ys_a4vD -> case y_a4vC of _ { Data.Text.Internal.Text dt_a4jP dt1_a4jQ dt2_a4jR -> let { a_a4jO :: GHC.Prim.Int# a_a4jO = GHC.Prim.+# dt1_a4jQ dt2_a4jR } in letrec { -- For the love of all that is good, why must you allocate? -- -- This loop is essentially `T.length`, the first argument being -- the length accumulator and the second being an index into the -- ByteArray# $wloop_length_s4GI :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $wloop_length_s4GI = \ (ww1_s4Gz :: GHC.Prim.Int#) (ww2_s4GD :: GHC.Prim.Int#) -> -- Have we reached the end of the Text? case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# ww2_s4GD a_a4jO) of _ { False -> { ... -- in this body there are few cases analyses which -- classify the code-points we encounter. The branches -- are recursive calls of the form $wloop_length_s4GI (GHC.Prim.+# ww1_s4Gz 1) (GHC.Prim.+# ww2_s4GD 1) ... True -> ww1_s4Gz }; } in case $wloop_length_s4GI 0 dt1_a4jQ of ww1_s4GH { __DEFAULT -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.<=# ww_s4GN ww1_s4GH) of _ { False -> Ticket.$wgo1 ys_a4vD ww_s4GN; True -> Ticket.$wgo1 ys_a4vD ww1_s4GH } } } } longestWord :: T.Text -> Int longestWord = \ (w_s4GT :: T.Text) -> case w_s4GT of _ { Data.Text.Internal.Text ww1_s4GW ww2_s4GX ww3_s4GY -> case Ticket.$wgo1 (Ticket.$wgo ww1_s4GW ww2_s4GX ww3_s4GY) 0 of ww4_s4H2 { __DEFAULT -> GHC.Types.I# ww4_s4H2 } } }}} Notice `$wloop_length_s4GI`: It should be a nice tight loop counting Unicode characters in the array `dt_a4jP` until it arrives at its end. However, GHC fails to lambda-lift this closure, thereby turning it into an allocating operation! Oh no! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 22:29:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 22:29:22 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.1a3edebe20d830b0b72151776e3688b6@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 Ben Gamari ): In [changeset:"bec5350da09fde51231004b1b7d33641ac51800e/ghc" bec5350d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bec5350da09fde51231004b1b7d33641ac51800e" Adding flags: -ffull-guard-reasoning and too-many-guards Introduction of two new flags, for more precise control over the new pattern match checker's behaviour when reasoning about guards. This is supposed to address #11195 (and maybe more performance bugs related to the NP-Hardness of coverage checking). Expected behaviour: * When `-ffull-guard-reasoning` is on, run the new pattern match checker in its full power * When `-ffull-guard-reasoning` is off (the default), for every match, check a metric to see whether pattern match checking for it has high probability of being non performant (at the the moment we check whether the number of guards is over 20 but I would like to use a more precise measure in the future). If the probability is high: - Oversimplify the guards (less expressive but more performant) and run the checker, and - Issue a warning about the simplification that happened. A new flag `-Wtoo-many-guards/-Wno-too-many-guards` suppresses the warning about the simplification (useful when combined with -Werror). Test Plan: validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1676 GHC Trac Issues: #11195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 22:53:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 22:53:51 -0000 Subject: [GHC] #11269: powerpc64le: Build fails in rts/Linker.c In-Reply-To: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> References: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> Message-ID: <062.715c592d59233d9d76f1c006d232f37e@haskell.org> #11269: powerpc64le: Build fails in rts/Linker.c -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1672 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c8d0af3107d4a01b73f813e31ac9b989772a2288/ghc" c8d0af3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8d0af3107d4a01b73f813e31ac9b989772a2288" RTS: Detect powerpc64le as ELF 64-bit system Test Plan: validate Reviewers: simonmar, erikd, austin, bgamari Reviewed By: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1672 GHC Trac Issues: #11269 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 23:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 23:14:06 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.19e6b114d7674c0c78cfd8903f5f4c8d@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1708 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"0054bcd42260d248e391ed01d6b3da4fefdad45c/ghc" 0054bcd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0054bcd42260d248e391ed01d6b3da4fefdad45c" rts/Linker(ARM): Ensure all code sections are flushed from cache Test Plan: Validate with T12299 Reviewers: hsyl20, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1708 GHC Trac Issues: #11299 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 27 23:24:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Dec 2015 23:24:52 -0000 Subject: [GHC] #11299: T5435_gcc_v fails on ARM In-Reply-To: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> References: <046.2aa6754b1c0d0144c5c180b1810754f6@haskell.org> Message-ID: <061.cb6a1ee79ea400e6f4c572fbdfd24497@haskell.org> #11299: T5435_gcc_v fails on ARM -------------------------------------+---------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1708 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 02:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 02:24:28 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.af9f72f34df730ee52ef1ac24d26e90d@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 doesn't appear to be specific to generics. Rather, it's an issue with `eqAddr#` and how it's affected by optimization levels. Here's a simplified example that takes away the complexity of `GEq1`: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} Compiling this with `-O0` makes the program return `True`, but compiling with `-O1` or higher returns `False`. Is pointer equality unpredictable enough that it can fail the reflexive property if optimized enough? If so, I can just modify `GEq1` so as not to include `Addr#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 05:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 05:01:39 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult Message-ID: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.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: -------------------------------------+------------------------------------- After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ?HsExpr? let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Is there a reason it has to be this difficult? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 05:02:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 05:02:24 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.02749167aa6f84d80762497f3b8dbcd8@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bitemyapp: Old description: > After a couple hours, 30-some browser tabs, and attempting to use ghc- > simple to paper over some annoyances with GHC's API (dynFlags/session- > stuff, particularly), I gave up. > > I then opened up haskell-src-exts and found the function I wanted in a > minute or two. > > {{{#!hs > > import qualified Language.Haskell.Exts.Parser as P > > parsePls' :: String -> IO () > parsePls' s = print $ P.parseExp s > }}} > > This is where I got stuck: > > {{{ > Prelude> parsePls "1 + 1" > Too late for parseStaticFlags: call it before runGhc or runGhcT > }}} > > This is the code I was working with before I gave up on GHC: > > {{{#!hs > module ParsePls where > > import DynFlags > import FastString > import qualified GHC > import qualified GhcMonad as GM > import HsSyn > import Lexer > import Outputable > import Parser > import RdrName > import SrcLoc > import StaticFlags > import StringBuffer > > import qualified Language.Haskell.GHC.Simple as S > import qualified Language.Haskell.GHC.Simple.Types as ST > > import System.Environment > > main :: IO () > main = do > [expr] <- getArgs > parsePls expr > > parsePls :: String -> IO () > parsePls s = do > initStaticOpts > let sbuf = stringToStringBuffer s > srcloc = mkRealSrcLoc (mkFastString s) 1 1 > (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig > -- dynflags <- undefined -- GHC.getSessionDynFlags > -- unP :: P a -> PState -> ParseResult a > > -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState > -- parseExpression :: P (LHsExpr RdrName) > -- type LHsExpr id = Located (HsExpr id) -- Defined in ?HsExpr? > > let parseResult = unP parseExpression > (mkPState dynflags sbuf srcloc) > case parseResult of > POk _ (L _ mdl) -> print $ showPpr dynflags mdl > PFailed ss _ -> do > putStrLn "Error occurred!" > print ss > }}} > > Is there a reason it has to be this difficult? New description: After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ?HsExpr? let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Whereas with haskell-src-exts I got: {{{ Prelude> parsePls' "1 + 1" ParseOk (InfixApp (Lit (Int 1)) (QVarOp (UnQual (Symbol "+"))) (Lit (Int 1))) }}} Which was perfectly satisfactory. Is there a reason it has to be this difficult? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 05:47:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 05:47:51 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.9f981d85518f8e4bec72eaac74f24659@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Have you considered getting a recent build of GHC 8 and doing this as a frontend plugin? Here's something that works for a recent GHC build: {{{ module Print where import GhcPlugins import DynFlags import FastString import GhcMonad import DriverPhases import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import ErrUtils import Control.Monad frontendPlugin :: FrontendPlugin frontendPlugin = defaultFrontendPlugin { frontend = doPrint } doPrint :: [String] -> [(String, Maybe Phase)] -> Ghc () doPrint args [] = error "usage: ghc --frontend Print File.hs" doPrint args fs = do dflags <- getDynFlags forM_ fs $ \(src_filename, _) -> do buf <- liftIO $ hGetStringBuffer src_filename let loc = mkRealSrcLoc (mkFastString src_filename) 1 1 case unP parseModule (mkPState dflags buf loc) of PFailed span err -> liftIO $ throwOneError (mkPlainErrMsg dflags span err) POk pst rdr_module -> liftIO . putStrLn $ showSDoc dflags (ppr rdr_module) }}} Here's how to build and run it; {{{ ghc --make Print.hs -package ghc -dynamic-too ghc --frontend Print Print.hs }}} Evidently, we should expose some sort of function which takes just a file name (rather than a `ModSummary`, which is a little touchy to get). This should be simple enough for someone to add. And I agree: static/dynamic flag initialization is terrible. It would be well worth someone trying to see if we can (finally) get rid of the rest of the static flags. It would also be useful to know what kind of abstracting API people would like to get dumped into the `Ghc` monad with minimum fuss. There IS some fuss involved; for example, it's convenient to have GHC's options parser around so that `DynFlags` are as configurable as they are with GHC. Would love proposals! (Willing to improve it, but it's very unclear what a good interface is supposed to be. One of the reasons I wrote the frontend plugins patch instead.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 05:58:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 05:58:22 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.dc9c8dfbdaeba1d761f7942ba65a2d27@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bitemyapp): >Willing to improve it, but it's very unclear what a good interface is supposed to be. This is good: http://hackage.haskell.org/package/haskell-src-exts-1.17.1/docs/Language- Haskell-Exts-Parser.html#v:parseExp The code you posted is going to send new people running for the hills (or Rust. or OCaml). There's no documentation, no way of knowing why one would want a frontend plugin or what problem it is solving for us. Googling the error message I got earlier was quite fruitless too. We don't really have to spend a lot of time discussing the API. Just catching up the GHC API's UX to the standard set by haskell-src-exts is sufficient for my purposes. Is there a reason a parser of Haskell source code needs to emit IO? If not, then there should be types like this available: {{{#!hs parseExp :: String -> ParseResult Exp }}} even if there are nittier-grittier underlying functions/facilities available. Further, why doesn't `ParseResult` in the GHC API have a Show instance? Trying to figure out something simple like, "parse this expression from a string and print the parse tree to stdout", with GHC's API is way-way-way harder than it should be and adding "more stuff" that the user has to know-about, care-about, etc. isn't good enough. It also looks like this frontend plugin thing doesn't work for REPL use. This is also not satisfactory. I'm assuming there are serious, difficult technical reasons the API provided by GHC doesn't include a simple "just parse the damn string" function with a Showable ParseResult. Could someone please explain those reasons? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 08:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 08:40:41 -0000 Subject: [GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode` Message-ID: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> #11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 attempting to self-bootstrap GHC HEAD I discovered that `utils/genprimocode` can't be compiled with GHC HEAD. How to reproduce roughly: {{{ $ cd utils/genprimcode $ alex --ghc Lexer.x $ happy --ghc Parser.y $ ghc-7.11.20151226 --make Main [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) ...killed by OS due to running out-of-memory after using up >10GiB ram.... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 10:37:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 10:37:49 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker Message-ID: <046.076adf4676a7bff5c198511775a24988@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- hvr stumbled upon this issue while attempting to bootstrap GHC with GHC HEAD. In so doing he found that GHC HEAD required more than 10 GB of memory while compiling `genprimopcode` (and never completed). It appears that this blow-up is due to the new pattern checker. In particular it appears that the pattern checker is affected quite adversely by sets of patterns sharing a prefix. For instance, this example, {{{#!hs import System.Environment main :: IO () main = do args <- getArgs print $ case head args of "--primop-primop-info" -> "turtle" "--primop-tag" -> "asdf" "--primop-list" -> "casdhf" "--primop-vector-uniques" -> "this" "--primop-vector-tys" -> "is" "--primop-vector-tys-exports" -> "silly" "--primop-vector-tycons" -> "hmmm" "--make-haskell-wrappers" -> "123512" "--make-haskell-source" -> "as;dg" "--make-latex-doc" -> "adghiw" _ -> error "Should not happen, known_args out of sync?" }}} As written GHC requires over ten gigabytes of heap and several minutes to compile the example. If one perform `s/--primop-//` to this example it takes 500ms to compile. Alternatively, if on replace the first `-` in each of the `--primop` strings with a unique character (thus breaking the shared prefixes) compilation time is a bit shy of a second. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 10:40:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 10:40:24 -0000 Subject: [GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode` In-Reply-To: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> References: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> Message-ID: <057.c993d02260bce19c8cb40a019d0b3760@haskell.org> #11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #11303 Comment: This is a duplicate of #11303. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 10:41:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 10:41:30 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.8ee09dbcf3f2871aca96e44b89b9b5e4@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => highest * related: => #11302 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 10:56:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 10:56:11 -0000 Subject: [GHC] #11304: GHC master segfaults when run with +RTS -h Message-ID: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> #11304: GHC master segfaults when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151218 $ ghc +RTS -h ghc: no input files Usage: For basic information, try the `--help' option. Segmentation fault }}} This appears to be due to ce1f1607ed7f8fedd2f63c8610cafefd59baaf32, {{{ commit ce1f1607ed7f8fedd2f63c8610cafefd59baaf32 Author: Simon Marlow Date: Sat Nov 7 09:39:05 2015 +0000 Make GHCi & TH work when the compiler is built with -prof }}} Which removes an `initProfiling2` call from `hs_init_ghc`, which means that `initHeapProfiling` is never called, which means that `censuses` is never initialized, which causes a crash during cleanup on RTS shutdown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 11:27:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 11:27:44 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.775afa4edddaa136562c950319dfdae0@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is essentially a duplicate of #10961. I agree it should be easier to use the parser and don't think there is a good reason why it isn't pure. FWIW, `ghc-exactprint` provides a bit of a nicer interface around the entry points which you might want to use in the mean time. https://hackage.haskell.org/package/ghc-exactprint-0.5.0.1/docs/Language- Haskell-GHC-ExactPrint-Parsers.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 13:08:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 13:08:42 -0000 Subject: [GHC] #11269: powerpc64le: Build fails in rts/Linker.c In-Reply-To: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> References: <047.9b4eeca452f5d2ca855dbb940482e3a5@haskell.org> Message-ID: <062.841349c0a9202bb042db78beb95d59b4@haskell.org> #11269: powerpc64le: Build fails in rts/Linker.c -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1672 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 13:53:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 13:53:18 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.fdbbd560291a8f62ce15338e62df40ff@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): As of today's commit c7830bdb14e0a85a78617314156d101155fdf7aa , this bug seems to persist. It would be interesting to see if it is just me or if somebody can reproduce the problem. I can add another bit of information. While the `inplace/bin/deriveConstants` process is running and seems to hang, I performed `top` and can see that `deriveConstants` is consuming '''14GB of memory'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 14:19:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 14:19:56 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.6e9399f5432e649e3e734d941c673da0@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by Phyx-): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 14:20:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 14:20:15 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.28089843bbfbf9c16e9ab7a95eb991ef@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by bgamari): * cc: Phyx- (removed) * cc: Phyx (added) Comment: I have also noticed failures of this sort on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 14:20:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 14:20:26 -0000 Subject: [GHC] #11300: outofmem RTS testcase fails on ARM In-Reply-To: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> References: <046.2ebfe155513a30b50222775e2adcccb3@haskell.org> Message-ID: <061.f4122e31fa9c9d6b247a80e11b38e9df@haskell.org> #11300: outofmem RTS testcase fails on ARM ----------------------------------+------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by bgamari): * cc: Phyx (removed) * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 16:00:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 16:00:10 -0000 Subject: [GHC] #11305: TC Regression Message-ID: <042.df96d1651596559a8340fd36e204e4be@haskell.org> #11305: TC Regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (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: -------------------------------------+------------------------------------- TODO: figure out better summary ;-) The following snippet extracted from Edward's `profunctors` package compiles with GHC 7.10.3, but fails to type-check with GHC HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} module Data.Profunctor.Strong where import Control.Arrow import Control.Category import Data.Tuple import Prelude hiding (id,(.)) infixr 0 :-> type p :-> q = forall a b. p a b -> q a b class Profunctor p where dimap :: (a -> b) -> (c -> d) -> p b c -> p a d class ProfunctorFunctor t where promap :: Profunctor p => (p :-> q) -> t p :-> t q class ProfunctorFunctor t => ProfunctorMonad t where proreturn :: Profunctor p => p :-> t p projoin :: Profunctor p => t (t p) :-> t p class ProfunctorFunctor t => ProfunctorComonad t where proextract :: Profunctor p => t p :-> p produplicate :: Profunctor p => t p :-> t (t p) class Profunctor p => Strong p where first' :: p a b -> p (a, c) (b, c) first' = dimap swap swap . second' second' :: p a b -> p (c, a) (c, b) second' = dimap swap swap . first' ---------------------------------------------------------------------------- newtype Tambara p a b = Tambara { runTambara :: forall c. p (a, c) (b, c) } instance Profunctor p => Profunctor (Tambara p) where dimap f g (Tambara p) = Tambara $ dimap (first f) (first g) p instance ProfunctorFunctor Tambara where promap f (Tambara p) = Tambara (f p) instance ProfunctorComonad Tambara where proextract (Tambara p) = dimap (\a -> (a,())) fst p produplicate (Tambara p) = Tambara (Tambara $ dimap hither yon p) where hither :: ((a, b), c) -> (a, (b, c)) hither ~(~(x,y),z) = (x,(y,z)) yon :: (a, (b, c)) -> ((a, b), c) yon ~(x,~(y,z)) = ((x,y),z) instance Profunctor p => Strong (Tambara p) where first' = runTambara . produplicate }}} {{{ Strong.hs:57:12: error: ? Couldn't match type ?Tambara p (a, c) (b, c)? with ?forall c1. Tambara p (a, c1) (b, c1)? Expected type: Tambara (Tambara p) a b -> Tambara p (a, c) (b, c) Actual type: Tambara (Tambara p) a b -> forall c. Tambara p (a, c) (b, c) ? In the first argument of ?(.)?, namely ?runTambara? In the expression: runTambara . produplicate In an equation for ?first'?: first' = runTambara . produplicate ? Relevant bindings include first' :: Tambara p a b -> Tambara p (a, c) (b, c) (bound at Strong.hs:57:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 16:39:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 16:39:06 -0000 Subject: [GHC] #11305: TC Regression In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.279d0d5ebb4c34d17d64eb3cc2955418@haskell.org> #11305: TC Regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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 hvr): * owner: => goldfire Comment: According to `git bisect`, the culprit is 2db18b8135335da2da9918b722699df684097be9 (i.e. visible type applications) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 18:47:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 18:47:25 -0000 Subject: [GHC] #11306: Do not generate warning in `do` when result is of type `Void`. Message-ID: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> #11306: Do not generate warning in `do` when result is of type `Void`. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- GHC generates warnings when `do` notation statements discard their result, without an explicit `_ <- `, unless the discarded result is of type `()`. Another type which is used to indicate "no result", is `Void` from `Data.Void`. There are no meaningful values of this type, so we should also skip the warnings for such situations. Here is an example: {{{#!hs import Data.Void f :: IO Void f = undefined main :: IO () main = do f return () }}} GHC output: {{{ test.hs:7:11: Warning: A do-notation statement discarded a result of type ?Void? Suppress this warning by saying ?_ <- f? or by using the flag -fno-warn-unused-do-bind }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 18:58:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 18:58:29 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators Message-ID: <044.2722f1013c64633fbf159145867daa0f@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- GHC 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 21:03:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 21:03:35 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.33f54e7af47ae9b6a308d9455af07f9c@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Can you try with `-fno-warn-overlapping-patterns -fno-warn-incomplete- patterns`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 21:08:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 21:08:41 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.a9d359e8fe82f731bb88defbd855eb68@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 heisenbug]: > It would be interesting to see if it is just me or if somebody can reproduce the problem. Re `genprimopcode` see #11302 and #11303 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 21:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 21:14:03 -0000 Subject: [GHC] #11305: TC regression due introduced by visible type-application (was: TC Regression) In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.22d4641d6d8326a09ee8586b7bff6b39@haskell.org> #11305: TC regression due introduced by visible type-application -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: regression 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 hvr): * keywords: => regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 21:23:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 21:23:24 -0000 Subject: [GHC] #11305: Type checker regression introduced by visible type-application (was: TC regression due introduced by visible type-application) In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.b46f37a158e06958a6d1006b5d7c976d@haskell.org> #11305: Type checker regression introduced by visible type-application -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: regression 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 Mon Dec 28 21:46:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 21:46:06 -0000 Subject: [GHC] #11233: Improve optimisation of pattern synonym matching In-Reply-To: <049.c3c9bdcea20f761bdc3df1ecf3f93c02@haskell.org> References: <049.c3c9bdcea20f761bdc3df1ecf3f93c02@haskell.org> Message-ID: <064.ddce9d04987a13fea3a5801a72e95dcd@haskell.org> #11233: Improve optimisation of pattern synonym matching -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: newcomer, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 22:18:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 22:18:34 -0000 Subject: [GHC] #11308: haddock and Cabal regression Message-ID: <045.bef4bc658305621ca0faad0da4cce2ea@haskell.org> #11308: haddock and Cabal regression -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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's the bug: https://github.com/haskell/cabal/issues/3004 It's blocking on: https://github.com/haskell/haddock/issues/379 This ticket is to make sure we don't ship a buggy Cabal/haddock pair. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 28 23:44:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Dec 2015 23:44:26 -0000 Subject: [GHC] #11309: Warn on shady data constructor export Message-ID: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> #11309: Warn on shady data constructor export -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- If a module defines a datatype and exports some, but not all, of the constructors, then modules importing the type will find it difficult to perform sensible and total case analyses. This is most likely to be a problem when a module that names exported constructors adds a new constructor. Could we get a warning for this, please? Note: this applies also to data family instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 01:59:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 01:59:17 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.223d583e14a5c9e033da3b52accf88d9@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another place "in the wild" where this appears to occur is `text-icu`. Attempting to compile `Data.Text.ICU.Regex.Internal` very quickly eats up all of my RAM. I tried waiting for about half an hour for it to finish before giving up (then again, I was using a laptop with "only" 4 GB of RAM). If pattern matching is the culprit, then [https://github.com/bos /text- icu/blob/bfe19b0b4214a586ebcaecc33d460e679a5133f6/Data/Text/ICU/Regex/Internal.hsc#L177 toURegexOpts] is the probable scene of the crime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 02:20:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 02:20:48 -0000 Subject: [GHC] #11306: Do not generate warning in `do` when result is of type `Void`. In-Reply-To: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> References: <047.10643f12d431cb206ac3b006b2adba9a@haskell.org> Message-ID: <062.d76228cfa6ff58e97604dd9eba91685b@haskell.org> #11306: Do not generate warning in `do` when result is of type `Void`. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm not a fan of this warning in the first place, but if anything, I would think it is most important to warn when the discarded value is of type `Void`, since that typically indicates that the following code is unreachable... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 02:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 02:27:48 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.bcaffa33ec021db074f85909992191f8@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In a way, the fact that memory usage explodes on such small inputs is encouraging: surely some mild effort on algorithms/data structures will have a massive effect here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 02:38:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 02:38:31 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.12380580a247bc4e9440a0e3caa8392e@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): It looks like GHC is happy to inline everything in your simplified example leaving {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} The value `"a"#` has been duplicated, so there are now two copies of the string constant in the program, with different addresses. For your test you can presumably work around this with NOINLINE annotations on `u0` and `uf0`. This duplication seems like generally undesirable behavior though; leaving aside the question of whether or not it is "semantically correct", it makes the resulting object file unnecessarily large (imagine the string was much longer than a single character). Probably worth opening a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 02:42:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 02:42:56 -0000 Subject: [GHC] #11288: Thread blocked indefinitely in a Mvar operation In-Reply-To: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> References: <045.c5dda8462296cf5810545b23ce6f03f0@haskell.org> Message-ID: <060.f6fc69d6be6f0fc4e60636793dcdf34c@haskell.org> #11288: Thread blocked indefinitely in a Mvar operation ------------------------------------------+------------------------------ Reporter: ygor_2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Comment (by rwbarton): It looks like the original error is here: {{{ ghc.exe: fd:4: hGetContents: invalid argument (invalid byte sequence) }}} I can't fathom a guess as to what it's doing though. Could you perhaps try running that failing ghc command with `-v`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 02:50:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 02:50:54 -0000 Subject: [GHC] #11304: GHC master segfaults when run with +RTS -h In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.878941d361434d72d9d183c87df4bb53@haskell.org> #11304: GHC master segfaults when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 rwbarton): I assume this is really "Haskell programs built without profiling segfault when run with `+RTS -h`"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 03:16:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 03:16:42 -0000 Subject: [GHC] #11310: Surprising accepted constructor for GADT instance of data family Message-ID: <045.1fcd83bf1e52860605d836fed11ed5fe@haskell.org> #11310: Surprising accepted constructor for GADT instance of data family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 -- Accepted: data family Foo (x :: *) :: * -> * data instance Foo Int Char where Foo :: Foo Int Char -- Not accepted data Bar Char where Bar :: Bar Char }}} It seems the second example, using a simple GADT, is syntactically barred from having a specific type constructor in its "head". That syntactic restriction is relaxed, however, for ''all'' arguments of the data instance, even though I'd expect it only for the first argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 03:44:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 03:44:22 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * Message-ID: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 `* :: *`, I can specialize a function of type `a -> a` to type `* -> *`. This seems like potentially not a great idea, and GHCi agrees: {{{ rwbarton at morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151228: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType Prelude> import Data.Kind Prelude Data.Kind> :t id :: * -> * id :: * -> * :: * -> * Prelude Data.Kind> (id :: * -> *) undefined `seq` () Segmentation fault }}} Also, when compiling a module containing the above expression, I get a panic while producing Cmm: {{{ rwbarton at morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 t [1 of 1] Compiling Main ( t.hs, t.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151228 for x86_64-unknown-linux): idToReg sat_sKV }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 03:47:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 03:47:39 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.7ca2b2f35d33d0897ca97caf15f3e93e@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): Apparently I don't really have to `:set -XTypeInType` to do this. It's enough to `import Data.Kind`. Is that intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 04:33:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 04:33:02 -0000 Subject: [GHC] #11312: GHC inlining primitive string literals can affect program output Message-ID: <050.6392f4ea96644f5394022cd373a55178@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 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: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 04:34:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 04:34:02 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.9d288f0c763c2bbc5f847cce6ca44782@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1714 * related: => #11312 Comment: Adding `{-# NOINLINE #-}` pragmas does indeed do the trick. I've opened Phab:D1714 for that workaround. I've also opened #11312 regarding the inlining issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 04:37:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 04:37:54 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2311313=3A_Awkward_error_message_=22Expecti?= =?utf-8?b?bmcgb25lIGZld2VyIGFyZ3VtZW50IHRvIOKAmCrigJki?= Message-ID: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> #11313: Awkward error message "Expecting one fewer argument to ?*?" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (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 first error below has a strange first line. Admittedly the input is nonsense, but as `*` has no arguments, according to the March Hare, it can't have one fewer argument. Note that the second error does not contain this problematic line. {{{ rwbarton at morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151228: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> :set -XTypeApplications Prelude Data.Kind> :t fmap @ (*) :1:8: error: ? Expecting one fewer argument to ?*? Expected kind ?* -> *?, but ?*? has kind ?*? ? In the type ?*? In the expression: fmap @* Prelude Data.Kind> :t fmap @ Int :1:8: error: ? Expected kind ?* -> *?, but ?Int? has kind ?*? ? In the type ?Int? In the expression: fmap @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 04:39:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 04:39:07 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.c98cf1dcf8165b9d081b4a9866c436d7@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 rwbarton): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 05:31:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 05:31:45 -0000 Subject: [GHC] #11305: Type checker regression introduced by visible type-application In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.468e8b3f29eab641b2663df9abbc914d@haskell.org> #11305: Type checker regression introduced by visible type-application -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11305 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1715 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * testcase: => typecheck/should_compile/T11305 * differential: => Phab:D1715 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 09:35:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 09:35:33 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.ec7e498922821a9a9a68a7c9888f24ad@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 gkaracha): Replying to [comment:5 osa1]: > I don't understand the argument about the definition not having any arguments. The exhaustiveness checker somehow checking for some patterns, right? And on the process it has to realize that some patterns are not checked. Whatever that it's finding on the process, it should print! Am I missing anything? Yes, this is true! But there are at least two good reasons at the moment for not printing this information: * This information may be too much for the eye (think of a big definition with a well-populated `where`-clause, like the ones you often find in GHC itself). Don't forget that the bag contains **all** constraints that are in scope, independently of being relevant to the specific match or not. * The pattern match checker does some simplifications in order to have reasonable performance and memory requirements. As you can see, there are already many problems concerning the checker's performance: #11195, #11239, #11276, ... so I would not push it more at the moment. The simplifications I am talking about are important not only for performance but also for the consistency of the final result and its usefulness to the user. At the moment the checker does not substitute in `HsExpr`. Instead, I have lifted `HsExpr` to `PmExpr`: {{{#!hs data PmExpr = PmExprVar Id | PmExprCon DataCon [PmExpr] | PmExprLit PmLit | PmExprEq PmExpr PmExpr -- Syntactic equality | PmExprOther (HsExpr Id) -- Note [PmExprOther in PmExpr] }}} Term substitution at the moment does not affect `PmExprOther` (see function `substPmExpr` in `deSugar/PmExpr.hs`) because substituting in `HsSyn` would be massive and at the moment would affect only the appearance but not the expressive power of the check. Hence, the final result may look inconsistent (it is not, because we do not actually inspect `HsExpr` at all so substituting or not at the moment makes no difference). I would like to give something more detailed to the user too but for the moment I think it is not a priority so, for now, I'd go with what I showed above, until I have a nice solution to these problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 10:22:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 10:22:48 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.24e35ef88edb4ca7b939b9a9bc2ef0d0@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Ahhhh, I see. This has been noticed before. Actually, I have added a note in `deSugar/Check.hs` about it: `Note [Literals in PmPat]`. My primary test case for this problem has been function `mkTextEncoding'` from `libraries/base/GHC/IO/Encoding.hs` until now but I guess your example stresses the same problem even more. The source of the problem lies in the way we translate literals: * In the paper, we treat them as guards: literal `l` gets translated to `x (True <- x == l)`. This allows the algorithm to work uniformly on everything but is too expensive, even for `mkTextEncoding'`. Essentially, the covered set contains `x |> {True ~ (x == l)}` and the uncovered contains `x |> {False ~ (x == l)}`. Hence, we explode first (everything is a guard) and then prune (use the term oracle to check the constraints) which is really exponential. * Hence, I changed the implementation and added literals in the pattern language. This means that for literal `l` the covered set contains `l |> {}` and the uncovered set contains `x |> {False ~ (x == l)}` like before. Since literals are patterns, more things can be checked eagerly, like with constructors where we can see immediately that e.g. `True` can not match `False`. Hence, we generate less from the start. The last thing to do (and I think this will address all performance issues concerning literals) is to completely add literals in the pattern language, that is, use a variant of Sestoft's negative patterns: {{{#!hs data PmPat :: PatTy -> * where PmCon :: { ... } -> PmPat t PmVar :: Id -> PmPat t PmLit :: PmLit -> PmPat t PmNLit :: Id -> [PmLit] -> PmPat VA -- add this constructor PmGrd :: { ... } -> PmPat PAT }}} The idea is that `PmNLit x lits` represents in a compact way __all literals `x` that are **not equal** to any of `lits`__. Hence, we generate much less and there is significantly less need for pruning. There is a slight possibility that this change will affect #322 and also I expect the size of the checker to increase 5-10% (LoC) but I have no better solution at the moment. Any ideas on this approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 10:23:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 10:23:40 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.557473538316c8594c9faeac1cefb4b9@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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): Thanks for thinking through the implications of this! I'm now not sure that the principle I articulated (`GADTs = GADTSyntax + ExistentialQuantification + EqualityConstraints`) is essential. My instinctive reactions are: 1. Perhaps it would be better if this still required `ExistentialQuantification`, i.e. `GADTs` would enable existential GADTs but not plain existential datatypes? 2. Yes. 3. I'm in two minds about this. I know our general policy is to require flags only at definition sites, but type refinement on pattern matching is the whole point of GADTs, and is significantly different to non-GADT matching, so it seems like it is reasonable to mark the use sites as well. Perhaps GADT pattern matches should require `EqualityConstraints` (and hence `GADTs` would suffice)? 4. I'm surprised that `GADTs` is not required in your example: my vote is to treat it as a bug and fix it without a deprecation period. I'd expect `GADTSyntax + ExistentialQuantification` to allow data constructors with existential variables and contexts, but not specialized result types. I don't particularly mind whether this declaration is or is not accepted by `GADTSyntax + ExistentialQuantification + EqualityConstraints` without `GADTs`. I'd be interested to hear what others think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 11:55:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 11:55:02 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.39b9ab264c61adb5747c3768fb4afd65@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:5 mpickering]: > Can you try with `-fno-warn-overlapping-patterns -fno-warn-incomplete- patterns`? BINGO! Doing this manually allowed me to continue bootstrapping :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 11:56:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 11:56:52 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.64eebece7cf96b31707ced7e7c368ca6@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: 11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * status: new => closed * resolution: => duplicate * related: => 11303 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 11:57:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 11:57:10 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.92442456d792ba88500c78ab5e7280a1@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * related: 11303 => #11303 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:02:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:02:54 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.e57176e43b83f8ce12e28b7ace62b869@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Great! Nevertheless, I am working already on fixing #11303, and I think it would be worth it to try bootstrapping again without `-fno-warn-overlapping-patterns -fno-warn- incomplete-patterns` when #11303 is fixed. Just to make sure that the source of the problem is really the same. I will keep you posted :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:03:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:03:21 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.1caa9dd482ecd26b6098b14359057c66@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Phab:D1676 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: => Phab:D1676 * resolution: => fixed Comment: The above patch teaches the pattern checker to run the patterns which it will check through a heuristic to determine whether it may result in the blow-up documented in this ticket. If there is a good chance things will explode the checker will run a simplified, but more performant, check. This should prevent this issue from affecting users in most cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:11:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:11:39 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.f97bf1170562ec7f9b566af0e671b05e@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:15:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:15:15 -0000 Subject: [GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode` In-Reply-To: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> References: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> Message-ID: <057.11956f0b3b9c9c1a262b5b5a6a455194@haskell.org> #11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Taking the hint from https://ghc.haskell.org/trac/ghc/ticket/11239#comment:5 I added `-fno- warn-overlapping-patterns -fno-warn-incomplete-patterns` to the compilation recipe like this: {{{ ghc -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -optP-include -optPutils/genprimopcode/dist/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -XHaskell2010 -no-user- package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -c utils/genprimopcode/./Main.hs -o utils/genprimopcode/dist/build/Main.o -fno-full-guard-reasoning -fno-warn-overlapping-patterns -fno-warn- incomplete-patterns }}} And it correctly built a `Main.o` and (subsequently on `make`) a `genprimopcode` so that I could go on bootstrapping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:16:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:16:01 -0000 Subject: [GHC] #11302: GHC HEAD uses up all memory while compiling `genprimcode` In-Reply-To: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> References: <042.b0d645817b872dc7aef66dad8b3d127c@haskell.org> Message-ID: <057.3cdc44a97a0a635e175ae1b2497874e8@haskell.org> #11302: GHC HEAD uses up all memory while compiling `genprimcode` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11303 #11239 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * related: #11303 => #11303 #11239 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 12:34:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 12:34:53 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.31f8f9b92cb353ba2c0d65f86224ab69@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Note that we need to support 7.8 and 7.10 as bootstrap compilers, so we cannot add those flags unconditionally. BTW., bootstrap is now complete and `utils/genprimopcode/dist/build/Main.o` was the only affected file. Replying to [comment:10 gkaracha]: > Great! > > Nevertheless, I am working already on fixing #11303, and I think it would be worth it to try > bootstrapping again without `-fno-warn-overlapping-patterns -fno-warn- incomplete-patterns` > when #11303 is fixed. Just to make sure that the source of the problem is really the same. I > will keep you posted :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 13:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 13:12:37 -0000 Subject: [GHC] #9614: ghc --print-(gcc|ld)-linker-flags broken In-Reply-To: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> References: <047.8a05a0d53d11d93a9d7fdc38579c7742@haskell.org> Message-ID: <062.db7ca4e297ba3ac4435272c4d4aff872@haskell.org> #9614: ghc --print-(gcc|ld)-linker-flags broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: 9421 Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"af92ef3eb9e70e59dfdc81cdb88f527c2eb82399/ghc" af92ef3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af92ef3eb9e70e59dfdc81cdb88f527c2eb82399" ghc/Main: Update list of --print modes Test Plan: Validate Reviewers: austin, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1712 GHC Trac Issues: #9614 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 13:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 13:12:37 -0000 Subject: [GHC] #11283: PatternSynonms and DisambiguateRecordFields causes panic In-Reply-To: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> References: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> Message-ID: <064.917a831d1cd6c565fd3fd10330f6b7fe@haskell.org> #11283: PatternSynonms and DisambiguateRecordFields causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T11283 Blocked By: | Blocking: Related Tickets: #9975 | Differential Rev(s): Phab:D1695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4f69203dd7892d3640e871c5914b7ee2be5f5dff/ghc" 4f69203d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4f69203dd7892d3640e871c5914b7ee2be5f5dff" Fix panic when using pattern synonyms with DisambiguateRecordFields This fixes a `find_tycon` panic when constructing a record pattern synonym when `DisambiguateRecordFields` (turned on by `RecordWildCards`) is enabled. The handling of record wild cards in such constructions isn't completely satisfactory, but doing better will require the `Parent` type to be more informative, as I'll explain on #11228. Test Plan: New test patsyn/should_compile/T11283.hs Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1695 GHC Trac Issues: #11283 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 13:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 13:12:37 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.d3d56848b62c89b5ac8b98c7ad05c415@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9975, #11283 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4f69203dd7892d3640e871c5914b7ee2be5f5dff/ghc" 4f69203d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4f69203dd7892d3640e871c5914b7ee2be5f5dff" Fix panic when using pattern synonyms with DisambiguateRecordFields This fixes a `find_tycon` panic when constructing a record pattern synonym when `DisambiguateRecordFields` (turned on by `RecordWildCards`) is enabled. The handling of record wild cards in such constructions isn't completely satisfactory, but doing better will require the `Parent` type to be more informative, as I'll explain on #11228. Test Plan: New test patsyn/should_compile/T11283.hs Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1695 GHC Trac Issues: #11283 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 13:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 13:12:37 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.d23a7b4715b73479befbc354b2489394@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8e735fd0f88454b74fbb866a59b608925a2b3e48/ghc" 8e735fd0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e735fd0f88454b74fbb866a59b608925a2b3e48" Fix GEq1 when optimizations are enabled When optimizations are enabled, primitive string literals can be inlined, which can create two copies of a string constant with different addresses. We want to avoid this behavior at all costs in the `GEq1` test, since the output depends on the result of `eqAddr#`. We prevent such inlining through use of the `{-# NOINLINE #-}` pragma. Fixes #11292. Test Plan: Validate with T11292 Reviewers: thomie, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1714 GHC Trac Issues: #11292 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 13:30:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 13:30:12 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.d98798983b47efeb0ccb93863c089d50@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.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): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While cleaning up things for the 8.0 release I noticed a TODO in `Data.Version` mentioning this ticket. My read of this discussion is that the original plan was to remove `versionTags` (at least from the `Eq` instance, if not the field itself) in GHC 7.12 (now 8.0). This has not yet happened. It would be nice to have some guidance from the Core Libraries Committee regarding what is slated to happen on this front in this release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:06:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:06:40 -0000 Subject: [GHC] #11283: PatternSynonms and DisambiguateRecordFields causes panic In-Reply-To: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> References: <049.eb004adf3b86d464fe3a3fee45a9bdef@haskell.org> Message-ID: <064.ec0e0a5eca375b2bd9ee98f9ae511f8d@haskell.org> #11283: PatternSynonms and DisambiguateRecordFields causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T11283 Blocked By: | Blocking: Related Tickets: #9975 | Differential Rev(s): Phab:D1695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:08:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:08:57 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.92cb33dbf54fc6b04bd197ca27a50f54@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: RyanGlScott, did you mean to add a `T11292` test in this diff? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:10:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:10:44 -0000 Subject: [GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex In-Reply-To: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> References: <044.1eba10cc2ab875f8ad0571288cc4efc5@haskell.org> Message-ID: <059.285b4cca6c3b5f6809022b631ae0aac6@haskell.org> #11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10726 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGIScott (removed) * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:11:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:11:00 -0000 Subject: [GHC] #11304: Programs compiled with GHC master segfault when run with +RTS -h (was: GHC master segfaults when run with +RTS -h) In-Reply-To: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> References: <046.b39239aeb6c5fbf2360a8be7625ad525@haskell.org> Message-ID: <061.d607712e077189bddcfddf9b949acc25@haskell.org> #11304: Programs compiled with GHC master segfault when run with +RTS -h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:24:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:24:54 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.ab9fab36fdebd0abbff86aa1688384e9@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: We should really get this sorted out before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 14:25:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 14:25:12 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.f38e183990f79d0538056a382710a5e6@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Not originally, but I suppose I did accidentally mention such a test in the Validation field. I should probably add a standalone test for this behavior with the proper flags always set (and possibly adjust it depending on the result of #11312). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 16:43:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 16:43:28 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.134791a3bb4d08971da626638651d050@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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 monoidal): Ad 1: The `data A = forall a. A a` syntax is enabled by `ExplicitForAll` + `GADTs` or by `ExistentialQuantification` (which implies `ExplicitForAll`). I imagine having explicit foralls is a feature separate from GADTs, so I see your point. The way I think about this is {{{ ExistentialQuantification = ExplicitForAll + existentials GADTs = GADTSyntax + EqualityConstraints + existentials }}} We could have a flag "existentials" (which would be useless without ExplicitForAll or GADTSyntax) but it does not seem to be worth it. I suggest that whenever the compiler needs to check for existentials it would check whether either `ExistentialQuantification` or `GADTs` is enabled. This way we have the equality `GADTs = ExistentialQuantification + EqualityConstraints + GADTSyntax` except that the right hand side also implies `ExplicitForAll`. Ad 3: I think making GADT pattern matches require `-XEqualityConstraints` is a step in right direction. However, the current check in `TcPat` has holes in it. For example, consider {{{ {-# LANGUAGE GADTs, MultiParamTypeClasses, FlexibleInstances #-} module X where class a ~ b => Equal a b instance Equal a a data E a b = Equal a b => E }}} {{{ module Y where import X f :: E a b -> a -> b f E x = x }}} This compiles as of current GHC, and introduces type equality in module Y without -XGADTs. (If you change the definition of `E` to `data E a b = a ~ b => E`, GHC will ask you to enable `-XGADTs`). Is this example a cheap trick or does it show a deeper problem? If we keep the check, I'd like to have a clear definition when a flag is required. Ad 4: I would prefer if the declaration was accepted with `GADTSyntax + ExistentialQuantification + EqualityConstraints`, because this way the flag `GADTs` would have clearer semantics. Otherwise we would have a distinction between `Eq :: a ~ b => Eq a b` and `Eq :: Eq a a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 17:37:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 17:37:56 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.5762a7740efc5a941bd1b5531d818860@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.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): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Let's leave it alone for 8.0 and fix it in the next release. That will give the cabal folks plenty of time to make sure it works for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 17:42:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 17:42:58 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.98ac00899f170b2965dd5af2d2025c80@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fcc76493c8b35001fc1b22738cc64ff9506e278a/ghc" fcc76493/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fcc76493c8b35001fc1b22738cc64ff9506e278a" Introduce negative patterns for literals (addresses #11303) Introduce negative patterns for literals. In addition to storing term constraints for literals (checked at the end by the term oracle), also check eagerly, using negative patterns. This means generation of smaller sets (covered, uncovered, and divergent), instead of generating big sets and pruning afterwards. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1716 GHC Trac Issues: #11303 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 19:00:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 19:00:25 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.771f8ddfeac3b6fe554ac8d39209d2b4@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 6.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): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Sounds good to me. Perhaps this should be added to the Core Library Committee's roadmap (which I seem to recall seeing at one point but am now having bit of trouble finding; perhaps we could add a few more inward- links to this page?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 19:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 19:39:56 -0000 Subject: [GHC] #11314: Documentation on const function is wrong Message-ID: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> #11314: Documentation on const function is wrong -------------------------------------+------------------------------------- Reporter: milleniumbug | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.3 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: -------------------------------------+------------------------------------- It currently only says Constant function which is not only not informative (how am I supposed to use this function, some API examples would be nice), but actually wrong (`const` is not a constant function, `const x` is) I suggest the following wording instead: Returns a unary constant function (a function that returns the same value for all inputs) from the argument @a at . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 19:41:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 19:41:58 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.26a40352049d285329210bcd81c9b4d7@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"adcbc98f50cd6bb01dfcf4c98ad5fe414f7cc40c/ghc" adcbc98f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="adcbc98f50cd6bb01dfcf4c98ad5fe414f7cc40c" Add regression test for #11303 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1719 GHC Trac Issues: #11303 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 19:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 19:47:06 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.0b22356f11805023ef990303acff4de0@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * testcase: => T11303 * differential: => Phab:D1716, Phab:D1719 * resolution: => fixed Comment: The test case now compiles in less than a second. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 19:58:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 19:58:41 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.a66795e10b3b3ff2e39987b54ba76fe5@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (CodeGen) Old description: > The program looks like this: > {{{ > module DfltProb1 where > > import Control.Monad.ST > import Prelude hiding (traverse) > > traverse :: a -> ST s [a] > traverse = undefined > > -- WORKS with signature test :: Num a => [a] > test = runST (traverse 1) > > main = print test > }}} > > This is the failure: > {{{ > $ ghc-7.11.20151225 -O DfltProb1.hs > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 7.11.20151224 for x86_64-unknown-linux): > CoreToStg.myCollectArgs > (case traverse of _ [Occ=Dead] { }) realWorld# > }}} New description: The program looks like this: {{{#!hs module DfltProb1 where import Control.Monad.ST import Prelude hiding (traverse) traverse :: a -> ST s [a] traverse = undefined -- WORKS with signature test :: Num a => [a] test = runST (traverse 1) main = print test }}} This is the failure: {{{ $ ghc-7.11.20151225 -O DfltProb1.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151224 for x86_64-unknown-linux): CoreToStg.myCollectArgs (case traverse of _ [Occ=Dead] { }) realWorld# }}} -- Comment: I believe this is fixed on `master`. I have a suspicion that this is due to d990354473239943d83ee90f8906f3737b53fe65. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 20:36:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 20:36:25 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.3dc462a741e3efc74cd041566f8386a0@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:7 heisenbug]: > Replying to [comment:5 mpickering]: > > Can you try with `-fno-warn-overlapping-patterns -fno-warn-incomplete- patterns`? > > BINGO! Doing this manually allowed me to continue bootstrapping :-) Finally #11303 is fixed! Could you please check whether it bootstraps now, without enabling `-fno-warn-overlapping-patterns -fno-warn-incomplete-patterns`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 20:43:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 20:43:30 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.b456964a084c4b3e1ea7edce64f6a0b7@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, well, the test appears to work on 6ec236b589d541e72eea8df84628206d26e93862 as well. Odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 21:06:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 21:06:07 -0000 Subject: [GHC] #11314: Documentation on const function is wrong In-Reply-To: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> References: <051.055304dc22524cc2d73ec21e7a5310cd@haskell.org> Message-ID: <066.1d3e1c187794c2b1026c251a964197e8@haskell.org> #11314: Documentation on const function is wrong -------------------------------------+------------------------------------- Reporter: milleniumbug | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1720 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * failure: None/Unknown => Documentation bug * differential: => Phab:D1720 * milestone: => 8.0.1 Old description: > It currently only says > > Constant function > > which is not only not informative (how am I supposed to use this > function, some API examples would be nice), but actually wrong (`const` > is not a constant function, `const x` is) > > I suggest the following wording instead: > > Returns a unary constant function (a function that returns the same > value for all inputs) from the argument @a at . New description: It currently only says > Constant function which is not only not informative (how am I supposed to use this function, some API examples would be nice), but actually wrong (`const` is not a constant function, `const x` is) I suggest the following wording instead: > Returns a unary constant function (a function that returns the same value for all inputs) from the argument @a at . -- Comment: Indeed, this is one of many examples where our documentation is sorely lacking. How does Phab:D1720 look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 21:32:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 21:32:21 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.467e6ecf1004fd4eb5757b763b0fa0f4@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): Replying to [comment:11 goldfire]: > `G` is inhabited at the type level, by `Any` for example. Oh, I see, right, Yet, both `Any` and `Loopy` need `UndecidableInstances`. Is there a way to inhabit `G` without enabling `UndecidableInstances`? I expect a good check to be able to handle everything anyway, I am just asking in an attempt to identify a subset of the language for which the check can have nice properties. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 23:10:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 23:10:55 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.bc284c5bd2f1fb23eae0b83a70c768e6@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): George, do you have any idea what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 29 23:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Dec 2015 23:38:37 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.8ad8524c056523ba0d6e01e1a1590e41@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:6 mpickering]: > George, do you have any idea what is going on here? I have been busy these days with #11195, #11303 and #11245 so I did not have enough time to look into it. Fortunately they are all done now so #11276 is my main priority now, I hope to have some feedback to give tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 00:38:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 00:38:01 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects Message-ID: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 the new Shake-based build system I came across an annoying problem related to missing split objects ([#note see note]). I still don't fully understand the reasons behind the problem, but I found that GHC doesn't restore missing split objects, as explained in the example below. I think this is a bug, but maybe this is actually a missing feature. I think it shouldn't be difficult to fix. {{{#!hs module Test (test) where test :: Int test = 0 }}} I compile the above with `ghc -split-objs Test.hs` and get two split object files in `Test_o_split`. Then if I delete any of these files, or even the whole folder, and rerun `ghc -split-objs Test.hs` the compiler doesn't bother to restore split objects, pretending that everything is up- to-date. However, if I delete `Test.o` all object files are restored. Another related issue reported by Neil Mitchell (which may be worth a separate ticket) is that even if we corrupt `Test.o` and rerun `ghc -split-objs Test.hs`, the compiler doesn't restore the object file (nor missing split objects) to the consistent state. ---- [=#note Note:] The problem I have is described here: https://github.com/snowleopard/shaking-up-ghc/issues/30. It's not necessary to follow the link to understand this ticket, however I'd appreciate any insight you might have about the reasons behind the problem and/or a possible solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 00:40:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 00:40:08 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.91dd5f08a36d105fa5964424d4b0f364@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Replying to [comment:6 RyanGlScott]: > I should probably add a standalone test for this behavior I don't know, but this issue is fixed. `TEST=GEq1 WAY=optasm` is passing again. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 00:58:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 00:58:55 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.f155ac2b9e23cadee8e7ea6a39b6d5b0@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Maybe you forgot `-O`, or `-fforce-recomp`. I just tried with 7.11.20151229 from https://launchpad.net/~hvr/+archive/ubuntu/ghc, and I can still reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 04:10:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 04:10:27 -0000 Subject: [GHC] #11305: Type checker regression introduced by visible type-application In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.8f69af5e30ce43092137e0472c317c9c@haskell.org> #11305: Type checker regression introduced by visible type-application -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11305 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1715 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c06b46d0313cafe05f8250a660b4481d7c1d298f/ghc" c06b46d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c06b46d0313cafe05f8250a660b4481d7c1d298f" Fix #11305. Summary: In the fallthrough case when doing a subsumption case, we need to deeply instantiate to remove any buried foralls in the "actual" type. Once this validates, please feel free to commit it; I may not have the chance to do this on Tuesday. Back in full action on Wed. Test Plan: ./validate, typecheck/should_compiler/T11305 Reviewers: austin, bgamari, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1715 GHC Trac Issues: #11305 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 04:11:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 04:11:35 -0000 Subject: [GHC] #11305: Type checker regression introduced by visible type-application In-Reply-To: <042.df96d1651596559a8340fd36e204e4be@haskell.org> References: <042.df96d1651596559a8340fd36e204e4be@haskell.org> Message-ID: <057.b7c3e5bd6f6fbda36e3edb16a425a153@haskell.org> #11305: Type checker regression introduced by visible type-application -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11305 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1715 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed Comment: Should be all set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 08:56:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 08:56:21 -0000 Subject: [GHC] #11316: Too many guards warning causes issues Message-ID: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- GHC HEAD warns if you have too many guards, for example: {{{ src/HSE/Bracket.hs:44:5: warning: Too many guards in an equation for ?needBracket? Guard checking has been over-simplified (Use: -Wno-too-many-guards to suppress this warning -ffull-guard-reasoning to run the full checker (may increase compilation time and memory consumption)) }}} The code in question is from https://github.com/ndmitchell/hlint/blob/master/src/HSE/Bracket.hs#L44 and reads: {{{#!hs needBracket i parent child | isAtom child = False | InfixApp{} <- parent, App{} <- child = False | isSection parent, App{} <- child = False | Let{} <- parent, App{} <- child = False | ListComp{} <- parent = False | List{} <- parent = False | Tuple{} <- parent = False | If{} <- parent, isAnyApp child = False | App{} <- parent, i == 0, App{} <- child = False | ExpTypeSig{} <- parent, i == 0, isApp child = False | Paren{} <- parent = False | isDotApp parent, isDotApp child, i == 1 = False | RecConstr{} <- parent = False | RecUpdate{} <- parent, i /= 0 = False | Case{} <- parent, i /= 0 || isAnyApp child = False | Lambda{} <- parent, i == length (universeBi parent :: [Pat_]) - 1 = False -- watch out for PViewPat | Do{} <- parent = False | otherwise = True }}} For code that runs with the default flags, and likes to have zero warnings (or warnings as errors), and compile with multiple GHC versions, that is problematic. How can I suppress this warning? * Adding {{{-Wno-too-many-guards}}} will only work with GHC 8, so I need to either use CPP to version select my warning suppression, or conditionality outside the compiler select the flags. * Or I can give up on detecting warnings as errors, which is a bit sad, as it's generally a useful criteria. * Or I can modify my code to make it harder to read in order to satisfy a checker whose semantics might change in future. * Or GHC could not warn on too many guards, because it's really a warning that the compiler can't cope, not that too many guards is necessarily bad. I suggest the last option, because warnings should generally be about code issues, not compiler issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:07:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:07:52 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.f04667972993d070468abcb0d1414920@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * cc: gkaracha (added) * milestone: => 8.0.1 Comment: > Or GHC could not warn on too many guards, because it's really a warning that the compiler can't cope, not that too many guards is necessarily bad. Indeed I'm quite uncertain of the right way forward here as all options are quite bad, On one hand, remaining silent in this case means that the user may rely on the compiler's pattern checker when it can't be relied upon. In passing `-Wall` to GHC, the user has requested that we provide warnings on non- exhaustive patterns. If we can't deliver on this promise it seems to me that we have a duty to ensure that the user knows this. To remain silent will mean that users may be taken by surprise when their warning-free code nevertheless crashes. For this reason I think it is quite important that a warning of this sort is available (although perhaps not enabled by default). Of course, this is made slightly trickier by the fact that pattern match checking is a hard problem and therefore will always be approximate. Moreover, before George's work we couldn't reason about guards at all. Further, even now the check necessarily breaks down completely in the face of boolean guards. Moreover, I am sympathetic to the complaint that it is too difficult to disable this warning in the presence of multiple compiler versions. == A pragma? == Our current approach to this issue, the `-Wtoo-many-guards` warning, has always been a bit of a compromise. For one, it is far too coarse-grained. In an ideal world, I would say that this flag ought to be a pragma attached to a particular binding, which would solve several problems, * someone reading or modifying the binding will be faced with a reminder that they cannot count on full pattern checking * one doesn't need to completely give up on full pattern checking in a module on account of a single large binding Unfortunately the fact that unknown pragmas are errors with `-Werror` makes this option just as inconvenient as the current flag. == A Proposal == Given the fact that guard checking is merely nice to have and will always be approximate, I tend to think we should just disable this warning by default. Hopefully for 8.2 we will have a [[https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings#ProposedChange|richer scheme]] for managing warnings, at which point we can add `-Wtoo-many- warnings` to `-Weverything`. In the meantime, we'll just need to ensure that the user's guide makes it known that the user must enable this flag if they want to be notified when the pattern checker gives up. George, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:15:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:15:30 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.12dc2248016abdbb1b5f5741a6774944@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: niteria => * status: patch => new Comment: I'm going to remove the `patch` status since all of the outstanding diffs for this ticket have been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:15:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:15:41 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.17581f76dc2271dab245b3f2b208a9bf@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => niteria -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:23:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:23:55 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.5150833a876257750abd2ff0ae3ddf97@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid not, {{{ $ inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151230 $ inplace/bin/ghc-stage2 -O DfltProb1.hs -fforce-recomp [1 of 1] Compiling DfltProb1 ( DfltProb1.hs, DfltProb1.o ) $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:37:31 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) Message-ID: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) --------------------------------------+------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: #11234 Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- On my `x86_64` Windows machine test `prog003` fails with a segfault: {{{ cd ./ghci/prog003 && ghciWayFlags=-static HC="/home/Rik/ghc/inplace/bin /ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no- user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history " "/home/Rik/ghc/inplace/bin/ghc-stage2.exe" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS prog003.run.stdout 2> prog003.run.stderr >> prog003.run.stdout 2>> prog003.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Run 1 a :: Int -> Int 168 Run 2 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 8 Segmentation fault/access violation in generated code Stderr: *** unexpected failure for prog003(ghci) }}} (I do not think it is an access violation error since when I remove [https://github.com/ghc/ghc/blob/c2fab84239299176a8e72aa26ae894019d677bd9/testsuite/tests/ghci/prog003/prog003.script#L65 line 65] and everything below line 70, the same stdout is generated.) This looks related to ticket #11234. The GHC version used was [http://git.haskell.org/ghc.git/commit/df6cb57b32d94b7f6f7c9a86207adfeee9712ed6 df6cb57b32d94b7f6f7c9a86207adfeee9712ed6], although I already noticed the problem with a version a few days older. If someone could point me to information about how to install GDB suitable for debugging GHC on my Windows machine I will try to post the stack trace. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:45:17 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.d7792a7e4bd217b154e6afcc302ebe5a@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) -------------------------------+-------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #11234 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by thomie): * cc: Phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:46:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:46:50 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.dadb6b6832aa85139864741ecaf6082d@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 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): 1. Sounds good to me. I think this is probably already the case. The "existentials" flag can be spelled `-XExistentialQuantification -XNoExplicitForAll` and it is indeed useless; here's a poor if obscure error message: {{{ Prelude> set -XExistentialQuantification -XNoExplicitForAll Prelude> data T = forall a . MkT a :3:10: Not a data constructor: ?forall? Perhaps you intended to use ExistentialQuantification }}} 3. Hmm, this is an interesting point. The current specification is something like this: `GADTs` (or `TypeFamilies`, and perhaps in the future `EqualityConstraints`) is required if pattern matching on a constructor whose context (at the type at which the pattern is being checked) directly includes a nominal equality. Here's another curious example: {{{#!hs data Dict c where MkDict :: c => Dict c f :: Dict (Int ~ Bool) -> Bool f MkDict = True -- requires GADTs g :: Dict a -> Bool g MkDict = True -- doesn't }}} I don't think we should do constraint solving to determine whether an extension is required by a pattern match. So perhaps it's better not to check at all. (But I wouldn't mind terribly if we retain the check as-is.) 4. Fair enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 11:51:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 11:51:44 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.a4123b099165932f0eaae8ca4529eafe@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) -------------------------------+-------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #11234 | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Phyx-): That's peculiar.. When I ran the tests after #11234 it was working. In anycase, making a `devel2` build should compile the RTS with symbols. Instructions for debugging are [https://ghc.haskell.org/trac/ghc/wiki/Debugging/CompiledCode?redirectedfrom=DebuggingGhcCrashes here] I will try to reproduce, thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:18:30 -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.9aafdc26f712246c7a84477b0cb3d3d5@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cocreature Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 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 cocreature): * owner: => cocreature -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:22:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:22:24 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.68bae711cd4994c91a55c1707775b755@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:12 gkaracha]: > Replying to [comment:7 heisenbug]: > > Replying to [comment:5 mpickering]: > > > Can you try with `-fno-warn-overlapping-patterns -fno-warn- incomplete-patterns`? > > > > BINGO! Doing this manually allowed me to continue bootstrapping :-) > > Finally #11303 is fixed! Could you please check whether it bootstraps now, without enabling > `-fno-warn-overlapping-patterns -fno-warn-incomplete-patterns`? Confirmed :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:32:36 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.afe628241398e59c857275c0aafe1cc8@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Note that at the moment I am not using {{{-Wall}}}, only {{{-Werror}}}, so I haven't asked for exhaustiveness checking of the guards (at least I haven't turned it on specially), so having a warning that it couldn't produce a warning I didn't even ask for seems even more dubious. Is the exhaustiveness of guards on by default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:35:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:35:09 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.85b2213974c40620271232339ad14ffa@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: #8740 => #8740, #11066 Comment: I think the right way to fix this is to make inaccessible code errors into warnings (per #11066). We could then optionally suppress them if they arise from generated code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:37:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:37:38 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.ee92e6c23115a53e8cc6e97618112822@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * related: #8128 => #8128, #8740 Comment: I'd like to see this: it would be particularly useful for code generated by standalone deriving (see related tickets). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 12:46:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 12:46:42 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.9e29de2d614ac4cac325eda7c8a5d621@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: fixed | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => closed * resolution: None => fixed * milestone: ? => 8.0.1 Comment: Great work @gkaracha! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:04:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:04:18 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.2e362b8afbbf6f3d3ead2f086eee61c0@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 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 bgamari): * milestone: 8.0.1 => 8.2.1 Old description: > Example: > > {{{ > {-# LANGUAGE GADTs #-} > module T5835 where > > data T a where > T :: Eq a => a -> T a > > foo :: a -> T a -> Bool > {-# INLINE foo #-} > foo x = \(T y) -> x == y > > appl :: (a -> b) -> a -> b > {-# NOINLINE appl #-} > appl f x = f x > > bar :: T Int -> Bool > bar t = appl (foo 42) t > }}} > > GHC generates this for `bar`: > > {{{ > bar2 :: Int > bar2 = I# 42 > > bar1 :: T Int -> Bool > bar1 = > \ (ds_dhk :: T Int) -> > case ds_dhk of _ { T $dEq_agz y_aa4 -> > == @ Int $dEq_agz bar2 y_aa4 > } > > bar :: T Int -> Bool > bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga > }}} > > Note how it want to get the `Eq` dictionary for `Int` from `T`. But we > know the `Eq Int` instance without inspecting `T` and `bar` could be > significantly simplified if we used that. New description: Example: {{{#!hs {-# LANGUAGE GADTs #-} module T5835 where data T a where T :: Eq a => a -> T a foo :: a -> T a -> Bool {-# INLINE foo #-} foo x = \(T y) -> x == y appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: T Int -> Bool bar t = appl (foo 42) t }}} GHC generates this for `bar`: {{{ bar2 :: Int bar2 = I# 42 bar1 :: T Int -> Bool bar1 = \ (ds_dhk :: T Int) -> case ds_dhk of _ { T $dEq_agz y_aa4 -> == @ Int $dEq_agz bar2 y_aa4 } bar :: T Int -> Bool bar = \ (t_aga :: T Int) -> appl @ (T Int) @ Bool bar1 t_aga }}} Note how it want to get the `Eq` dictionary for `Int` from `T`. But we know the `Eq Int` instance without inspecting `T` and `bar` could be significantly simplified if we used that. -- Comment: Looks like this won't make it for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:10:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:10:44 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.d4f3b653674a87a59b80ec1c7f1ab6cc@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:15:55 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.86774c5dee30616a8410c0b419357c47@haskell.org> #7289: Mingw FPU init not Windows compatible. -----------------------------------+----------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.2.2 Resolution: | 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 bgamari): * cc: Phyx-, simonmar (added) Comment: Phyx-, do you know whether this is still the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:18:37 -0000 Subject: [GHC] #7367: float-out causes extra allocation In-Reply-To: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> References: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> Message-ID: <060.42dca431c4313abebbf15de439d97bc2@haskell.org> #7367: float-out causes extra allocation -------------------------------------+------------------------------------- Reporter: wurmli | Owner: Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 7.6.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => Research needed Comment: As has been discussed in this ticket, GHC could in principle do better in optimizing imperative code such as this. However, exactly how this should be done is a topic that would require research. Setting the milestone appropriately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:23:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:23:39 -0000 Subject: [GHC] #5834: Allow both INLINE and INLINABLE for the same function In-Reply-To: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> References: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> Message-ID: <056.b6556c283302b77c78532e5c58d5d455@haskell.org> #5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 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 bgamari: Old description: > Sometimes you really want both. Here is a small example: > > {{{ > module T where > > foo :: Num a => a -> a -> a > foo x y = x+y+1 > }}} > > {{{ > module U where > > import T > > appl :: (a -> b) -> a -> b > {-# NOINLINE appl #-} > appl f x = f x > > bar :: Int -> Int -> Int > bar x y = appl foo x y > }}} > > If I mark `foo` as `INLINE`, then GHC generates this code for `bar`: > > {{{ > bar1 :: Int -> Int -> Int > bar1 = foo @ Int $fNumInt > > bar :: Int -> Int -> Int > bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 > x_aa0 y_aa1 > }}} > > Whereas with `INLINABLE`, we get a nice specialisation but, of course, > not guarantees with respect to inlining. > > In general, it seems that requiring a function to inline when it is > saturated and requiring it two specialise when it isn't are two different > things and shouldn't be mutually exclusive. New description: Sometimes you really want both. Here is a small example: {{{#!hs module T where foo :: Num a => a -> a -> a foo x y = x+y+1 }}} {{{#!hs module U where import T appl :: (a -> b) -> a -> b {-# NOINLINE appl #-} appl f x = f x bar :: Int -> Int -> Int bar x y = appl foo x y }}} If I mark `foo` as `INLINE`, then GHC generates this code for `bar`: {{{#!hs bar1 :: Int -> Int -> Int bar1 = foo @ Int $fNumInt bar :: Int -> Int -> Int bar = \ (x_aa0 :: Int) (y_aa1 :: Int) -> appl @ Int @ (Int -> Int) bar1 x_aa0 y_aa1 }}} Whereas with `INLINABLE`, we get a nice specialisation but, of course, not guarantees with respect to inlining. In general, it seems that requiring a function to inline when it is saturated and requiring it to specialise when it isn't are two different things and shouldn't be mutually exclusive. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:42:27 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.a0401bf31a015f93d2bfbbd3f33f98ae@haskell.org> #7289: Mingw FPU init not Windows compatible. -----------------------------------+----------------------------- Reporter: Lennart | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+----------------------------- Comment (by Phyx-): Yeah it is, and it's also unlikely to be changed as they say it's wanted behavior http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/10686. Even though it introduces some very odd/unexpected behavior https://github.com/numpy/numpy/issues/5194. It seems an easy solution/workaround is to indeed link in `CRT_fp8.o` or `CRT_fp10.o` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:48:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:48:33 -0000 Subject: [GHC] #11094: Cost-center heap profiler should be able to emit samples to eventlog In-Reply-To: <046.5020b7d3a1ba23f2949a42c6789e9133@haskell.org> References: <046.5020b7d3a1ba23f2949a42c6789e9133@haskell.org> Message-ID: <061.fb2d749816de1dc4316fae050301224c@haskell.org> #11094: Cost-center heap profiler should be able to emit samples to eventlog -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 bgamari): Here is a proposed eventlog sample format. = Event types = == Beginning of sample stream == A single fixed-width event emitted during program start-up describing the samples that follow. * `Word64`: Sampling period in nanoseconds * `Word64`: Sample break-down type. One of, * `SAMPLE_TYPE_COST_CENTER` (output from `-hc`) * `SAMPLE_TYPE_CLOSURE_TYPE` (output from `-hC`) * `SAMPLE_TYPE_RETAINER` (output from `-hr`) * `SAMPLE_TYPE_BIOGRAPHY` (output from `-hb`) * `SAMPLE_TYPE_MODULE` (output from `-hm`) * `SAMPLE_TYPE_TYPE_DESCR` (output from `-hy`) == Cost center == A variable-length packet produced once for each cost center, * `Word32`: cost center number * `Word16`: name length in bytes * UTF-8 string: name == Cost-center sample == A variable-length packet encoding a heap profile sample broken down by cost-center. Since events may only be up to 2^16^ bytes in length a single sample may need to be split among multiple events. The event shall contain packed pairs of, * `Word32`: cost center number * `Word32`: heap residency in bytes == Type description sample == A variable-length event encoding a heap sample broken down by type description. The event shall contain packed triplets of, * `Word8`; type description length in bytes * UTF-8 string: type description * `Word32`: heap residency in bytes == Closure type sample == -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 13:48:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 13:48:51 -0000 Subject: [GHC] #11094: Cost-center heap profiler should be able to emit samples to eventlog In-Reply-To: <046.5020b7d3a1ba23f2949a42c6789e9133@haskell.org> References: <046.5020b7d3a1ba23f2949a42c6789e9133@haskell.org> Message-ID: <061.2856aa940e5366608cc988caf7b10a9d@haskell.org> #11094: Cost-center heap profiler should be able to emit samples to eventlog -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 bgamari): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:01:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:01:18 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.c7fee78ee287fc6e91e2020aeb4b551b@haskell.org> #7289: Mingw FPU init not Windows compatible. -----------------------------------+-------------------------------- Reporter: Lennart | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | 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 bgamari): * status: new => upstream * milestone: 8.0.1 => 8.2.1 Old description: > Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits > (which is the standard). I suggest ghc linking on Windows should be > changed to that it uses 53 bits instead. This will make programs more > Windows compatible (and possibly faster). > > Here's a comment from Mingw's Float.h: > > /* > MSVCRT.dll _fpreset initializes the control register to 0x27f, > the status register to zero and the tag word to 0FFFFh. > This differs from asm instruction finit/fninit which set control > word to 0x37f (64 bit mantissa precison rather than 53 bit). > By default, the mingw version of _fpreset sets fp control as > per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when > building your application. > */ New description: Mingw initializes the FPU top 80 bit precision instead of MSVC's 53 bits (which is the standard). I suggest ghc linking on Windows should be changed to that it uses 53 bits instead. This will make programs more Windows compatible (and possibly faster). Here's a comment from Mingw's Float.h: {{{#!c /* MSVCRT.dll _fpreset initializes the control register to 0x27f, the status register to zero and the tag word to 0FFFFh. This differs from asm instruction finit/fninit which set control word to 0x37f (64 bit mantissa precison rather than 53 bit). By default, the mingw version of _fpreset sets fp control as per fninit. To use the MSVCRT.dll _fpreset, include CRT_fp8.o when building your application. */ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:09:34 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.e7e20f9df2b7105f366c540d4b2a40d4@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:12:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:12:56 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.60076e3901c52cee2ae9715a3530a7a6@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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): This looks very similar to #5945. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:13:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:13:13 -0000 Subject: [GHC] #5945: Lambda lifting In-Reply-To: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> References: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> Message-ID: <061.09546c4d1fcdb2c259a64f5626aa2554@haskell.org> #5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #11284 Comment: This looks very similar to #11284. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:15:18 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.74884bbddd3d0db97a1632e7cbe2e309@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Hmm, Harbormaster also fails on `TEST=DfltProb1 WAY=optasm` (and a bunch of other tests): https://phabricator.haskell.org/D1652#50905 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:38:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:38:17 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.583bb2576f4d1e8d26f936502e2a5e22@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the change from 7.10 to HEAD is an improvement, because 7.10 is illogical with regard to these shenanigans. This is accepted: {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators #-} module Parse where type family a :++: b infix 5 :++: data a :> b infix 2 :> type instance Int :++: Char :> Bool = Double }}} But in that `type instance`, the `:++:` should really bind tighter, making an instance declaration for `:>`, which is hogwash of course. So 7.10 is ignoring fixities altogether and just looking for the first operator. Better still would be Simon's suggestion, but I'm inclined to call this new behavior a feature, not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:39:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:39:22 -0000 Subject: [GHC] #11309: Warn on shady data constructor export In-Reply-To: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> References: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> Message-ID: <060.15689326a5ffa49bb62147ef5c3e569e@haskell.org> #11309: Warn on shady data constructor export -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Sounds quite sensible to me. +1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:44:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:44:26 -0000 Subject: [GHC] #11310: Surprising accepted constructor for GADT instance of data family In-Reply-To: <045.1fcd83bf1e52860605d836fed11ed5fe@haskell.org> References: <045.1fcd83bf1e52860605d836fed11ed5fe@haskell.org> Message-ID: <060.bafeddfc12d451d81b78696f6d7594e8@haskell.org> #11310: Surprising accepted constructor for GADT instance of data family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a documentation bug more than an implementation bug (or perhaps a design bug). In contrast to type families, data family results must always have kind `*`. And the variables in a data family declaration have no scope anyway (ignoring `TypeInType` stuff), so a user may usefully say {{{#!hs data family DF1 :: * -> Nat -> * }}} as equivalent to {{{#!hs data family DF2 x (y :: Nat) }}} Because type families may have higher-kinded results (that is, result kinds with arrows), type families have to distinguish between proper arguments and components of the result. Do you have an improvement to suggest, in either the design or documentation? I admit this inconsistency is quite surprising, but I don't have a better approach in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:48:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:48:30 -0000 Subject: [GHC] #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * In-Reply-To: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> References: <047.7031d20e010121f2f61831dbd5bf5d16@haskell.org> Message-ID: <062.123b9a11c000d0df6803bbe0fc659adc@haskell.org> #11311: segmentation fault/panic with -XTypeInType and functions of type * -> * -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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): There should be nothing wrong with specializing `id` to `* -> *`. `*` is a perfectly fine type that is uninhabited by terms. But clearly some part of GHC expects things of type `*` to be types. I will investigate. As for comment:1 : It would be nice to reject this without `-XTypeInType`, but arranging to snag all the things that used to be impossible is quite hard and would be rather invasive in GHC. With Simon's consultation, we decided to snag just the easy cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:52:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:52:36 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.afeedc6263ae3094c6a0117bd3a7769f@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): `Any` needs `UndecidableInstances`? I don't think it should... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 14:55:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 14:55:33 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.cf9d84198cc0accd3703c36089abf04a@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): It seems that if the final guard is {{{| otherwise}}} you could short- circuit the entire analysis pass, since we immediately know what the result is going to be. In such circumstances, emitting a warning about a failed analysis which could be trivially avoided seems unnecessary. It would also provide a simple way for users with "excessively complex" guards to disable the warning, simply add {{{| otherwise -> error "GHC can't cope with this many guards"}}}. No need for the pragma then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:08:11 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.dff0af100090c81e5c784d592cb14660@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:1 bgamari]: > Indeed I'm quite uncertain of the right way forward here as all options are quite bad, > > On one hand, remaining silent in this case means that the user may rely on the > compiler's pattern checker when it can't be relied upon. In passing `-Wall` to GHC, > the user has requested that we provide warnings on non-exhaustive patterns. If we can't > deliver on this promise it seems to me that we have a duty to ensure that the user knows > this. To remain silent will mean that users may be taken by surprise when their warning-free > code nevertheless crashes. For this reason I think it is quite important that a warning of > this sort is available (although perhaps not enabled by default). > > Of course, this is made slightly trickier by the fact that pattern match checking is a > hard problem and therefore will always be approximate. Moreover, before George's work we > couldn't reason about guards at all. Further, even now the check necessarily breaks down > completely in the face of boolean guards. > > Given the fact that guard checking is merely nice to have and will always be approximate, > I tend to think we should just disable this warning by default. I think after all I agree with this decision. By oversimplifying guards, we lose precision but the check is always reliable, in the sense that we always play on the safe side, no matter what is our choice about guards: * If a match is deemed exhaustive, it certainly is * If a clause is deemed redundant, it certainly is * If a clause is deemed to have inaccessible RHS, the RHS is certainly inaccessible I summary, this means that by oversimplifying guards, we simply increase the possibility for: * Detecting less matches as exhaustive * Detecting less clauses as redundant * Detecting more clauses as with inaccessible RHS instead of redundant (safe side in terms of laziness) The part of the check that is bit more than the rest with guard simplification is coverage checking: It is less likely to see that something is redundant if guards are oversimplified, but this is something we can live with I think. Hence, I also vote for turning `-Wtoo-many-guards` off by default if you feel that makes GHC too chatty. Replying to [comment:2 NeilMitchell]: > Note that at the moment I am not using {{{-Wall}}}, only {{{-Werror}}}, so I haven't asked > for exhaustiveness checking of the guards (at least I haven't turned it on specially), so > having a warning that it couldn't produce a warning I didn't even ask for seems even more > dubious. Is the exhaustiveness of guards on by default? Ah, I see. By default, GHC has `-fwarn-overlapping-patterns` (coverage checking) enabled. Hence, even without `-Wall`, the checker will run (but only print warnings about redundant or clauses with inaccessible right hand side). About the guards, there is a misconception in general: They are not something special that the checker can completely drop. The only thing a check can do is oversimplify (like the old checker used to do -- and that's why we would get all these wrong messages) but never drop: A guard that might fail makes the clause in question not total so we cannot just say "forget about the guard", one way or the other, a guard changes the semantics of pattern matching and has to be reasoned about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:15:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:15:44 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.e20c231908d07fd950d5034c3c540bdd@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:3 NeilMitchell]: > It seems that if the final guard is {{{| otherwise}}} you could short- circuit the entire analysis pass, since we immediately know what the result is going to be. In such circumstances, emitting a warning about a failed analysis which could be trivially avoided seems unnecessary. It would also provide a simple way for users with "excessively complex" guards to disable the warning, simply add {{{| otherwise -> error "GHC can't cope with this many guards"}}}. No need for the pragma then. Hmmmm, I disagree with this: The check is not about exhaustiveness only but also about coverage (redundancy) checking, which is by the way the **expensive** part (both problems are NP-Hard but coverage checking appears to trigger exponential behaviour much more often). Hence, having an `otherwise` means that the check is exhaustive but it does not mean that everything is useful: {{{#!hs len x | [] <- x = 0 | (_:ys) <- x = 1 + len ys | otherwise = error "can't happen" }}} Of course the above is exhaustive but it would be nice to see that the last guard is redundant. Since we cannot see that a specific guard is redundant (we can only check for redundant clauses), I see your point. But in principle I always think about coverage/exhaustiveness inseparably. Additionally, in terms of the implementation, I would not like to have so many "special cases", because it becomes really fast unintuitive for the user. What I mean is that I would prefer the warning about too many guards to appear or not independently of the existence of the `otherwise` clause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:18:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:18:59 -0000 Subject: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD In-Reply-To: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> References: <048.2f54d88a7743cd243f673a2a4bc7aa48@haskell.org> Message-ID: <063.360092bba5b58c4fc539a6f212c73c13@haskell.org> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11303 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:13 heisenbug]: > Confirmed :-) Great, one less thing to worry about, thank you very much! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:29:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:29:36 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.a7e94daf059fa83183f114dea2392f8f@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Understood about coverage and exhaustiveness, that makes sense. As long as in default mode the warning doesn't pop up, I'm happy. However, there are some people that always run with {{{-Wall}}}, and if that also turns on {{{-Wtoo-many-guards}}} then these people are going to be left with the nasty set of choices above. In general, introducing warnings that cannot be suppressed by refactorings that improve the code is something I dislike. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:46:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:46:05 -0000 Subject: [GHC] #11318: Data.Text.length allocates one closure per character Message-ID: <046.fe58c0222bbdae65d2f7b2b592abbbca@haskell.org> #11318: Data.Text.length allocates one closure per character -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #11284 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #11284 I noticed that `map Data.Text.length` applied to a list of `Text` values would result in code which would allocate one closure per character due to lack of lambda lifting. It turns out it's even worse than this. Consider this example (inspired by #11284), {{{#!hs module Hi2 (hello) where import qualified Data.Text as T hello :: Int hello = T.length hi hi :: T.Text hi = T.pack "hello" }}} When compiled with GHC 7.10.3 with `-O`, the following simplified Core is produced, {{{#!hs hello :: Int hello = case unpackCString# "hello"# of _ { Text dt_a33D dt1_a33E dt2_a33F -> let { a_a33C :: Int# a_a33C = +# dt1_a33E dt2_a33F } in letrec { $wloop_length_s3bt :: Int# -> Int# -> Int# $wloop_length_s3bt = \ (ww_s3bk :: Int#) (ww_s3bo :: Int#) -> case tagToEnum# @ Bool (>=# ww_s3bo a_a33C) of _ { False -> case indexWord16Array# dt_a33D ww_s3bo of r#_a35n { __DEFAULT -> case tagToEnum# @ Bool (geWord# r#_a35n (__word 55296)) of _ { False -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 1); True -> case tagToEnum# @ Bool (leWord# r#_a35n (__word 56319)) of _ { False -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 1); True -> $wloop_length_s3bt (+# ww_s3bk 1) (+# ww_s3bo 2) } } }; True -> ww_s3bk }; } in case $wloop_length_s3bt 0 dt1_a33E of ww_s3bs { __DEFAULT -> I# ww_s3bs } } }}} Even this simple example produces a `length` function which allocations -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 15:48:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 15:48:26 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.000c05350a3909390f40e5f82e65f056@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5945, #11318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #5945, #11318 Comment: It turns out that even just `Data.Text.length` along allocates. See #11318. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 16:02:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 16:02:11 -0000 Subject: [GHC] #10116: Closed type families: Warn if it doesn't handle all cases In-Reply-To: <049.356115fff338ba416dd9590b8ce78129@haskell.org> References: <049.356115fff338ba416dd9590b8ce78129@haskell.org> Message-ID: <064.819fd9cf125e848163155f7c71a9d3d5@haskell.org> #10116: Closed type families: Warn if it doesn't handle all cases -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 gkaracha): Replying to [comment:13 goldfire]: > `Any` needs `UndecidableInstances`? I don't think it should... Oops, sorry, my mistake, `Any` does not need `UndecidableInstances`! I had a different implementation of `Any` in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 16:07:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 16:07:56 -0000 Subject: [GHC] #11309: Warn on shady data constructor export In-Reply-To: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> References: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> Message-ID: <060.a98bb19b87b0375413ec2a2562337c91@haskell.org> #11309: Warn on shady data constructor export -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't understand the situation where this warning would be useful. If you want to export all the constructors then can you not use a wildcard? If this warning is implemented and turned on by -Wall then is there any way to export some constructors warning free? It seems to me the only situation where you explicitly list the constructors is when you don't want to export them all. Maybe there is a better example to do with data families which I am missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 16:18:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 16:18:30 -0000 Subject: [GHC] #11309: Warn on shady data constructor export In-Reply-To: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> References: <045.02c07a2144ad7ca4e21e646e40821fb2@haskell.org> Message-ID: <060.34606ba47a710cbc8213fc280c676e7a@haskell.org> #11309: Warn on shady data constructor export -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 mpickering]: > I don't understand the situation where this warning would be useful. If you want to export all the constructors then can you not use a wildcard? If this warning is implemented and turned on by -Wall then is there any way to export some constructors warning free? It seems to me the only situation where you explicitly list the constructors is when you don't want to export them all. > > Maybe there is a better example to do with data families which I am missing. You might want to avoid a wildcard so people reading the module header will see all the exported names. I would argue that it's highly unusual to want to export only some constructors. Generally, you either want to keep the type abstract or to expose it fully. Can you think of a solid reason for exporting only some constructors? As for turning warnings off, every existing warning flag has `-fno-warn-...`. This would be no different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 16:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 16:53:10 -0000 Subject: [GHC] #11318: Data.Text.length allocates one closure per character In-Reply-To: <046.fe58c0222bbdae65d2f7b2b592abbbca@haskell.org> References: <046.fe58c0222bbdae65d2f7b2b592abbbca@haskell.org> Message-ID: <061.3bc487febfc284ea5d134991a77a59d6@haskell.org> #11318: Data.Text.length allocates one closure per character -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: The premise of this ticket is totally wrong: we aren't allocating one closure per character, we are allocating one closure per call. This is totally reasonable. Apologies for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 17:19:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 17:19:15 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.01f5d5ef332d899f8ace21b246feab8a@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): The problem is, even though `A_o_split` is supposed to be considered output of compilation, the recompilation checkers for `--make` and `-c` (the ones that determine if the source is modified) only look at the merged `o` file (not the split objects) to see if they've gone away. Distressingly, in the current scheme, it is unobvious whether or not a split object directory is complete or not. So this suggests that we have to atomically output some digest describing all of the split objects we expect to see. Recompilation avoidance, when running in split objects mode, checks to see if the digest is newer than the source file, and that all the files in the digest exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:17:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:17:41 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.eaf947821d28a7e21db23232c610d941@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 6.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): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): https://prime.haskell.org/wiki/Libraries/Proposals contains the current set of actively worked on proposals. It currently focuses on things that affect Prelude at the moment, but we can broaden the mandate of the page to cover more API changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:34:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:34:24 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.c4c34e3106e7243ec55fefb172027b6c@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:"bb7f2e33197e667eb694bd1243f125c722a0a868/ghc" bb7f2e33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb7f2e33197e667eb694bd1243f125c722a0a868" Address #11245: Ensure the non-matched list is always non-empty When there is an uncovered vector of length 0 (which in turn means that it represents a guard failure) print "(incomplete guards)" instead of an empty list of non-covered vectors. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1717 GHC Trac Issues: #11245 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:37:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:37:13 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.5af987a6fe939034a8425d66f5e32919@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.4 (Linker) | Resolution: | Keywords: linker script Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 9237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:37:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:37:47 -0000 Subject: [GHC] #9237: GHC not recognizing INPUT(-llibrary) in linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.1d840a01acb34699e06757b5fa5c566e@haskell.org> #9237: GHC not recognizing INPUT(-llibrary) in linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 10046 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:38:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:38:28 -0000 Subject: [GHC] #9034: GHCi panics when given C++ object file on GNU/Linux In-Reply-To: <043.041301d73710117066e0bc737fc4c18c@haskell.org> References: <043.041301d73710117066e0bc737fc4c18c@haskell.org> Message-ID: <058.b7abba431f38f91e4c41c884bb844244@haskell.org> #9034: GHCi panics when given C++ object file on GNU/Linux -------------------------------------+------------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, | dynamic linking Operating System: Linux | Architecture: x86_64 | (amd64) 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 Wed Dec 30 18:39:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:39:58 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.ae1e89f5c293db8da16737052158d873@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 (Linker) | Keywords: panic, Resolution: | dynamic linking Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8935, #9034, | Differential Rev(s): #9074, #9278 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 18:41:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 18:41:00 -0000 Subject: [GHC] #8238: Implement unloading of shared libraries In-Reply-To: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> References: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> Message-ID: <062.67d0cf619ab98df69333930f45f41ffa@haskell.org> #8238: Implement unloading of shared libraries -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.7 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 19:58:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 19:58:14 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.2c20ab0141253971321df86099600462@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.4 (Linker) | Resolution: | Keywords: linker script Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 2615, 9237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hgolden): Replying to [comment:4 ezyang]: > hgolden, I actually am having difficulty running your script and reproducing the same output. There are two problems. First, the path that is in your example doesn't exist on my system. There are a few possible candidates: `/usr/lib/x86_64-linux-gnu/libc.so` is a linker script that has contents > > {{{ > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf64-x86-64) > GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux- gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld- linux-x86-64.so.2 ) ) > }}} My apology for not replying promptly! The library above should have the same results on your system. Please replace the library name in the `loadDLL` function with the name of any linker script on your test system. > Then, when I run the script compiled by GHC 7.6.3, I get `Nothing`. So I can't seem to coax out the Chinese output. If you are getting `Nothing` that suggests a problem with the regular expression. It should find the `/lib/x86_64-linux-gnu/libc.so.6` in the GROUP command and try to `dlopen` it. I will investigate. > BTW, in GHC 7.10 you need to initialize the object linker, otherwise it will segfault. In the past the RTS initialized the object linker when it started up. Maybe this is related to a change in that logic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 21:03:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 21:03:07 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.6bdc62699124244550497326691857c4@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 gkaracha): Henceforth, a non-exhaustiveness warning about a match for which guards are responsible (the match has no arguments so incompleteness appears due to guards not covering all possible cases), a better warning will be printed. E.g. for the example above, the warning issued will be: {{{ T11245.hs:12:7: warning: Pattern match(es) are non-exhaustive In an equation for ?a?: Guards do not cover entire pattern space }}} There is probably (probably because it is always subject to the performance cost) room for improvement, like printing more details concerning failure, but I think I can safely close this ticket now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 21:03:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 21:03:50 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.8b3a21e74158456aa10c40ba3f4696ac@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 gkaracha): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 21:17:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 21:17:21 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.0fb1c3a30693d7f6f8d2108167e6da3c@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I was hoping we could get rid of `-split-objs`, now that #8405 is implemented (function-sections). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 21:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 21:17:55 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.42ef754f0fc00bcd8766702dfea1a088@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 22:30:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 22:30:59 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.be209e74813c47ee2f5a71254c8bc142@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) ---------------------------------+---------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: GC Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: prog003 Blocked By: | Blocking: Related Tickets: #11234 #3408 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * keywords: => GC * testcase: => prog003 * architecture: x86_64 (amd64) => Unknown/Multiple * related: #11234 => #11234 #3408 Comment: This seems like it's related to #3408. The `GC` timeout `-I` is at fault. The default timeout for Windows was changed to 5secs in https://github.com/ghc/ghc/blob/master/ghc/hschooks.c#L42 to avoid issues with the `GC` and `haskeline` on Windows. Coincidentally I don't know why this was done there (which is rather hidden) rather than in `RtsFlags.c`. The helptext for RTS opts is also wrong (says the default is 0.3s for all platforms). In any case, the test is setting a value so low that it's causing a segfault. On a normal run the GC ends with {{{ Memory inventory: gen 0 blocks : 16 blocks ( 0.1 MB) gen 1 blocks : 5541 blocks ( 21.6 MB) nursery : 5379 blocks ( 21.0 MB) retainer : 0 blocks ( 0.0 MB) arena blocks : 0 blocks ( 0.0 MB) exec : 1 blocks ( 0.0 MB) free : 1411 blocks ( 5.5 MB) total : 12348 blocks ( 48.2 MB) 84f44: cap 0: all caps stopped for GC 84f44: cap 0: finished GC 84f44: exitHpc 84f44: cap 0: shutting down }}} but when it segfaults {{{ Memory inventory: gen 0 blocks : 51 blocks ( 0.2 MB) gen 1 blocks : 5470 blocks ( 21.4 MB) nursery : 5202 blocks ( 20.3 MB) retainer : 0 blocks ( 0.0 MB) arena blocks : 0 blocks ( 0.0 MB) exec : 1 blocks ( 0.0 MB) free : 3388 blocks ( 13.2 MB) total : 14112 blocks ( 55.1 MB) 84cd4: cap 0: all caps stopped for GC 84cd4: cap 0: finished GC }}} So GC does finish, but something happens between then and `exitHpc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:30:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:30:45 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) Message-ID: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Linux ImpredicativeTypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't have the latest version of GHC, trying to derive `Functor A` and `Foldable A` is fine but when I derive `Traversable A` in the attachment Error.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, DeriveTraversable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable, Traversable) }}} GHC barks at me (verbose log attached): {{{#!hs /tmp/Error.hs:8:32: error: ? Couldn't match type ?forall a1. A a1? with ?A b? Expected type: f (A b) Actual type: f (forall a. A a) ? In the expression: pure A In an equation for ?traverse?: traverse f A = pure A When typechecking the code for ?traverse? in a derived instance for ?Traversable A?: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ?Traversable A? ? Relevant bindings include f :: a -> f b (bound at /tmp/Error.hs:8:32) traverse :: (a -> f b) -> A a -> f (A b) (bound at /tmp/Error.hs:8:32) }}} With `-ddump-deriv` we get this (unqualified) instance: {{{#!hs instance Traversable A where traverse f_a2Le A = pure A }}} which by itself causes the same problem in the attachment Error2.hs: {{{#!hs {-# LANGUAGE DeriveFunctor, DeriveFoldable, ImpredicativeTypes #-} import Data.Functor (Functor) import Data.Foldable (Foldable) import Data.Traversable (Traversable) data A a = A deriving (Functor, Foldable) instance Traversable A where traverse f A = pure A }}} Works fine in GHC-7.10.2 and GHC-7.10.0.20150316 and GHC-7.4 (with some additional imports), is this an `ImpredicativeTypes` regression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:31:10 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.aec0c246e4048fc40b4ea77d2d5f7f17@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error.hs" added. Derives Traversable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:32:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:32:03 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.8379f333f1740fd20842d0a28e2f94b5@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error2.hs" added. Handwritten instance of Traversable, cleaned up output of -ddump-deriv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:32:36 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.86cb8c2514725e3e938c12b951525236@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error.log" added. ghc-7.11.20151226 -v -ignore-dot-ghci --interactive /tmp/Error2.hs &> /tmp/Error2.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:33:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:33:24 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.86cb8c2514725e3e938c12b951525236@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error.log" removed. ghc-7.11.20151226 -v -ignore-dot-ghci --interactive /tmp/Error2.hs &> /tmp/Error2.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:33:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:33:24 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.a8ddb64a24b26b857583055fffde8b8e@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error.log" added. ghc-7.11.20151226 -v -ignore-dot-ghci --interactive /tmp/Error.hs &> /tmp/Error.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:33:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:33:54 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.59ad08fc38c12a46f20ba048b16b54a7@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Error2.log" added. ghc-7.11.20151226 -v -ignore-dot-ghci --interactive /tmp/Error2.hs &> /tmp/Error2.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 30 23:35:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Dec 2015 23:35:45 -0000 Subject: [GHC] #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.242d144239145d772f0dd22d2b140d53@haskell.org> #11319: ImpredicativeTypes cause trouble (affects deriving of Traversable) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): GHCi (version 7.11.20151226) and Glasgow Haskell Compiler (version 7.11.20151226, stage 2 booted by GHC version 7.8.4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 00:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 00:33:07 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.a33231e1bb320eb576a74e38aefec0ec@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. The trouble is that the previous float-out pass transforms {{{ f = ...(case $cshowsPrec_aQi of { })... x{str=bot} = case $cshowsPrec_aQi of { } }}} into {{{ lvl = case $cshowsPrec_aQi of { } f = ...(case $cshowsPrec_aQi of { })... x{str=bot} = case $cshowsPrec_aQi of { } }}} But 'lvl' doesn't have a strictness annotation. Now CSE gets rid of `x` in favour of `lvl`. And then Lint complains when it finds a previously legitimate `(case x of {})`. I have a fix coming, that will deal with this case nicely. It just involves broadening the cases handled by `Note [Bottoming floats]` in `SetLevels`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 00:36:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 00:36:46 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.0e12cc726d1ff32a47c192b3d96da61e@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fixed? Or still to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 01:06:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 01:06:10 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual (was: ImpredicativeTypes cause trouble (affects deriving of Traversable)) In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.abcecac7cf887b9609410872467f0770@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: goldfire (added) Comment: Nothing special about deriving here, try: {{{ {-# LANGUAGE ImpredicativeTypes #-} f :: Applicative f => f (Maybe a) f = pure Nothing main = return () {- Error.hs:4:5: error: ? Couldn't match type ?forall a1. Maybe a1? with ?Maybe a? Expected type: f (Maybe a) Actual type: f (forall a. Maybe a) ? In the expression: pure Nothing In an equation for ?f?: f = pure Nothing ? Relevant bindings include f :: f (Maybe a) (bound at Error.hs:4:1) -} }}} This is with an up-to-the-minute version of HEAD, that contains the relevant-looking Phab:1715. As `ImpredicativeTypes` is unsupported anyways, perhaps we should just take the opportunity to kill it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 01:42:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 01:42:49 -0000 Subject: [GHC] #11254: GHC panic In-Reply-To: <051.76070f6fcce893e6bc75484414af761d@haskell.org> References: <051.76070f6fcce893e6bc75484414af761d@haskell.org> Message-ID: <066.d7a90aa0728b37364864c0bd716be19d@haskell.org> #11254: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11254 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Still to do. But with visible types in, I know how to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 02:55:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 02:55:58 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.286326e36b7d9f2bf2675d49706b08f7@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It would make sense that the type-checker rewrite from visible type application would break impredicativity even more than usual. Given its already-quite-broken state, I didn't try to salvage it. I don't want to completely kill it, though, as it sometimes is useful, if just for experimentation. And visible types lets you climb out of any hole you get in. For example, this works: {{{ {-# LANGUAGE ImpredicativeTypes, ScopedTypeVariables, TypeApplications #-} module Bug where f :: forall a f. Applicative f => f (Maybe a) f = pure (Nothing @a) }}} All that said, I'll take a look at this one, as it would be nice to be less broken. And my hunch is that this will be quite easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 10:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 10:25:59 -0000 Subject: [GHC] #11320: Various API Annotations fixes Message-ID: <044.2d9c92400b05655f034c6fbce09bec02@haskell.org> #11320: Various API Annotations fixes -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- - Export unicodeAnn from GHC - unicodeAnn for Annlarrowtail was wrong - Use actual source for a CImport SourceText GHC master commit: https://phabricator.haskell.org/rGHC25e4556d97429e95ddb5972f6e7e6599ef902e9c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 10:26:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 10:26:21 -0000 Subject: [GHC] #11320: Various API Annotations fixes In-Reply-To: <044.2d9c92400b05655f034c6fbce09bec02@haskell.org> References: <044.2d9c92400b05655f034c6fbce09bec02@haskell.org> Message-ID: <059.1418b2301dc5f76d7ca391ffa3bac15d@haskell.org> #11320: Various API Annotations fixes -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | ApiAnnotations 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 alanz): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 10:35:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 10:35:12 -0000 Subject: [GHC] #11321: API Annotations: AnnTilde missing Message-ID: <044.3a1a086fbb065fd006d50f6fea8a8849@haskell.org> #11321: API Annotations: AnnTilde missing -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In T10689a.hs, the fragment {{{#!hs data instance Sing (z :: [a]) = z ~ '[] => SNil | forall (m :: a) (n :: [a]). z ~ (:) m n => SCons (Sing m) (Sing n) }}} ends up with the `AnnTilde` annotations for the two tildes not attached to the final AST. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:24:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:24:45 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro Message-ID: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:#1723 | Wiki Page: -------------------------------------+------------------------------------- TODO -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:24:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:24:53 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro In-Reply-To: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> References: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> Message-ID: <057.97a026cd2d7e264d412f480902a0e8d3@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | 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): Phab:#1723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:25:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:25:06 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro In-Reply-To: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> References: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> Message-ID: <057.af72d39ce94ffd94ec467c42caed7369@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | 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): Phab:D1723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:#1723 => Phab:D1723 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:30:24 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro In-Reply-To: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> References: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> Message-ID: <057.04a9f81beb15c1f62cda97619960090a@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | 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: #9734 | Differential Rev(s): Phab:D1723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9734 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:31:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:31:51 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.6f82f2799489dc603b4df16bca4feada@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11322 | Differential Rev(s): Phab:D386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #11322 Comment: Turns out, using `YES`/`NO` as values for CPP constants is not a good idea... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 12:56:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 12:56:21 -0000 Subject: [GHC] #11260: Re-compilation driver/recomp11 test fails (was: Re-compilation tests fail on powerpc64) In-Reply-To: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> References: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> Message-ID: <062.e05cbc12d173ee484dde928008e96e77@haskell.org> #11260: Re-compilation driver/recomp11 test fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | 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: Compile-time | Test Case: performance bug | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * testcase: => driver/recomp011 * architecture: powerpc64 => Unknown/Multiple * owner: trommler => * os: Linux => Unknown/Multiple Old description: > recomp011: > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc > changed] > Linking Main ... > 4343 > +Linking Main ... > 4343 > }}} > recomp015: > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > Running main... > +Linking Main ... > Running main... > }}} New description: recomp011: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] Linking Main ... 4343 +Linking Main ... 4343 }}} -- Comment: I take it `recomp015` does not fail on ARM. In [https://gist.github.com/AlainODea/98141991849093285c52], which is a build on SmartOS, `recomp011` fails but not `recomp015`. It seems to me that the `recomp015` failure is powerpc64 specific and I will create a new ticket for it. I am disowning the ticket because it is not powerpc64 specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:03:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:03:49 -0000 Subject: [GHC] #11323: powerpc64: recomp015 fails with redundant linking Message-ID: <047.1148580a44ecdf753373d9211c559f12@haskell.org> #11323: powerpc64: recomp015 fails with redundant linking -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time Test Case: | performance bug driver/recomp15 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:27:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:27: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.17abde243562a035021847befb084dd7@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: 10458 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * blockedby: => 10458 Comment: This will be fixed as part of #10458. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:27:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:27:42 -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.4c9182ca23dac75360b0b88d0d56b766@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by trommler): * status: patch => new Comment: @simonmar did not like my hack, and he is right. Let me sit down and actually fix dynamic linking properly. My plan for a redesign of dynamic linking is (I'll add that to Trac #11238 too): 1. Use ld to generate a temporary shared object .so from an object file .o linking no other libraries at all. ELF shared objects allow undefined symbols at link time. 1. Link all temporary shared objects, Haskell libraries, and command line C libraries (in that order) into a dummy shared object. Exclude shared objects that are to be unloaded from the link. 1. Load the dummy shared object. Call this the "new" dummy shared object and call the one that was previously loaded the "old" dummy shared object. 1. Unload (dlclose) the dummy shared object. This will also unload shared objects that are to be unloaded (unless they are still referenced by other still loaded libraries). See Phab:1631 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:28:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:28:07 -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.2bcc01762663834a659e03346988ce0b@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+---------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+---------------------------------------- Changes (by trommler): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:37:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:37:46 -0000 Subject: [GHC] #10374: Can't build GHC with a dynamic only GHC installation In-Reply-To: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> References: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> Message-ID: <062.1279169eed0e82b5fac4b331f14fdcf0@haskell.org> #10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | 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 Thu Dec 31 13:39:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:39:12 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on ELF systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.a0178596535edc60220109108ed1d378@haskell.org> #10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | 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 trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:51:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:51:11 -0000 Subject: [GHC] #10761: GHC panic when compiling vimus: failed to map segment from shared object In-Reply-To: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> References: <044.348040be7af1c5ddfaac6540d862ffb8@haskell.org> Message-ID: <059.e8f8e4767cf27c6c62eedd452de96aed@haskell.org> #10761: GHC panic when compiling vimus: failed to map segment from shared object -------------------------------------+------------------------------------- Reporter: haasn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 13:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:52:18 -0000 Subject: [GHC] #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS In-Reply-To: <047.e4f44909e905adacb4005302519ba187@haskell.org> References: <047.e4f44909e905adacb4005302519ba187@haskell.org> Message-ID: <062.314eeb0e619ce537b36338d249875e67@haskell.org> #9825: ghc "panic! (the 'impossible' happened)" building vimus on NixOS --------------------------------------------+----------------------------- Reporter: jzellner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System (Linker) | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time 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 Thu Dec 31 13:55:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 13:55:14 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic In-Reply-To: <051.41ace47270d90cc9e836ab3706638147@haskell.org> References: <051.41ace47270d90cc9e836ab3706638147@haskell.org> Message-ID: <066.9e368cd3803480238799df571cf86ba5@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 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 trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:05:08 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.0411cf491bcca331ce985d30178b74e5@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | 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 Thu Dec 31 14:10:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:10:13 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.d71b94c3d0222428ff65c127166dff9e@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:11 nomeata]: > > To load a static library we use the RTS linker and the RTS linker needs to load dependent C libraries explicitly. Unfortunately we cannot assume that the C library with a specific version is installed. So the RTS linker looks for the unversioned library and tries to load that. > > BTW, why is that? Is it a valid and supported use case to build against one version and run against another version of the library? You don't have to recompile for say a security fix in a shared library. The official GHC binaries are build against a certain version of the standard C library (libc) but generally work with a newer libc as long as it is binary compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:21:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:21:20 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.cb26e699e45201a21dabd5816931f0a3@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: simonmar (added) Comment: How about this for a fix in the static case: 1. Prepare a dummy shared library `libHSC.so` at build time where we use `ld` to deal with finding the right shared libraries. If the package depends on more than one C library still only one dummy shared library needs to be created. 2. Install the dummy shared library with the static library `libHS.a` 3. Teach RTS linker to load the dummy shared library to satisfy C dependencies. I can look into this after #10458. CC'ing @simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:23:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:23:18 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.05dd94ed88349270f5a26bbb97d7d699@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 10458 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * blockedby: => 10458 Comment: The dynamic case will be fixed by #10458. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:30:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:30:26 -0000 Subject: [GHC] #8396: cleanup / refactor native code gens In-Reply-To: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> References: <045.aa7cf1c57555c9884c0054e57028458c@haskell.org> Message-ID: <060.72dc7062ada3c648086696c0c02f3721@haskell.org> #8396: cleanup / refactor native code gens -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (NCG) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8299 , #8287 | Differential Rev(s): ,#8272 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:36:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:36:39 -0000 Subject: [GHC] #9237: GHC not recognizing INPUT(-llibrary) in linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.702f0932d97556d81cbb0b08c39ef126@haskell.org> #9237: GHC not recognizing INPUT(-llibrary) in linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.8.2 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: 9498, 10458 | Blocking: Related Tickets: #2615, #10046 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * related: 2615, 10046 => #2615, #10046 * blockedby: => 9498, 10458 Comment: Replying to [comment:10 hgolden]: > > I still would like to avoid incurring dependencies on `.so`s that are really linker scripts, if possible... > > I don't see any way to avoid this unless we find a way to call `ld` as a helper. Doing this would be way beyond my level of understanding. I think this could be solved by my proposal in #9498 in the static case and #10458 in the dynamic case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:45:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:45:19 -0000 Subject: [GHC] #11324: Missing Kind Inference Message-ID: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> #11324: Missing Kind Inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The following example doesn't compile, but I expected it to. {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, ScopedTypeVariables, KindSignatures, PolyKinds, DataKinds, FlexibleInstances, UndecidableInstances, TypeFamilies #-} module Test where data Proxy a data Tagged t s = Tag s type family CharOf fp :: k class Reflects (a :: k) where value :: Proxy a instance Reflects (a :: Bool) type MyConstraint (x :: Bool) = (x~x) foo :: forall fp . (MyConstraint (CharOf fp)) => Tagged fp Int foo= let x = value::Proxy (CharOf fp) in Tag 2 }}} The error in 7.10.2 (unable to test with HEAD) is `Could not deduce (Reflects k (CharOf k fp)) arising from a use of ?value?`, basically that it was unable to figure out the kind of `CharOf fp`. I think GHC should know the kind from the constraint on `foo`. I've found two workarounds: {{{ foo :: forall fp . (MyConstraint (CharOf fp)) => Tagged fp Int foo= let x = value::Proxy (CharOf fp :: Bin) in Tag 2 }}} and {{{ foo :: forall fp x . (MyConstraint x, x~CharOf fp) => Tagged fp Int foo= let x = value::Proxy x in Tag 2 }}} but both seem unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:45:32 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.6a0065b430d202f1110a3fabfc591868@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 Simon Peyton Jones ): In [changeset:"70eefbc21649b11cd0ea1b779df316fc93d84a59/ghc" 70eefbc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="70eefbc21649b11cd0ea1b779df316fc93d84a59" Test Trac #11245 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:45:32 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.333af441f73123c2202a699ecc752ec0@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0579fe99b933384172d19beb6a00dc8a1238101a/ghc" 0579fe9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0579fe99b933384172d19beb6a00dc8a1238101a" Improve exprIsBottom This fixes Trac #11290, by being sligthtly cleverer about finding what expressions are bottom. Actually this might have minor other side benefits. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:48:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:48:30 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.016b506f92f1ed4e7173809d7e8cfe05@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) 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 Thu Dec 31 14:49:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:49:33 -0000 Subject: [GHC] #11245: Non-exhaustive pattern, "Patterns not matched" list is empty In-Reply-To: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> References: <043.770c7e4cb176531fc64456b7da5c91c9@haskell.org> Message-ID: <058.80a92a0d8a80c56bd8c48cb702b63bba@haskell.org> #11245: Non-exhaustive pattern, "Patterns not matched" list is empty -------------------------------------+------------------------------------- Reporter: osa1 | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | pmcheck/should_compile/T11245 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => pmcheck/should_compile/T11245 Comment: Good. But always add a regression test and fill in the "Test case" field of the ticket. I've done this for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 14:51:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 14:51:54 -0000 Subject: [GHC] #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** In-Reply-To: <045.dcc3b755524fc239874d7187491be2de@haskell.org> References: <045.dcc3b755524fc239874d7187491be2de@haskell.org> Message-ID: <060.b7579c16e07cb0a414ae12964cb48562@haskell.org> #11290: T6031: *** Core Lint errors : in result of Common sub-expression *** -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T6031, | deriving/should_run/T7931 (WAY=hpc) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:07:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:07:57 -0000 Subject: [GHC] #11324: Missing Kind Inference In-Reply-To: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> References: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> Message-ID: <062.821656135236a76ffef01636b66b0f4c@haskell.org> #11324: Missing Kind Inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 rwbarton): * status: new => closed * resolution: => invalid Comment: > I think GHC should know the kind from the constraint on `foo`. The kind of what? Since `CharOf` is polykinded in its result kind, there could be two different instances {{{ type instance CharOf T = True -- really "type instance CharOf Bool T = True" type instance CharOf T = () -- really "type instance CharOf * T = ()" }}} The occurrence of `CharOf fp` in `MyConstraint (CharOf fp)` must have kind `Bool`, because that is the kind that `MyConstraint` takes. But there is no reason why the subsequent occurrence of `CharOf fp` must have the same kind. This is illustrated by your two working examples. In the first one, `Bin` is not `Bool`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:11:33 -0000 Subject: [GHC] #11324: Missing Kind Inference In-Reply-To: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> References: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> Message-ID: <062.844c948170def7da0bc952153612e194@haskell.org> #11324: Missing Kind Inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 crockeea): Erp, the `Bin` is a typo, it was supposed to be `Bool`. But surely the two type instances you gave conflict? That's what GHC tells me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:14:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:14:55 -0000 Subject: [GHC] #11122: Ambiguous inferred type causes a panic In-Reply-To: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> References: <049.1088c8ba6b56b1d64805be5246c7971a@haskell.org> Message-ID: <064.05dc97d020a144f20c393bb1c704ceeb@haskell.org> #11122: Ambiguous inferred type causes a panic -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_fail/T11122 Blocked By: | Blocking: Related Tickets: #10615 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => partial-sigs/should_fail/T11122 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:21:08 -0000 Subject: [GHC] #11324: Missing Kind Inference In-Reply-To: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> References: <047.c9eb250ab1271b96797cfbf3a6dfee94@haskell.org> Message-ID: <062.bbbb40c4279bb74795481c75bb3cf7f7@haskell.org> #11324: Missing Kind Inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 rwbarton): No, they don't conflict, because they have different (non-overlapping) arguments, when the implicit kind parameter of `CharOf` is taken into account. It's easy to think that `type family CharOf fp :: k` means the kind of the result of `CharOf` depends on the type `fp` in some unspecified way. But actually, it means there is a type `CharOf fp` of kind `k` for *every* pair `fp`, `k`. (Much like a function of type, say, `Int -> t` produces any type `t` of the caller's choice, not a type of the function's own choice.) Try this version of your program. {{{ -# LANGUAGE RankNTypes, ConstraintKinds, ScopedTypeVariables, KindSignatures, PolyKinds, DataKinds, FlexibleInstances, UndecidableInstances, TypeFamilies #-} module Test where data Proxy a data Tagged t s = Tag s type family CharOf fp :: k data T type instance CharOf T = True -- really "type instance CharOf Bool T = True" type instance CharOf T = () -- really "type instance CharOf * T = ()" class Reflects (a :: k) where value :: Proxy a instance Reflects (a :: Bool) instance Reflects (a :: *) type MyConstraint (x :: Bool) = (x~x) foo :: forall fp . (MyConstraint (CharOf fp)) => Tagged fp Int foo= let x = value::Proxy (CharOf fp :: *) -- N.B. Not Bool! in Tag 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:22:21 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.6de363f939a2c1f4c82d38ca0ea51a42@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Where is this `eqAddr#` test coming from?? It's utterly bogus to compare two strings by address. This is functional programming! I'm very uncomfortable about "fixing" this by some new delicate stuff like NOINLINE pragmas, especially as they are entirely un-explained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:28:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:28:40 -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.bec6208ddd5bf5114bc250d5409021a1@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): Anyone who uses `eqAddr#` to compare string literals is asking for trouble. Really it should be harder to do. `eqAddr#` is a respectable function, but it is NOT respectable that `"foo"# :: Addr#`. We should have `String#`, and operations to compare the strings. Meanwhile, see #8472 for a better approach to sharing string literals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:29:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:29:15 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.a4c123f3dc3236769251b1df9fbb77a5@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 simonpj): See also #11312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:33:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:33:22 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors Message-ID: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: GADTs | Operating System: Linux Architecture: x86 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [https://www.youtube.com/watch?v=6snteFntvjM A Practical Introduction to Haskell GADTs] from LambdaConf 2015, example from attachment Hole.hs: {{{#!hs {-# LANGUAGE GADTs #-} data STy ty where SInt :: STy Int SBool :: STy Bool SMaybe :: STy a -> STy (Maybe a) zero :: STy ty -> ty zero ty = case ty of SInt -> 5 SBool -> False SMaybe a -> _ }}} When running with "GHCi, version 7.11.20151226": {{{ % ghci -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.11.20151226: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: error: ? Found hole: _ :: ty Where: ?ty? is a rigid type variable bound by the type signature for: zero :: forall ty. STy ty -> ty at /tmp/Hole.hs:8:9 ? In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } ? Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) Failed, modules loaded: none. Prelude> }}} when older versions (GHCi version 7.10.2) refine the type of `_` to `Maybe a`: {{{ % ghci-7.10.2 -ignore-dot-ghci /tmp/Hole.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Hole.hs, interpreted ) /tmp/Hole.hs:12:15: Found hole ?_? with type: Maybe a Where: ?a? is a rigid type variable bound by a pattern with constructor SMaybe :: forall a. STy a -> STy (Maybe a), in a case alternative at /tmp/Hole.hs:12:3 Relevant bindings include a :: STy a (bound at /tmp/Hole.hs:12:10) ty :: STy ty (bound at /tmp/Hole.hs:9:6) zero :: STy ty -> ty (bound at /tmp/Hole.hs:9:1) In the expression: _ In a case alternative: SMaybe a -> _ In the expression: case ty of { SInt -> 5 SBool -> False SMaybe a -> _ } Failed, modules loaded: none. Prelude> }}} Regression? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:34:20 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.15a7f6c3b786ecc782ae3af795896836@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Hole.hs" added. GHC 7.11 does not refine the typed hole -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:35:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:35:10 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.5eb3c932024b13e8d3dd51606747d223@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "Hole.log" added. ghci-7.11.20151226 -v -ignore-dot-ghci /tmp/Hole.hs &> /tmp/Hole.log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 15:59:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 15:59:50 -0000 Subject: [GHC] #11325: Type of hole does not get refined after pattern matching on [GADT] constructors In-Reply-To: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> References: <051.8ec42c0e7d97d5831a3b9d77051c9cfe@haskell.org> Message-ID: <066.701e890c6639fc50d08ace61e1351c58@haskell.org> #11325: Type of hole does not get refined after pattern matching on [GADT] constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: GADTs Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I'm sure this is from the visible type application stuff. Will take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 18:06:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 18:06:29 -0000 Subject: [GHC] #11326: bindist built in docker won't install Message-ID: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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: -------------------------------------+------------------------------------- Building with https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker as follows {{{ git checkout e4cc19de4bdbccea589d41717e31d63b088a8990 git submodule update ./configure CPUS=5 ./validate }}} Thereafter {{{ tar xvf ~/mysrc/git.haskell.org/ghc/bindistprep/ghc-7.11.20151229-x86_64 -unknown-linux.tar.bz2 cd ghc-7.11.20151229 ./configure make install }}} Fails with {{{ "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/opt/ghc/7.11.20151229' '/opt/ghc/7.11.20151229/lib/ghc-7.11.20151229' '/opt/ghc/7.11.20151229/share/doc/ghc/html/libraries' 'v dyn' ghc-cabal: /home/ghc/libraries/ghc-prim/ghc-prim.cabal: does not exist }}} The path `/home/ghc/libraries/ghc-prim/ghc-prim.cabal` is the absolute path to the file in the docker file system, i.e. it is the location when the tar was constructed. Bisection log {{{ alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git checkout 5bb7fecb09f828ea41e5b5a295ea159fa405dcc5 M libraries/Cabal M libraries/primitive M libraries/unix M utils/haddock Note: checking out '5bb7fecb09f828ea41e5b5a295ea159fa405dcc5'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 5bb7fec... Export some useful GHC API functions. alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git submodule update Submodule path 'libraries/Cabal': checked out '679812d2b679af952a7c9ab45a9a3a3476874a07' Submodule path 'libraries/primitive': checked out '83d3d23d2fa1583ecd1b59464cc889924e1b5fff' Submodule path 'utils/haddock': checked out '80f2f9805b61e8cea291bae8ce22db626dc11f21' alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git bisect good Bisecting: 11 revisions left to test after this (roughly 4 steps) [c06b46d0313cafe05f8250a660b4481d7c1d298f] Fix #11305. alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git bisect bad Bisecting: 5 revisions left to test after this (roughly 3 steps) [fcc76493c8b35001fc1b22738cc64ff9506e278a] Introduce negative patterns for literals (addresses #11303) alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git bisect good Bisecting: 2 revisions left to test after this (roughly 2 steps) [e4cc19de4bdbccea589d41717e31d63b088a8990] Update Cabal submodule to latest snapshot alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git bisect bad Bisecting: 0 revisions left to test after this (roughly 1 step) [adcbc98f50cd6bb01dfcf4c98ad5fe414f7cc40c] Add regression test for #11303 alanz at alanz-laptop:~/mysrc/git.haskell.org/ghc$ git bisect good e4cc19de4bdbccea589d41717e31d63b088a8990 is the first bad commit commit e4cc19de4bdbccea589d41717e31d63b088a8990 Author: Herbert Valerio Riedel Date: Tue Dec 29 22:19:54 2015 +0100 Update Cabal submodule to latest snapshot :040000 040000 9ba8cf17f85a186265761f3f1e4a11c809d0a54f 7cec7703b483a73f07d2414b364e0f3923970b1f M libraries }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 18:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 18:12:06 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.6b8e108bb24e60f408ee6e88c62ce638@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 bgamari): For the record, this commit bumped `Cabal` from `679812d2b679af952a7c9ab45a9a3a3476874a07` to `072e4728079e6caf521339e3934e1279aa09e83d`. Thankfully there aren't too many commits between these points. What looks particularly suspicious is the `Cabal` commit {{{ commit f907f1a6b4241ab4b75eaafa2ffb9031de8f008a Author: Edward Z. Yang Date: Thu Dec 24 21:56:28 2015 -0800 Canonicalize path to Cabal file, partially towards #2994. }}} alanz, perhaps you could see if the issue is fixed if you revert this one commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 18:12:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 18:12:21 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.2672a1cc29192819a9f61c5a68fea5c4@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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 bgamari): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 18:12:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 18:12:30 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.619adad680ce2708ebcb537bd6b4c447@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Installing GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 18:29:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 18:29:51 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.1f3960166da60eb4bcbccb1de1aadd11@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This commit in question canonicalizes the Cabal file path and saves it in `LocalBuildInfo` in an effort to fix [https://github.com/haskell/cabal/issues/2994|#2994]. Perhaps `ghc-cabal` should be working around this by relativizing the Cabal file path in `LocalBuildInfo`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 19:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 19:12:33 -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.abb2f1e2ef9954d44011bce4741ad6b6@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Changes (by hgolden): * cc: hgolden (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 19:14:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 19:14:43 -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.b472f35794ee70f7c8499fe39b3b713f@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) -------------------------------+----------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: 9237, 9498, 11042 Related Tickets: | Differential Rev(s): Phab:D1631 Wiki Page: | -------------------------------+----------------------------------------- Comment (by hgolden): Replying to [comment:29 trommler]: > See Phab:1631 for details. The link above doesn't work. Phab:D1631 is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 20:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 20:38:58 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.1ad43332d63a8be9a5d68f03e5b37896@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: Looks like @gridaphobe fixed this in {{{ commit 380b25ea4754c2aea683538ffdb179f8946219a0 Author: Eric Seidel Date: Wed Dec 23 10:10:04 2015 +0100 Allow CallStacks to be frozen }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 20:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 20:40:06 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.33f308552ca1a8066851d7aa85269dd3@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Was fixed by changeset:e9ab6d5939014e11b4f9368984f991de4d4cf041 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 20:42:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 20:42:50 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.79b57fa1e56b87f74d853488673e942b@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 20:45:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 20:45:57 -0000 Subject: [GHC] #11277: Undeclared `CCS_MAIN` in unregisterised build In-Reply-To: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> References: <044.86c2b3fd112a59449a7df99d91ec5022@haskell.org> Message-ID: <059.e92033ed9b74acb7ac5ec53e9f43e675@haskell.org> #11277: Undeclared `CCS_MAIN` in unregisterised build -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): While at it changeset:75851bf930067ae7c57bee3c6feea456534eafed also needs a merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:27:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:27:55 -0000 Subject: [GHC] #11326: bindist built in docker won't install In-Reply-To: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> References: <044.10c5572ceb6d6413779342d381abf3a1@haskell.org> Message-ID: <059.7053d36d210bcb7c06e3a9212d98345c@haskell.org> #11326: bindist built in docker won't install -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I reverted it: https://github.com/haskell/cabal/commit/bf4d05efa79a41a819e3d9278d5e9e1e5a055ce7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:41:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:41:51 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro In-Reply-To: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> References: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> Message-ID: <057.63aefb0bf217214fb20d41e6a761275e@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | 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: #9734 | Differential Rev(s): Phab:D1723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"eae40e16a0933fe3b6cb0ee4dc9cdbe3d21e44ce/ghc" eae40e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eae40e16a0933fe3b6cb0ee4dc9cdbe3d21e44ce" Use 0/1 instead of YES/NO as `__GLASGOW_HASKELL_TH__` macro value Using `YES`/`NO` causes all sorts of problems as CPP doesn't work on symbolic tokens but rather on scalar values. A use like #if __GLASGOW_HASKELL_TH__==YES {-# LANGUAGE TemplateHaskell #-} #endif doesn't do what one may naively expect, and neither does #if __GLASGOW_HASKELL_TH__ {-# LANGUAGE TemplateHaskell #-} #endif *unless* `YES` happens to evaluate to a non-zero scalar. `__GLASGOW_HASKELL_TH__ was originally introduced via D396 / #9734. Fixes #11322 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1723 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:41:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:41:52 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.f0031a298b6418988e30b2a05e6579ab@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11322 | Differential Rev(s): Phab:D386 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"eae40e16a0933fe3b6cb0ee4dc9cdbe3d21e44ce/ghc" eae40e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eae40e16a0933fe3b6cb0ee4dc9cdbe3d21e44ce" Use 0/1 instead of YES/NO as `__GLASGOW_HASKELL_TH__` macro value Using `YES`/`NO` causes all sorts of problems as CPP doesn't work on symbolic tokens but rather on scalar values. A use like #if __GLASGOW_HASKELL_TH__==YES {-# LANGUAGE TemplateHaskell #-} #endif doesn't do what one may naively expect, and neither does #if __GLASGOW_HASKELL_TH__ {-# LANGUAGE TemplateHaskell #-} #endif *unless* `YES` happens to evaluate to a non-zero scalar. `__GLASGOW_HASKELL_TH__ was originally introduced via D396 / #9734. Fixes #11322 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1723 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:41:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:41:52 -0000 Subject: [GHC] #8182: Parser.y.pp needs special treatment with -fcmm-sink In-Reply-To: <052.36ec4d841d9cf929e03889e8e8c83b25@haskell.org> References: <052.36ec4d841d9cf929e03889e8e8c83b25@haskell.org> Message-ID: <067.7055689ecd739e8a89f82a82fd4cef23@haskell.org> #8182: Parser.y.pp needs special treatment with -fcmm-sink -------------------------------------+--------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Build System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"37945c1db2f893657c1e3b9b26704cbf3ef27a5a/ghc" 37945c1d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37945c1db2f893657c1e3b9b26704cbf3ef27a5a" Simplify -fcmm-sink handling for Parser.hs As we're requiring GHC >= 7.10 now, the conditional handling introduced in 9e133b9dccec0553c6ec302d6ca0d3bc5eea06c4 for addressing #8182 can be made unconditional, and thus simplify the build-system a little bit. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:57:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:57:24 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.605fb6cbce192b89bb7f89bf75a56d4f@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | 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 ezyang): I gave some bogus numbers, because the build system did not inform me that SplitSections doesn't actually do anything on Linux yet. So someone will have to do this test on Mac OS X and tell us what the difference is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 21:58:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 21:58:31 -0000 Subject: [GHC] #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro In-Reply-To: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> References: <042.30d7cbad7aa7735a9439bc13340f41df@haskell.org> Message-ID: <057.87dc6e62b1f714c876aa9ac3f2348d7a@haskell.org> #11322: Dysfunctional `__GLASGOW_HASKELL_TH` macro -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9734 | Differential Rev(s): Phab:D1723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Old description: > TODO New description: see commit message -- Comment: Merged to ghc-8.0 via 39237c178f179a7e8d57e6e51e4dcd6881b97ca4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 22:30:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 22:30:21 -0000 Subject: [GHC] #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs In-Reply-To: <045.7e427084bf60386398394c8c253ebec9@haskell.org> References: <045.7e427084bf60386398394c8c253ebec9@haskell.org> Message-ID: <060.bf0f733461df77fad37ea4a1d0543928@haskell.org> #11291: DfltProb1(optasm): panic CoreToStg.myCollectArgs -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/DfltProb1 | (optasm) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I know what is happening; patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 22:49:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 22:49:29 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.9695c575dbd466a38f3f8a92f11a9f7f@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 simonpj]: > Where is this `eqAddr#` test coming from?? It's utterly bogus to compare two strings by address. This is functional programming! We have to test `eqAddr#` here because that's how `deriving Eq` deals with `Addr#`. `Addr#` is [http://git.haskell.org/ghc.git/blob/2f923ce2ab8bad6d01645c735c81bbf1b9ff1e05:/compiler/typecheck/TcGenDeriv.hs#l2194 one of six] privileged unlifted types which a datatype can have and still have a derived `Eq`/`Ord` instance. Internally, the `deriving` machinery compares `Addr#` fields in a datatype with `eqAddr#`/`ltAddr#`/etc., so this test just checks to see if GHC generics is equally as expressive. > I'm very uncomfortable about "fixing" this by some new delicate stuff like NOINLINE pragmas, especially as they are entirely un-explained. I'm inclined to agree, but if we do fix this, we'd probably need to change the way `Addr#` is dealt with in datatypes as well for the sake of consistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 23:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 23:26:54 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.5484963c65510c6c9f6d2268f6061612@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm inclined to agree, but if we do fix this, we'd probably need to change the way `Addr#` is dealt with in datatypes as well for the sake of consistency. No... an `Addr#` might be returned from C-land by `malloc`, and might be perfectly stable. It's just that primitive strings should not be compared with `eqAddr#`. The bug is that primitive strings have type `Addr#`; they should have type `String#`. And to compare `String#` you should use `strcmp`. I suppose that means a new primitive type and family of operations over it... but that looks to me like the Right Thing to do. This NOINLINE stuff looks desperately fragile.... a bug waiting to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 31 23:27:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 31 Dec 2015 23:27:45 -0000 Subject: [GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing In-Reply-To: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> References: <045.cdc6af1926cd16aa35393da7e2fb5cc9@haskell.org> Message-ID: <060.c13eeb6abe5fe2919f6723fe44f11b74@haskell.org> #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11312 | Differential Rev(s): Phab:D1714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm inclined to agree, but if we do fix this, we'd probably need to change the way `Addr#` is dealt with in datatypes as well for the sake of consistency. No... an `Addr#` might be returned from C-land by `malloc`, and might be perfectly stable. It's just that primitive strings should not be compared with `eqAddr#`. The bug is that primitive strings have type `Addr#`; they should have type `String#`. And to compare `String#` you should use `strcmp`. I suppose that means a new primitive type and family of operations over it... but that looks to me like the Right Thing to do. This NOINLINE stuff looks desperately fragile.... a bug waiting to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 03:15:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 03:15:51 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.e7bd9245fe2afe75b981b02c3f561234@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * owner: => MarcelineVQ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 18 07:30:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Dec 2015 07:30:01 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.136ee1f1f5bb3a534e24a2212314bda7@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * status: new => patch * differential: => Phab:D1650 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 11:25:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 11:25:07 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.baeb4babeee4e961efffcc34356fdcfd@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:12 hvr]: > Moreover, in the context of `-Ndiv` and `-Nsub` I consider `-Nmax` wrongly named: > It should rather be named `-Nmin` to avoid confusion: God, please no. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 19 11:27:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Dec 2015 11:27:50 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.b7a1cf6598155bf98300022432e322ab@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new * owner: MarcelineVQ => Comment: MarcelineVQ: please hold off from implementing `-Ndiv` and `-Nsub` till this syntax discussion has subsided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 21 06:13:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Dec 2015 06:13:20 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.c764fc2bc3c7614717f888ddf760d502@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * owner: => MarcelineVQ * differential: Phab:D1650 => Phab:D1650, Phab:D1677 Comment: New revision to check out, settled on -maxN and also discovered possible -m bug where it silently ignores bad opts that begin with m. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:15:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:15:59 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.86ee9a8c534e5c909bf7c5c307a216c5@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 23 09:16:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Dec 2015 09:16:06 -0000 Subject: [GHC] #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options In-Reply-To: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> References: <047.8ab1f4617aa75c3c439f322b5bb4c6f5@haskell.org> Message-ID: <062.fa5ec31ab8aa6bc56efdaa7e1359a6bb@haskell.org> #10728: Add e.g. "-N<=4" in addition to the fixed "-N4" and variable "-N" RTS options -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: MarcelineVQ Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9221, #8224 | Differential Rev(s): Phab:D1650, Wiki Page: | Phab:D1677 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler