- ghc-tickets - Haskell.org

[GHC] #10139: Coercible causes ghc to hang
by GHC 24 Mar '15

24 Mar '15

#10139: Coercible causes ghc to hang -------------------------------------+------------------------------------- Reporter: | Owner: nitromaster101 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider my two instance declarations. The second one will hang ghc. If I change (coerce) to (coerce :: Normal a -> Sized a) it compiles fine. The first declaration also works fine. {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} import qualified Data.FingerTree as FT import GHC.Exts class DOps a where plus :: a -> D a -> a type family D a :: * type instance D (FT.FingerTree (Size Int, v) (Sized a)) = [Diff (Normal a)] type family Normal a :: * data Diff a = Add Int a newtype Sized a = Sized a newtype Size a = Size a -- This works: instance (FT.Measured (Size Int, v) (Sized a), Coercible (Normal a) (Sized a)) => DOps (FT.FingerTree (Size Int, v) (Sized a)) where plus = foldr (\(Add index val) seq -> FT.singleton ((coerce) val)) -- This hangs: instance (FT.Measured (Size Int, v) (Sized a), Coercible (Normal a) (Sized a)) => DOps (FT.FingerTree (Size Int, v) (Sized a)) where plus = foldr (flip f) where f seq x = case x of Add index val -> FT.singleton ((coerce) val) }}} {{{ $ ~/downloads/ghc-7.10.0.20150123/out/bin/ghci --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20150123 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10185: Coercible solver incomplete with non-variable transitivity
by GHC 24 Mar '15

24 Mar '15

#10185: Coercible solver incomplete with non-variable transitivity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ import Data.Coerce import Data.Proxy foo :: (Coercible (a b) (c d), Coercible (c d) (e f)) => Proxy (c d) -> a b -> e f foo _ = coerce }}} I get an error, because GHC isn't smart enough to figure out transitivity in this case. It ''can'' do it with bare variables, but not variable applications. It's possible there's a way to do this, but we'll wait for someone to shout before investing effort. Do shout if this lack of functionality is ruining your day! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10079: Coercible solver regression: Couldn't match rep of () with Const () b
by GHC 24 Mar '15

24 Mar '15

#10079: Coercible solver regression: Couldn't match rep of () with Const () b -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, I ran into what appears to be a regression in the Coercible solver since 7.8.4. This is as small as I've managed to get my example case. {{{ {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Control.Applicative import Data.Coerce broken :: Bizarre (->) w => w a b t -> () broken = getConst #. bazaar (Const #. const ()) class Profunctor p where (#.) :: Coercible c b => (b -> c) -> p a b -> p a c class Bizarre p w | w -> p where bazaar :: Applicative f => p a (f b) -> w a b t -> f t }}} {{{ Bug.hs:10:36: Couldn't match representation of type ‘()’ with that of ‘Const () b’ Relevant role signatures: type role Const representational phantom Relevant bindings include broken :: w a b t -> () (bound at Bug.hs:10:1) In the first argument of ‘bazaar’, namely ‘(Const #. const ())’ In the second argument of ‘(#.)’, namely ‘bazaar (Const #. const ())’ In the expression: getConst #. bazaar (Const #. const ()) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[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