September 2016 - ghc-tickets

[GHC] #12423: Panic with DeriveAnyClass and DefaultSignatures
by GHC 10 Feb '17

10 Feb '17

#12423: Panic with DeriveAnyClass and DefaultSignatures -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- With the code {{{#!hs {-# LANGUAGE DefaultSignatures, DeriveAnyClass #-} class Eq1 f where (==#) :: Eq a => f a -> f a -> Bool default (==#) :: Eq (f a) => f a -> f a -> Bool (==#) = (==) data Foo a = Foo (Either a a) deriving (Eq, Eq1) }}} GHC 8.0.1 and 7.10.3 both panic: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): in other argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12423> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9821: DeriveAnyClass support for higher-kinded classes + some more comments
by GHC 10 Feb '17

10 Feb '17

#9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #5462 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- #5462 was merged before a few final fixes were done. This ticket serves to record that. Left to address are: https://phabricator.haskell.org/D476?id=1443#inline-3652 https://phabricator.haskell.org/D476?id=1443#inline-3648 https://phabricator.haskell.org/D476?id=1443#inline-3646 Also, `DeriveAnyClass` currently panics at higher-kinded classes (like `((* -> *) -> *) -> Constraint`). I'll fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12594: DeriveAnyClass fails to derive some classes
by GHC 10 Feb '17

10 Feb '17

#12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveAnyClass, DeriveGeneric #-} import Database.PostgreSQL.Simple import GHC.Generics data Foo = Foo { bar :: Int } deriving (Generic, ToRow) }}} This succeeds using `ghci`, but fails when trying to compile it using `ghc` with the following error message: {{{ • No instance for (Database.PostgreSQL.Simple.ToField.ToField Char) arising from the first field of ‘Foo’ (type ‘Int’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (ToRow Foo) }}} However, it works if I use `instance ToRow Foo` instead of relying upon `DeriveAnyClass`. I've tried this with other types instead of `Int`, using `newtype` instead of `data` and having multiple fields in the datatype. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position
by GHC 10 Feb '17

10 Feb '17

#12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: Generics | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE KindSignatures #-} module Example where class C (a :: * -> *) data T a = MkT (a -> Int) deriving C }}} fails to compile with the following GHC panic: {{{ $ /opt/ghc/8.0.1/bin/ghc Example.hs [1 of 1] Compiling Example ( Example.hs, Example.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): contravariant Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The culprit is that when `DeriveAnyClass` comes up with the constraints for typeclass instances whose argument is of kind `* -> *`, it calls [http://git.haskell.org/ghc.git/blob/0676e68cf5fe8696f1f760fef0f35dba14db110… deepSubtypesContaining], which immediately bails out when it sees a type variable in a contravariant or "bad" position. I'm less sure of what the fix should be. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind
by GHC 10 Feb '17

10 Feb '17

#12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following program compiles without issue on GHC 7.6.3 through GHC 7.10.3, but fails to compile on GHC 8.0.1 and GHC HEAD. (I added a CPP guard simply because the `DataD` constructor changed between 7.10 and 8.0.) {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Regression where import Language.Haskell.TH data T k class C a $(do TyConI (DataD [] tName [ KindedTV kName kKind] #if __GLASGOW_HASKELL__ >= 800 _ #endif _ _) <- reify ''T d <- instanceD (cxt []) (conT ''C `appT` (conT tName `appT` sigT (varT kName) kKind)) [] return [d]) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Regression.hs [1 of 1] Compiling Regression ( Regression.hs, Regression.o ) Regression.hs:(13,3)-(19,15): Splicing declarations do { TyConI (DataD [] tName_a2RT [KindedTV kName_a2RU kKind_a2RV] _ _ _) <- reify ''T; d_a31Y <- instanceD (cxt []) (conT ''C `appT` (conT tName_a2RT `appT` sigT (varT kName_a2RU) kKind_a2RV)) []; return [d_a31Y] } ======> instance C (T (k_avB :: k_avC)) Regression.hs:13:3: error: Variable ‘k_avB’ used as both a kind and a type Did you intend to use TypeInType? }}} Somewhat confusingly, you can use `instance C (T (k_avB :: k_avC))` on its own, and it will compile without issue. Also, quoting it doesn't seem to trip up this bug, as this also compiles without issue: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module WorksSomehow where import Language.Haskell.TH data T k class C a $([d| instance C (T k) |]) }}} The original program has several workarounds: 1. Turn off `PolyKinds` (OK, this isn't a very good workaround...) 2. Add an explicit kind signature to `T`, e.g., `data T (k :: k1)` 3. Change the type variable of `T` to some other letter, e.g., `data T p` or `data T k1` Given that (3) is a successful workaround, I strongly suspect that GHC is confusing the type variable `k` (which gets `ddump-splice`d as `k_avB`) with the kind variable `k` (which gets `ddump-splice`d as `k_avC`) due to their common prefix `k`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11668: SPEC has a runtime cost
by GHC 10 Feb '17

10 Feb '17

#11668: SPEC has a runtime cost -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As far as I know, `SPEC` is merely intended to help the compiler identify calls for which constructor specialization may be help. Yet it's not erased! In fact, it has a runtime representation which we need to construct and pass around to so-marked calls. This likely isn't killing the performance of anyone's programs but surely we can do better than this. Really, the whole scheme of marking functions with `SPEC` (which as far as I know isn't even properly documented) seems quite odd. What is stopping us from simply attaching pragmas to equations? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10626: Missed opportunity for SpecConstr
by GHC 10 Feb '17

10 Feb '17

#10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Look at `perf/should_run/T4830`. After `SpecConstr` and optimisation we finally get {{{ Rec { Main.foo_$s$wfoo1 [Occ=LoopBreaker] :: Int# -> Double -> Double -> Double# [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,1*U><L,U><L,U>] Main.foo_$s$wfoo1 = \ (sc_s4eN :: Int#) (sc1_s4eO :: Double) (sc2_s4eP :: Double) -> case sc_s4eN of ds_X1SR { __DEFAULT -> case sc1_s4eO of wild_a1Tf { D# x_a1Th -> case sc2_s4eP of wild1_a1Tj { D# y_a1Tl -> case tagToEnum# @ Bool (<=## x_a1Th y_a1Tl) of _ [Occ=Dead] { False -> Main.foo_$s$wfoo1 (-# ds_X1SR 1#) wild1_a1Tj wild_a1Tf; True -> Main.foo_$s$wfoo1 (-# ds_X1SR 1#) wild_a1Tf wild1_a1Tj } } }; 0# -> case sc1_s4eO of _ [Occ=Dead] { D# x_a1UL -> case sc2_s4eP of _ [Occ=Dead] { D# y_a1UP -> +## x_a1UL y_a1UP } } } end Rec } }}} If we ran `SpecConstr` again we'd specialise this function, because the recursive calls both have boxed arguments. I looked into why `SpecConstr` didn't catch it, and it's because `SpecConstr`'s input looks like this {{{ case case tagToEnum# @ Bool (<=## x_a1Th y_a1Tl) of _ [Occ=Dead] { False -> (wild1_a1Tj, wild_a1Tf); True -> wild_X8 } of r_s4e0 { (ipv_s4e1, ipv_s4e2) -> $wfoo_s4db (I# (-# ds_X1SR 1#)) (Just @ (Double, Double) r_s4e0) }}} Notice the case-of-case which doesn't expose the `Double` boxes of arguments to `$wfoo`. Why is that case-of-case still there? Because of `Note [Single- alternative cases]` in Simplify. Which is clearly a delicate spot so I don't want to meddle with it today. But it's intriguing. Maybe Sequent Core will do better. Note that late demand analysis also catches this case, yielding the (rather good) {{{ Rec { Main.$w$s$wfoo [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Double# -> Double# -> Double# [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <S,1*U><L,U><L,U>] Main.$w$s$wfoo = \ (w_s4gW :: Int#) (ww_s4h1 :: Double#) (ww1_s4h5 :: Double#) -> case w_s4gW of ds_X1SW { __DEFAULT -> case tagToEnum# @ Bool (<=## ww_s4h1 ww1_s4h5) of _ [Occ=Dead] { False -> Main.$w$s$wfoo (-# ds_X1SW 1#) ww1_s4h5 ww_s4h1; True -> Main.$w$s$wfoo (-# ds_X1SW 1#) ww_s4h1 ww1_s4h5 }; 0# -> +## ww_s4h1 ww1_s4h5 } end Rec } }}} I'm pretty sure that late-demand-analysis should be on with `-O2` but someone should do a nofib run to check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10681: Teach GHC to interpret all hs files as two types of hs-boot files (abstract types only/full types + values)
by GHC 10 Feb '17

10 Feb '17

#10681: Teach GHC to interpret all hs files as two types of hs-boot files (abstract types only/full types + values) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is a new proposal for solving #1409. The big addition here is that we create **two** hs-boot files for each hs file: one that is a full hs-boot file to be imported by hs files to break loops, and a second which only includes abstract types for hs-boot files to import. C.f. #10679 **Discussion.** Here is a slightly goofy `hs-boot` file I've excerpted from GHC: {{{ module Packages where import {-# SOURCE #-} Module (PackageKey) import {-# SOURCE #-} DynFlags (DynFlags) packageKeyPackageIdString :: DynFlags -> PackageKey -> Maybe String }}} The `hs-boot` file must itself import `hs-boot` files, because this boot file is used by `Module` and `DynFlags`; without `{-# SOURCE #-}`, the boot file itself will participate in a cycle! But notice that there is something very interesting: a boot file is ONLY ever interested in importing other modules to get types. Never to import constructors or functions! We can use this observation to give us a mechanical transformation of an `hs` file to an `hs-boot` file, ASSUMING we can define a "second level" of `hs-boot` file to record our abstract types. **Example.** In this example, we have chosen to break the loop from `A`s import to `B`. {{{ module A where import {-# SOURCE #-} B data A = A B f :: A -> Bool f (A (B (A b))) = g b f _ = True module B where import A data B = B A g :: B -> Bool g (B (A (B b))) = f b g _ = False }}} The first-level `hs-boot`s are: {{{ module A where -- not actually used import {-# SOURCE 2 #-} B data A = A B f :: A -> Bool module B where import {-# SOURCE 2 #-} A data B = B A g :: B -> Bool }}} The second-level `hs-boot`s are: {{{ module A where data A module B where -- not actually used data B }}} **Commentary.** Here are some remarks: 1. Because we have to lift the transitive dependencies of anything we `{-# SOURCE #-}` import, it doesn't make sense to have a pragma which explicitly says what to put in the `hs-boot` file; instead, we just put in everything that we *can* handle in an `hs-boot` file (so exclude anything with missing type signatures, type families, etc.) Ideally, these automatic hs-boot files are generated lazily, but they should be reused as necessary. 2. This facility actually makes `{-# SOURCE #-}` a lot more attractive for increasing separate compilation: you can mark an import `{-# SOURCE #-}` to ensure that if its implementation changes, you don't have to recompile this module / you can build the module in parallel with that module. The downside is that when the imported file is modified, we have to regenerate the `hs-boot` stub before we conclude that the types have not changed (as opposed to with separate `hs-boot` files, where a modification to `hs` would not bump the timestamp on `hs-boot`. 3. This seems to definitely suggest that you should never need more than two levels of hs-boot nesting, or perhaps three with kinding. (But maybe someone has a fancy type system feature for which this is not true!) Maybe this applies to signature files too. 4. We can't force the first level of `hs-boot` files to be abstract types, for two reasons: (1) a source file importing the hs-boot file may really need the selector/constructor, and (2) the `hs-boot` files will reflect any cycles from the source files, that's no good! Rolling out to the second level breaks the cycle because abstract types never need any imports. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10681> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11062: Type families + hs-boot files = panic
by GHC 09 Feb '17

09 Feb '17

#11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- I have these modules: A.hs-boot: {{{ {-# LANGUAGE TypeFamilies #-} module A where type family F a }}} B.hs: {{{ {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A type instance F Int = Bool }}} A.hs: {{{ {-# LANGUAGE TypeFamilies #-} module A where import B type family F a }}} And now this happens: {{{ rae:11:50:47 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 7.11.20151104 rae:11:50:50 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A .hs-boot rae:11:50:52 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c B.hs rae:11:50:54 ~/temp/bug> ~/Documents/ghc-cur/inplace/bin/ghc-stage2 -c A.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151104 for x86_64-apple-darwin): tcIfaceGlobal (local): not found: F [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rae:11:50:57 ~/temp/bug> }}} The problem occurs only in one-shot mode. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8155: Defaulting bug or unfortunate error message with closed type families
by GHC 08 Feb '17

08 Feb '17

#8155: Defaulting bug or unfortunate error message with closed type families ------------------------------------+------------------------------------- Reporter: nh2 | 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: | ------------------------------------+------------------------------------- https://github.com/nh2/infinite-type-families/blob/master/Test2.hs Some code extracted from hmatrix: {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module Test where data Vector a = Vector a data Matrix a = Matrix a class Build f where build' :: BoundsOf f -> f -> ContainerOf f #if __GLASGOW_HASKELL__ <= 706 -- Normal type families with GHC 7.6, works well. type family BoundsOf x type instance BoundsOf (a->a) = Int type instance BoundsOf (a->a->a) = (Int,Int) type family ContainerOf x type instance ContainerOf (a->a) = Vector a type instance ContainerOf (a->a->a) = Matrix a #else -- Closed type families for GHC 7.8 type family BoundsOf x where BoundsOf (a->a->a) = (Int,Int) BoundsOf (a->a) = Int type family ContainerOf x where ContainerOf (a->a) = Vector a ContainerOf (a->a->a) = Matrix a #endif instance (Num a) => Build (a->a) where build' = buildV buildV :: (Integral a, Num b) => a -> (b -> c) -> Vector c buildV _ _ = undefined }}} This is probably related to #8154. With GHC 7.7, we get the following error: {{{ Test2.hs:59:14: Could not deduce (BoundsOf (a -> a) ~ Integer) from the context (Num a) bound by the instance declaration at Test2.hs:58:10-32 Expected type: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) Actual type: Integer -> (a -> a) -> Vector a Relevant bindings include build' :: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) (bound at Test2.hs:59:5) In the expression: buildV In an equation for ‛build'’: build' = buildV }}} 1) Where does this Integer come from? 2) Change {{{ BoundsOf (a->a) = Int }}} into {{{ BoundsOf (a->a) = Integer }}} You get the same error message, although clearly {{{BoundsOf (a -> a) ~ Integer}}} (you just wrote that down).[[BR]] Even if the order matters in closed type families, is this not the wrong error message? 3) If you flip the order so that the (a->a) case comes first, it works (with both it Int or Integer). I don't quite understand why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8