July 2014 - ghc-tickets

[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 03 Dec '14

03 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] #9186: GHC panic when compiling compdata
by GHC 01 Dec '14

01 Dec '14

#9186: GHC panic when compiling compdata ------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 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: | ------------------------------------+------------------------------------- When testing ghc-7.8.2.20140609 with Stackage, I came across the following ghc panic: [51 of 62] Compiling Data.Comp.Ordering ( src/Data/Comp/Ordering.hs, dist/build/Data/Comp/Ordering.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2.20140609 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc4836_0/ghc4836_257.so: undefined symbol: compdatazm0zi8zi1zi0_DataziCompziDeriveziUtils_zdwabstractConType_info Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Failed to install compdata-0.8.1.0 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #8100: Standalone deriving using template haskell
by GHC 01 Dec '14

01 Dec '14

#8100: Standalone deriving using template haskell ------------------------------------+------------------------------------- Reporter: acube | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently, there seems to be no support for standalone deriving in TemplateHaskell: {{{ Prelude Data.Typeable Language.Haskell.TH> :set -XStandaloneDeriving Prelude Data.Typeable Language.Haskell.TH> data Weird a (b :: * -> * -> *) c = Weird Prelude Data.Typeable Language.Haskell.TH> runQ $ [d| deriving instance Typeable Weird |] [] }}} ''Use case'': The library [http://hackage.haskell.org/package/typeable-th typeable-th] can already generate Typeable instances using TH for GHC 7.4 and 7.6. To add support for GHC 7.8 in a way that the user doesn't have to care about the version, there has to be a way to make Typeable instances via TH in GHC 7.8. This is currently impossible, but with StandaloneDeriving support for TH, it would be possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9005: Ship default bash completion file with ghc
by GHC 01 Dec '14

01 Dec '14

#9005: Ship default bash completion file with ghc ------------------------------------+------------------------------------- Reporter: td123 | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: None | 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: | ------------------------------------+------------------------------------- Now that ticket #7843 has been closed, it would be great to ship a default implementation of a bash completion file for ghc. Since there isn't a standard location to install completion files across distros, it might be good to have an optional flag during configure to specify a location and if one is specified, install the bash completion file into that location. The following links provide implementations that have worked for me: http://www.reddit.com/r/haskell/comments/236qkb/autocomplete_command_line_o… https://ghc.haskell.org/trac/ghc/wiki/AutocompleteGHCFlags -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9005> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8815: confusing language in error message
by GHC 30 Nov '14

30 Nov '14

#8815: confusing language in error message ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Late last night I was finding myself very confused by the following (in retrospect obvious error message) {{{ src/Numerical/OpenBLAS/BLAS.hs:41:44: A pattern match on a GADT requires GADTs or TypeFamilies In the pattern: SRow In the pattern: DenseMatrix SRow _ _ _ _ In an equation for ‛encodeNiceOrderHelper’: encodeNiceOrderHelper (DenseMatrix SRow _ _ _ _) = encodeOrder BLASRowMajor }}} the error is correct per se, but reading (at least late at night) made me think "wait, how is my type not a GADT or TypeFamily?!!?!" I'm thinking (perhaps ) that ``` A pattern match on a GADT requires GADTs or TypeFamilies `` ` could perhaps be more clearly communicated as ```A pattern match on a GADT requires that GADTs or TypeFamilies Language extensions be enabled in the use site module``` (or something similar) relatedly: whats the current reasoning for why GADT related matching logic isn't enabled in client modules that use GADTs? (i'm not questioning it, just wondering why) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10