August 2014 - ghc-tickets

[GHC] #9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux
by GHC 14 Dec '14

14 Dec '14

#9372: dll-split during stage 2 compiling ghc v7.8.3 for arm_linux ----------------------------+---------------------------------------------- Reporter: chrisfgl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------------- Trying to compile GHC 7.8.3 for ubuntu/arm. Was in Stage 1 for 8 hours before exiting with following message: dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped) make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #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] #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

[GHC] #9240: "read . show ≡ id" not satisfied by Data.Fixed
by GHC 02 Dec '14

02 Dec '14

#9240: "read . show ≡ id" not satisfied by Data.Fixed ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9213 | ------------------------------------+------------------------------------- As pointed out in #9213, the desired property "read . show ≡ id" is not satisfied for all resolutions. For instance, consider the following example: {{{ > data B7 > instance HasResolution B7 where resolution _ = 128 > 1.070 :: Fixed B7 1.062 > 1.062 :: Fixed B7 1.054 > read "1.070" :: Fixed B7 1.062 > read "1.062" :: Fixed B7 1.054 }}} This behaviour can be reproduced all the way back to GHC 7.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8304: more lenient operator sections (RelaxedSections extension)
by GHC 01 Dec '14

01 Dec '14

#8304: more lenient operator sections (RelaxedSections extension) -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | 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: | -------------------------------------+------------------------------------- Some operator sections are rejected which could have some meaning. {{{ (a ++ b ++ ) could mean \x -> a ++ b ++ c (++ a ++) could mean \x y -> x ++ a ++ y }}} The attached quasiquoter implements this, but for various reasons it would be better if ghc supported this directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9497: Silent typed holes
by GHC 01 Dec '14

01 Dec '14

#9497: Silent typed holes -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: typed holes, | Operating System: warnings | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have a UI feature request for -fwarn-typed-holes, currently there's two options: 1) typed holes are on (default) and GHC prints errors for types holes or 2) typed holes are off and GHC will print "not in scope" error and prematurely end compilation. When writing haskell, I frequently want to typecheck my code before it's completely implemented. Before I used undefined/error, which worked but I was always worried about accidentally forgetting an undefined somewhere. With typed holes this is no longer a problem, but unfortunately the warnings from typed holes are so verbose they drown out the other type errors. This makes typechecking during refactoring rather onerous. I propose adding a -fsilent-typed-holes and/or -ftreat-type-holes-as- undefined which enable typed holes, but silence any compile time warnings. It'd be nice if this flag treated holes as if "-fdefer-type-errors" was on, but ONLY for typed holes. This would let me compile the code and fix warnings, ignoring the holes while developing, while still assuring that, when I remove the flag and compile "for real" I get an error about typed holes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12