January 2017 - ghc-tickets

[GHC] #9562: Type families + hs-boot files = unsafeCoerce
by GHC 13 Feb '17

13 Feb '17

#9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider the following bundle of modules: A.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module A where type family F a b }}} B.hs-boot: {{{#!hs module B where import A oops :: F a b -> a -> b }}} B.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module B where import A import C type instance F a b = b oops :: F a b -> a -> b oops = const }}} C.hs: {{{#!hs module C (oops) where import {-# SOURCE #-} B }}} D.hs: {{{#!hs {-# LANGUAGE TypeFamilies #-} module D where import A import C type instance F a b = a unsafeCoerce :: a -> b unsafeCoerce x = oops x x }}} Main.hs: {{{#!hs module Main where import D ( unsafeCoerce ) main = print $ (unsafeCoerce True :: Int) }}} When loading these into GHCi, we quite reasonably get a type family instance overlap error. But, separate compilation leads to disaster: {{{ rae:01:49:47 ~/temp/bug> ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 rae:01:49:49 ~/temp/bug> ghc -c A.hs rae:01:49:53 ~/temp/bug> ghc -c B.hs-boot rae:01:49:58 ~/temp/bug> ghc -c C.hs rae:01:50:09 ~/temp/bug> ghc -c B.hs rae:01:50:13 ~/temp/bug> ghc -c D.hs rae:01:50:17 ~/temp/bug> ghc Main.hs -o Unsafe [6 of 6] Compiling Main ( Main.hs, Main.o ) Linking Unsafe ... rae:01:50:23 ~/temp/bug> ./Unsafe 2882303761534249061 }}} Yikes! Proposed (terrible) solution: hs-boot files '''must''' list all type instance declarations in the corresponding modules. It may also be a good idea to require all normal instance declarations in the hs-boot file as well, because this same trick can be used to introduce incoherence (I think -- haven't tested). This bug persists even if `Main` declares that it is `Safe`. I've attached a tarball of the files for ease of testing. (Credit to Edward Yang and Geoff Mainland, whose discussion provoked the line of inquiry that led to this discovery.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13214: Orphan instances in Backpack signatures don't work
by GHC 12 Feb '17

12 Feb '17

#13214: Orphan instances in Backpack signatures don't work -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ unit p where signature A where instance Show (a -> b) module B where import A f = show (\x -> x) }}} There are probably other problems too but here's the start. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8405: experiment with using function-sections for linking (for smaller libs and executables)
by GHC 12 Feb '17

12 Feb '17

#8405: experiment with using function-sections for linking (for smaller libs and executables) ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: | ------------------------------------+------------------------------------- currently the only support we have for making small (ish) executables using split objects, which 1. is not on by default, for various good reasons 2. can seriously penalize compile times 3. in tandem, something like strip is often used, but on some platforms/targets (such as the iOS cross compiler), strip will actually break things might be worth seriously experimenting with function-sections / gc- sections in the object files we generate. example slide deck on this http://elinux.org/images/2/2d/ELC2010-gc- sections_Denys_Vlasenko.pdf -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8405> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[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] #13199: TH-spliced class instances are pretty-printed incorrectly post-#3384
by GHC 10 Feb '17

10 Feb '17

#13199: TH-spliced class instances are pretty-printed incorrectly post-#3384 -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: -------------------------------------+------------------------------------- The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. You can see this for yourself by compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where class C a b $([d| instance C a (Maybe b) |]) }}} {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.1.20170126: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(9,3)-(10,6): Splicing declarations [d| instance C a_a1eC (Maybe b_a1eD) |] ======> instance C a_a4m5 Maybe b_a4m6 }}} Note the nonsensical `instance C a_a4m5 Maybe b_a4m6`. For comparison, here is how it should be pretty-printed: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(9,3)-(10,6): Splicing declarations [d| instance C a_a13N (Maybe b_a13O) |] ======> instance C a_a3Ju (Maybe b_a3Jv) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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