February 2016 - ghc-tickets

[GHC] #11542: Profiling call count frequently 0 when it shouldn't be
by GHC 17 Mar '16

17 Mar '16

#11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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's an example (lines shortened): {{{ FUNCTION MODULE CALLS addinMTypeM Cortex.Stem.Exp.Addin 212462 56309 0.0 0.0 0.1 0.0 addinMTypeM'' Cortex.Stem.Exp.Addin 212463 0 0.0 0.0 0.1 0.0 memoize Cortex.Utils.Memo 212464 0 0.0 0.0 0.1 0.0 memoizeIO Cortex.Utils.Memo 212465 0 0.0 0.0 0.1 0.0 addinMTypeM' Cortex.Stem.Exp.Addin 212467 13799 0.0 0.0 0.1 0.0 }}} Maybe I don't understand the profile info, but here is my interpretation. addinMTypeM is called 56309 times, and then it calls addinMTypeM'' 0 times, which calls memoize 0 times, which calls memoizeIO 0 times, which calls addinMType' 13799. How can a function that was called 0 times call another function 13799 times? My profile are full of the 0 entries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10075: Muddling Constraint and * means that Core is inconsistent
by GHC 17 Mar '16

17 Mar '16

#10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I can say this: {{{ type family F (a :: k) type instance F (a :: Constraint) = Int type instance F (a :: *) = Bool }}} This compiles to the following Core: {{{ F :: forall (k :: BOX). k -> * axF1 :: [a :: Constraint].F Constraint a ~ Int axF2 :: [a :: *]. F * a ~ Bool }}} I can then build the following: {{{ sym axF1[Any Constraint] ; axF2[Any *] :: Int ~ Bool }}} The transitivity is sound because, in Core, `Constraint` and `*` are indistinguishable. I don't think there's a way to actually cause a bug in a running program due to this problem, but we should probably patch it up. Possible resolution: Have `coreView` change `Constraint` to `*`. Possible resolution once we have `* :: *`: Make `Constraint` and `*` representationally equal. In other words, it would be as if `Constraint` were a newtype around `*`. I haven't thought out the ramifications of this decision, but there's something nice about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10303: Make it easier to print stack traces when debugging GHC itself
by GHC 17 Mar '16

17 Mar '16

#10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As suggested in [http://mail.haskell.org/pipermail/ghc- devs/2015-February/008271.html the mailing list], GHC should have better support for printing its own stack trace when profiling is enabled. This ticket is to track progress toward this goal. There are a few moving parts: * Just having `pprTrace` use `traceStack` is a bad idea, because a profiled compiler will spew lots and lots and lots of output. Instead, I propose a new `pprTraceStack :: String -> SDoc -> a -> a`. * Currently, `ASSERT` will print a stack trace, but it's sometimes the wrong one. `ASSERT` throws an error; if this error is caught and re- thrown, the stack trace is at the re-throw. Instead, it should be at the origin. * Is it worth adding a new mode in `build.mk` that enables profiling, `DEBUG`, and `-fprof-auto`, just to get good stack traces? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9803: Poor error message for unbound variable in pattern synonym
by GHC 17 Mar '16

17 Mar '16

#9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{ pattern OneElt = [x] }}} I get {{{ Right-hand side of bidirectional pattern synonym cannot be used as an expression [x] }}} I have two complaints with this error message: 1. It's very unclear what's actually wrong with the pattern -- `[x]` looks like a perfectly fine expression, until I realize that `x` is unbound. 2. The herald of the error is more than 80 characters (if you count the indentation) and wraps on my 80-character terminal. GHC tends to avoid this elsewhere, and so the wrapping is suboptimal. I would easily say that issue (1) is more important than issue (2). Perhaps this would be better: {{{ Variable `x' is unbound in the bidirectional pattern synonym `OneElt': [x] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8132: Warning for Typeable instances misplaced
by GHC 16 Mar '16

16 Mar '16

#8132: Warning for Typeable instances misplaced -------------------------+------------------------------------------------- Reporter: | Owner: scottgw | Status: new Type: bug | Milestone: Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- There is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which appears pretty weird to the user. {{{ #!haskell import Data.Typeable data K = K instance Typeable K where typeRep _ = undefined ex :: TypeRep ex = typeRep (undefined :: Proxy K) }}} Gives as an error: {{{ No instance for (Typeable * K) arising from a use of ‛typeRep’ In the expression: typeRep (undefined :: Proxy K) In an equation for ‛ex’: ex = typeRep (undefined :: Proxy K) }}} Which is of course surprising because the user just defined the instance. After commenting out the code that uses the instance, one gets: {{{ TypEx.hs:1:1: Warning: Typeable instances can only be derived; ignoring the following instance: instance Typeable * K -- Defined at TypEx.hs:5:10 }}} This information should clearly be somehow presented before or with the previous error if the user is to have any way to figure out what is going on. I suppose this could be fixed by: 1. Turning the Typeable instance warning into an error 2. Checking the missing instance in the existing error for Typeable and suggest that the user should look for hand written instances as a source of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11642: Typechecker doesn't use evidence available from pattern synonym?
by GHC 16 Mar '16

16 Mar '16

#11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- Either that or I am missing something... Consider the following, {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} module Test where data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: TypeRep f -> TypeRep x -> TypeRep (f x) data TypeRepX where TypeRepX :: TypeRep a -> TypeRepX data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a trArrow :: TypeRep (->) trArrow = undefined eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined pattern TRFun :: forall fun. () => forall arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TypeApp (TypeApp (eqTypeRep trArrow -> Just HRefl) arg) res buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = case typeRepKind f of TRFun arg _ -> case eqTypeRep arg x of Just HRefl -> TypeRepX $ TypeApp f x }}} This fails with, {{{ $ ghc Test.hs -fprint-explicit-kinds [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:38:30: error: • Expected kind ‘TypeRep (k1 -> res) a’, but ‘f’ has kind ‘TypeRep k a’ • In the first argument of ‘TypeApp’, namely ‘f’ In the second argument of ‘($)’, namely ‘TypeApp f x’ In the expression: TypeRepX $ TypeApp f x • Relevant bindings include arg :: TypeRep * arg (bound at Test.hs:35:11) }}} That is, the typechecker doesn't believe that `f`'s type (why is it saying "kind" here?), `TypeRep k a`, will unify with `TypeRep (k1 -> res) a`, despite the `TRFun` pattern match, which should have brought into scope that `k ~ (arg -> res)`. This was tested with a recent snapshot from `ghc-8.0` (23baff798aca5856650508ad0f7727045efe3680). Am I missing something here or is this a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932
by GHC 16 Mar '16

16 Mar '16

#11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As mentioned in https://mail.haskell.org/pipermail/ghc- devs/2016-February/011455.html, the following tests currently hit an assert when the compiler is built with -DDEBUG: {{{ patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) }}} {{{ Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] }}} Phab:D1951 contained a stopgap patch, but since it wasn't accepted, I'll just mark the tests as expect_broken for this ticket, so that other developers aren't bothered by this issue. The offending commit is b5292557dcf2e3844b4837172230575d40a8917e. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11614: document TypeInType
by GHC 16 Mar '16

16 Mar '16

#11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Just to keep track of the status for 8.0.1.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11401: No match in record selector ctev_dest
by GHC 16 Mar '16

16 Mar '16

#11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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 the llvm-tf package I got the following problem: {{{ $ cat RecordSelectorCtevDest.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module RecordSelectorCtevDest where import Data.Word (Word32, ) import Foreign.Ptr (Ptr, ) newtype Value a = Value a newtype Function a = Function a newtype CodeGenFunction r a = CodeGenFunction a bind :: CodeGenFunction r a -> (a -> CodeGenFunction r b) -> CodeGenFunction r b bind (CodeGenFunction a) k = k a class (f ~ CalledFunction g, r ~ CallerResult g, g ~ CallerFunction f r) => CallArgs f g r where type CalledFunction g :: * type CallerResult g :: * type CallerFunction f r :: * call :: Function f -> g instance CallArgs (IO a) (CodeGenFunction r (Value a)) r where type CalledFunction (CodeGenFunction r (Value a)) = IO a type CallerResult (CodeGenFunction r (Value a)) = r type CallerFunction (IO a) r = CodeGenFunction r (Value a) call = undefined instance CallArgs b b' r => CallArgs (a -> b) (Value a -> b') r where type CalledFunction (Value a -> b') = a -> CalledFunction b' type CallerResult (Value a -> b') = CallerResult b' type CallerFunction (a -> b) r = Value a -> CallerFunction b r call = undefined test :: Function (IO (Ptr a)) -> Function (Ptr a -> IO Word32) -> CodeGenFunction Word32 (Value Word32) test start fill = bind (call start) (call fill) $ ghci-8.0.0.20160109 RecordSelectorCtevDest.hs GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling RecordSelectorCtevDest ( RecordSelectorCtevDest.hs, interpreted ) *** Exception: No match in record selector ctev_dest }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11401> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11407: -XTypeInType uses up all memory when used in data family instance
by GHC 16 Mar '16

16 Mar '16

#11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- Compiling this code with GHC 8.1 causes all my memory to be used very quickly: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module TypeInTypeEatsAllMemory where import Data.Kind type Const a b = a data family UhOh (f :: k1) (a :: k2) (b :: k3) data instance UhOh (f :: * -> * -> *) (a :: forall a) (b :: Const * a) = UhOh }}} On the other hand, this code compiles without issue: {{{#!hs {-# LANGUAGE TypeInType #-} module TypeInTypeEatsAllMemory where import Data.Kind type Const a b = a data UhOh (f :: * -> * -> *) (a :: forall a) (b :: Const * a) = UhOh }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11407> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7