March 2015 - ghc-tickets

[GHC] #8550: GHC builds recursive coerctions when using recursive type families
by GHC 24 Mar '15

24 Mar '15

#8550: GHC builds recursive coerctions when using recursive type families -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider {{{ {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances #-} type family F a type instance F () = F () data A where A :: F () ~ () => A x :: A x = A }}} On GHC 7.6.3 it yields a context reduction stack overflow (despite F () ~ () being put into the “solved funeqs” list). In HEAD, a recursive dictionary is built, but then detected: {{{ [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20131108 for x86_64-unknown-linux): Cycle in coercion bindings [[cobox_ayX{v} [lid] = CO main:Foo.TFCo:R:F(){tc rob}[0] ; cobox_ayZ{v} [lid], cobox_ayZ{v} [lid] = CO cobox_ayX{v} [lid] ; cobox_az0{v} [lid]]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Either this panic needs to be turned into an error, or we need to prevent recursive dictionaries for when solving funeqs (similar to how we do it for `Coercible`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #9554: Pathological type family turns type error into runtime loop
by GHC 24 Mar '15

24 Mar '15

#9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: indexed- Related Tickets: | types/should_fail/T9554 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_fail/T9554 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9554#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 24 Mar '15

24 Mar '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: indexed- at runtime | types/should_fail/T7788 Blocked By: | Blocking: Related Tickets: #8550, #10079 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => indexed-types/should_fail/T7788 * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found
by GHC 24 Mar '15

24 Mar '15

#10158: Panic compiling singletons: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `cabal install singletons` panics like this with HEAD: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.11.20150313 for x86_64-unknown-linux): StgCmmEnv: variable not found cobox_a1Job local binds for: sConst sAsTypeOf sId %:++ sMap sFoldr %$ %$! $WLet_1627796109GoSym3KindInference $WLet_1627796109GoSym2KindInference $WLet_1627796109GoSym1KindInference $WLet_1627796109GoSym0KindInference $WSeqSym1KindInference $WSeqSym0KindInference $WFlipSym2KindInference $WFlipSym1KindInference $WFlipSym0KindInference $WConstSym1KindInference $WConstSym0KindInference $WAsTypeOfSym1KindInference $WAsTypeOfSym0KindInference $WIdSym0KindInference $W:++$### $W:++$$### $WMapSym0KindInference $WMapSym1KindInference $WFoldrSym2KindInference $WFoldrSym1KindInference $WFoldrSym0KindInference $WLambda_1627796009Sym3KindInference $WLambda_1627796009Sym2KindInference $WLambda_1627796009Sym1KindInference $WLambda_1627796009Sym0KindInference $W:.$$$### $W:.$$### $W:.$### %$1 sAsTypeOf1 sConst1 sFlip1 sId1 sSeq1 a_r1JEg sF_s1JFN sG_s1JFO sA_1627796004_s1JFP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #9554: Pathological type family turns type error into runtime loop
by GHC 24 Mar '15

24 Mar '15

#9554: Pathological type family turns type error into runtime loop -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9554#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 24 Mar '15

24 Mar '15

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: #8550, #10079 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa" Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints
by GHC 23 Mar '15

23 Mar '15

#7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => ⊥ Comment: Replying to [comment:3 simonpj]: > So the status quo,in which `TypeRep`s are essentially compared by name, is looking more attractive. No one is aruging for this change. So I propose to park it for now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7897#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8556: Invalid constructor names are accepted in data declarations
by GHC 23 Mar '15

23 Mar '15

#8556: Invalid constructor names are accepted in data declarations ------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Earlier today, someone was asking on #haskell why the constructor name {{{(^)}}} wouldn't work in GADT definitions. My response was that {{{(^)}}} isn't a constructor name, but much to my surprise, GHC accepts such names in a regular data declaration: {{{ data Foo = F | (^^^^) Int Int }}} This creates a {{{Foo}}} type and value constructor {{{F}}}, but no value constructor {{{(^^^^)}}}. However, in 7.6.3, if DataKinds are enabled, both constructors appear at the type level. In HEAD, the same definition is accepted, with only {{{F}}} existing at the value level, as before. But at the type level, both {{{F}}} and {{{(^^^^)}}} just generate errors that {{{Foo}}} is not a promotable type. At that point, I think there's no question that the declaration should just be ruled out. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8556> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10179: Kinds missing from types in ghci
by GHC 23 Mar '15

23 Mar '15

#10179: Kinds missing from types in ghci -------------------------------------+------------------------------------- Reporter: br1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} data family F (a:: k) foo :: F (m :: [()]) -> a foo = undefined bar :: F (m :: [[()]]) -> a bar = undefined according to GHCi, both foo and bar have type F m -> a but [foo, bar] fails -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10179> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9194: Remove magic parsing of (~)
by GHC 23 Mar '15

23 Mar '15

#9194: Remove magic parsing of (~) ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It seems that `(~)` has magical parsing: {{{ Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint Prelude> :i (+) -- for comparison class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + }}} Now that type operators do not need to start with a colon, this magic seems unnecessary. The `(~)` syntax does not need to be wired-in, unless I'm missing something. (The ''definition'' of `(~)` needs to be wired in -- it's just the syntax that doesn't need to be.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5