November 2014 - ghc-tickets

[GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm
by GHC 11 Dec '14

11 Dec '14

#9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: tc124 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc-HEAD: {{{ $ make fulltest TEST="tc124" WAY=optasm =====> tc124(optasm) 3136 of 4101 [0, 0, 0] cd ./typecheck/should_compile && '/home/slyfox/dev/git/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc124.hs -O -fasm -fno-warn-incomplete-patterns >tc124.comp.stderr 2>&1 Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: In the type ‘a_12 -> a_aia -> a_aia’ @ a_12 is out of scope *** Offending Program *** Foo.g :: Foo.T -> Foo.T [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 40 30}] Foo.g = \ (t_ahr :: Foo.T) -> case t_ahr of _ [Occ=Dead] { Foo.T ds_dlB ds_dlC -> Foo.T ds_dlB (\ (@ a_ai4) (@ b_ai5) _ [Occ=Dead] (y_aht :: b_ai5) -> y_aht) } ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8240: Better error messages for type family constraints
by GHC 11 Dec '14

11 Dec '14

#8240: Better error messages for type family constraints ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- Consider this constraint {{{ F Int ~ Bool -- Arising (say) on line 5 F Int ~ Char -- Arising (say) on line 10 }}} At the moment we'll combine the two to {{{ F Int ~ Bool -- Arising on line 5 Bool ~ Char -- Arising on line 10 }}} The second of these errors is "insoluble" and is reported first. But it's totally misleading: nowhere in the program did we directly need `Int~Char`. Another variant of this came up in Trac #8227. There we get the constraint {{{ Scalar (V a) ~ t0 Scalar (V a) ~ t0 -> t0 }}} which leads to {{{ Scalar (V a) ~ t0 -> t0 t0 ~ t0 -> t0 -- Occurs check }}} which gives the confusing error {{{ T8227.hs:16:44: Occurs check: cannot construct the infinite type: t0 ~ t0 -> t0 Expected type: Scalar (V (t0 -> t0)) Actual type: Scalar (V a) }}} I think the solution is * Do not combine two Wanteds {{{ [W] F tys ~ t1 [W] F tys ~ t2 }}} unless t1 and t2 are both touchable unification variables. * Instead (perhaps) generate a Derived constraint {{{ [D] t1 ~ t2 }}} to express the fact that t1 and t2 had better end up equal. * To do this the inert set would need to contain many `CTyFunEq` constraints with the same LHS. I'm not very sure about this, and no time now, so I'm just making this ticket to record the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9569: Tuple constraints don't work right
by GHC 11 Dec '14

11 Dec '14

#9569: Tuple constraints don't work right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider this program: {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, KindSignatures, DataKinds, TypeFamilies #-} module Wrong where import GHC.Prim data Proxy (c :: Constraint) class Deferrable (c :: Constraint) where defer :: Proxy c -> (c => a) -> a deferPair :: (Deferrable c1, Deferrable c2) => Proxy (c1,c2) -> ((c1,c2) => a) -> a deferPair = undefined instance (Deferrable c1, Deferrable c2) => Deferrable (c1,c2) where -- defer p f = deferPair p f -- Succeeds defer = deferPair -- Fails }}} The first (commented-out) definition of `defer` in the instance declaration succeeds; but the second fails with an utterly bogus message {{{ ConstraintBug.hs:27:13: Could not deduce (c1 ~ (c1, c2)) from the context (Deferrable c1, Deferrable c2) }}} The reason is that when type-checking the method defintion we try to unify {{{ ((c1,c2) => a) ~ ((gamma1, gamma2) => alpha) }}} where * the LHS comes from instantiating the signature `(c => a)` (from the class decl) with `(c1,c2)/c` from the instance. * the RHS comes from instantiating the type of `deferPair` with fresh unification variables. The difficulty is that in the type of `deferPair`, the concrete syntax {{{ deferPair :: ...((c1,c2) => a)... }}} is really just syntactic sugar for {{{ deferPair :: ...(c1 => c2 => a)... }}} i.e. curried. But the function in the instantiated signature really has one constraint argument, a pair, not two. It's not clear how to fix this. It would actually be more consistent if {{{ f :: (Eq a, Show a) => blah }}} really did take a pair of dictionaries, rather than two curried dictionaries. But that would be a pretty big change, forced by a corner case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9569> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9404: tcInferRho muddies the waters
by GHC 11 Dec '14

11 Dec '14

#9404: tcInferRho muddies the waters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In trying to understand the algorithm implemented in !TcExpr, I've spent some time examining `tcInferRho`. I conjecture that this function is superfluous and should be removed, in favor of `tcInfer . tcExpr`. Some of these thoughts were first written up in [http://www.haskell.org/pipermail /ghc-devs/2014-July/005733.html this thread]. After a considerable amount of staring, I've actually found a misbehavior caused by the current implementation. `tcInferRho` calls `tcInfExpr`, which has only 3 special cases before calling `tcInfer . tcExpr`: for variables, parentheses, and application. I was first drawn into this problem because these three cases seem woefully insufficient for the problem at hand. I was surprised how such a paucity of cases could have survived without causing havoc, if indeed `tcInferRho` were necessary at all. For example, only normal (prefix) application is handled; infix application is missing. In looking at differences between `tcInferApp` (which is called from the application case of `tcInfExpr`) and `tcApp` (called from `tcExpr`), I saw that the former doesn't have a special case for `seq` while the latter does. And, indeed, this difference is exploitable. This compiles fine: {{{ foo _ = case () `seq` (# #) of (# #) -> () }}} This does not: {{{ foo _ = case seq () (# #) of (# #) -> () }}} which produces {{{ Scratch.hs:15:21: Kind incompatibility when matching types: b0 :: * (# #) :: # In the second argument of ‘seq’, namely ‘(##)’ In the expression: seq () (##) }}} Looking at the code, this behavior is expected, because the first version of the code calls into `tcInfer . tcExpr`, which special-cases `seq`, while the second is caught by `tcInferApp`, which doesn't have the special case. The above example shows that this isn't just a theoretical concern about code cleanup! This all leads to another question: Why special-case `seq` at all? !MkId tells me that {{{ seq :: forall (a :: *) (b :: *). a -> b -> b }}} Why isn't it {{{ seq :: forall (a :: *) (b :: OpenKind). a -> b -> b }}} With the second type, I would imagine that `seq` wouldn't need a special case in the type-checker. Is there something wrong with the second type for `seq`? I'll post more thoughts to this ticket as I continue to explore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies
by GHC 11 Dec '14

11 Dec '14

#9090: Untouchable higher-kinded type variable in connection with RankNTypes, ConstraintKinds and TypeFamilies -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I have the following module {{{ {-# LANGUAGE RankNTypes, ConstraintKinds, TypeFamilies #-} import GHC.Exts (Constraint) type family D (c :: Constraint) :: Constraint type instance D (Eq a) = Eq a -- checks f :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f g x = g x -- checks f' :: Eq b => (forall a. Eq a => f a -> Bool) -> f b -> Bool f' = f -- checks, so GHC seems to think that both types are interchangeable f'' :: Eq b => (forall a. D (Eq a) => f a -> Bool) -> f b -> Bool f'' = f' -- checks test' y = f' (\ (Just x) -> x /= x) y -- fails test y = f (\ (Just x) -> x /= x) y -- fails too, unsurprisingly test'' y = f'' (\ (Just x) -> x /= x) y }}} The module checks with GHC-7.6.3, but fails in GHC-7.8.2 and GHC-7.9.20140430 with {{{ src/Test.hs:24:16: Couldn't match type ‘f’ with ‘Maybe’ ‘f’ is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:24:10-35 ‘f’ is a rigid type variable bound by the inferred type of test :: Eq b => f b -> Bool at src/Test.hs:24:1 Possible fix: add a type signature for ‘test’ Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:24:6) test :: f b -> Bool (bound at src/Test.hs:24:1) In the pattern: Just x In the first argument of ‘f’, namely ‘(\ (Just x) -> x /= x)’ In the expression: f (\ (Just x) -> x /= x) y src/Test.hs:27:20: Couldn't match type ‘f’ with ‘Maybe’ ‘f’ is untouchable inside the constraints (D (Eq a)) bound by a type expected by the context: (D (Eq a)) => f a -> Bool at src/Test.hs:27:12-39 ‘f’ is a rigid type variable bound by the inferred type of test'' :: Eq b => f b -> Bool at src/Test.hs:27:1 Possible fix: add a type signature for ‘test''’ Expected type: f a Actual type: Maybe a Relevant bindings include y :: f b (bound at src/Test.hs:27:8) test'' :: f b -> Bool (bound at src/Test.hs:27:1) In the pattern: Just x In the first argument of ‘f''’, namely ‘(\ (Just x) -> x /= x)’ In the expression: f'' (\ (Just x) -> x /= x) y }}} I'd expect it to typecheck. At first, I thought this might be related in some way to #8985. That's why I tested with HEAD, but while #8985 seems indeed to be fixed, this is still a problem there. Also, while my simplified test case compiles with GHC-7.6.3, my original more complicated program does not, so there might be another report forthcoming if I manage to isolate the difference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9808: Add data-dir to InstalledPackageInfo
by GHC 08 Dec '14

08 Dec '14

#9808: Add data-dir to InstalledPackageInfo -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, the data directory of a package is not stored in the package database. This is fine for programs produced by GHC, where programs know the location of their own data files through the `Paths_packagename` module, but it's not sufficient for programs that do not have direct access to the local filesystem. Programs produced by GHCJS should be able to load their data files over HTTP. If GHCJS would know the `data-dir` location of all packages, it could make the data files for all dependencies available when linking, and generate a `FilePath -> URI` mapping table. The best it can currently do is making all files on the hard drive available. I have a patch for this that I'll submit once I've figured out how Phabricator works ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9777: -msse flag could be handled better by the driver
by GHC 06 Dec '14

06 Dec '14

#9777: -msse flag could be handled better by the driver -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Other than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- I bumped into two small issues with `-msse` and `-msse4.2` flags: 1. GHC accepts any flag of the form `-msseX.Y`, eg. `-msse3.14`. I think we should validate numbers passed by the user or - even better - pre- define a set of allowed `-msse` flags. Currently we have this definition: {{{ Flag "msse" (versionSuffix (\maj min d -> d{ sseVersion = Just (maj, min) })) }}} 2. A direct consequence of above definition is that bash command-line auto-completion does not suggest `-msse4.2` flag. This is somewhat related to Austin's Phab:D165 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8894: Clean up `Coercible` plumbing
by GHC 03 Dec '14

03 Dec '14

#8894: Clean up `Coercible` plumbing ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, the way `Coercible` is exported (with an data type in `GHC.Types` and a built-in !TyCon exported in `GHC.Prim`) works, but is confusing and should be cleaned up. Probably by exporting it directly from `GHC.Types`. Care needs to be taken that ghci and haddock display the data from modified built-in !TyCon; when I tried that a while ago it was displayed as a regular data type by one of them. If that is still the case and I didn't just do a mistake back then, this probably needs to be understood and fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9142: LLVM HEAD rejects aliases used by LLVM codegen
by GHC 02 Dec '14

02 Dec '14

#9142: LLVM HEAD rejects aliases used by LLVM codegen ------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | 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: | ------------------------------------+------------------------------------- LLVM HEAD has [https://github.com/llvm- mirror/llvm/commit/38048cdb1c016e1429004ddf4adfa40a8d853cbf changed] the behavior of aliases to reject references to things other than definitions. This unfortunately means that the handling of externs breaks, {{{ "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o You are using a new version of LLVM that hasn't been tested yet! We will try though... Alias must point to a definition i8* @"barf$alias" Alias must point to a definition i8* @"stg_gc_unpt_r1$alias" Alias must point to a definition i8* @"stg_apply_interp_info$alias" Alias must point to a definition i8* @"stg_yield_to_interpreter$alias" Alias must point to a definition i8* @"stg_ap_stack_entries$alias" Alias must point to a definition i8* @"__stg_gc_enter_1$alias" Alias must point to a definition i8* @"stg_upd_frame_info$alias" LLVM ERROR: Broken module found, compilation aborted! }}} In reference to the following aliases,. {{{ @barf = external global i8 @barf$alias = alias private i8* @barf @stg_gc_unpt_r1 = external global i8 @stg_gc_unpt_r1$alias = alias private i8* @stg_gc_unpt_r1 @stg_apply_interp_info = external global i8 @stg_apply_interp_info$alias = alias private i8* @stg_apply_interp_info @stg_yield_to_interpreter = external global i8 @stg_yield_to_interpreter$alias = alias private i8* @stg_yield_to_interpreter @stg_ap_stack_entries = external global i8 @stg_ap_stack_entries$alias = alias private i8* @stg_ap_stack_entries @__stg_gc_enter_1 = external global i8 @__stg_gc_enter_1$alias = alias private i8* @__stg_gc_enter_1 @stg_upd_frame_info = external global i8 @stg_upd_frame_info$alias = alias private i8* @stg_upd_frame_info }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9142> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #8548: Coercible does not resolve type family application
by GHC 02 Dec '14

02 Dec '14

#8548: Coercible does not resolve type family application -------------------------------------------+------------------------------- Reporter: nomeata | Owner: nomeata 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: #8503 | Test Case: | Blocking: -------------------------------------------+------------------------------- With GND implemented using `Coercible` (See #8503) the test for #4185 fails. A minimal example is: {{{ {-# LANGUAGE TypeFamilies #-} module CoerceNewtypeFamily where import GHC.Exts data family Foo k newtype instance Foo Int = FooInt Int x :: Foo Int -> Int x = coerce }}} yielding {{{ [1 of 1] Compiling CoerceNewtypeFamily ( CoerceNewtypeFamily.hs, CoerceNewtypeFamily.o ) CoerceNewtypeFamily.hs:11:5: No instance for (Coercible (Foo Int) Int) because ‛Foo Int’ and ‛Int’ are different types. arising from a use of ‛coerce’ In the expression: coerce In an equation for ‛x’: x = coerce }}} I guess the `Coercible` finding code needs to simply type family equations if possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8548> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7