February 2017 - ghc-tickets

[GHC] #13266: Source locations from signature merging/matching are bad
by GHC 10 Feb '17

10 Feb '17

#13266: Source locations from signature merging/matching are bad -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Example output: {{{ /tmp/ghc3555_0/ghc_7.hscpp:1:1: error: No instance for (GHC.Enum.Enum t) arising when attempting to show that instance [safe] MonadHold t (PushM t) -- Defined in ‘z-reflex-z-common-0.5.0:Reflex.NewPure’ is provided by ‘z-reflex-z-common-0.5.0:Reflex.NewPure’ Possible fix: add (GHC.Enum.Enum t) to the context of the instance declaration | 1 | # 1 "indef/Reflex/Sig.hsig" }}} Unfortunately, this is not so easy to fix. Ordinarily, type errors occur while we are checking the source file in question, so we have plenty of SrcSpans from the parsed syntax tree to attach error to good source locations. However, a signature merge works differently: in general, we will have some interface files from our dependencies which we would like to merge together. If there is an incompatibility, there is NO local source declaration that we can get a SrcSpan for. So, what should we report in this case? One possibility is that we want to report the location of the source file *that produced the interface file.* But that would involve saving file paths in interface files, which seems quite distasteful to me, especially since the source location might be in a temporary directory, in which case you just broke determinism. So... I am not sure what to do here! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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] #13258: GHC head 8.1.20170209 does not compile package 'mono-traversable'
by GHC 10 Feb '17

10 Feb '17

#13258: GHC head 8.1.20170209 does not compile package 'mono-traversable' -------------------------------------+------------------------------------- Reporter: clinton | 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: -------------------------------------+------------------------------------- Not sure if this is a bug in 'mono-traversable' or GHC but I thought it was worth reporting in any case. GHC head 8.1.20170209 is the version used: {{{ Configuring mono-traversable-1.0.1.1... Preprocessing library mono-traversable-1.0.1.1... [1 of 5] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, .stack-work/dist/x86_64-linux/Cabal-1.25.0.0/build/Data/MonoTraversable.o ) /tmp/stack12856/mono- traversable-1.0.1.1/src/Data/MonoTraversable.hs:144:13: error: • The default type signature for omap: forall (f :: * -> *) a. (Functor f, Element (f a) ~ a, f a ~ mono) => (a -> a) -> f a -> f a does not match its corresponding non-default type signature • When checking the class method: omap :: forall mono. MonoFunctor mono => (Element mono -> Element mono) -> mono -> mono In the class declaration for ‘MonoFunctor’ | 144 | default omap :: (Functor f, Element (f a) ~ a, f a ~ mono) => (a -> a) -> f a -> f a | ^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 10 Feb '17

10 Feb '17

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman <alan.zimm@…>): In [changeset:"258c719599f78178c75b58d9c49e10e498cb7c48/ghc" 258c719/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="258c719599f78178c75b58d9c49e10e498cb7c48" TH-spliced class instances are pretty-printed incorrectly post-#3384 Summary: The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. Test Plan: ./validate Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3043 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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