September 2016 - ghc-tickets

[GHC] #11339: Possible type-checker regression in GHC 8.0
by GHC 21 Oct '16

21 Oct '16

#11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 (Type checker) | 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 following code (extracted from hackage:microlens) type-checks on GHC 7.10 but '''not''' on GHC 8.0/8.1: {{{#!hs {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Failing where import Control.Applicative ( Const(Const, getConst) ) import Data.Functor.Identity ( Identity(Identity) ) type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t failing :: forall s t a b . Traversal s t a b -> Traversal s t a b -> Traversal s t a b failing left right afb s = case pins t of [] -> right afb s _ -> t afb where -- t :: (a -> f b) -> f t -- TYPECHECKS with GHC 7.10, but not with GHC 8.x: Bazaar { getBazaar = t } = left sell s -- FAILS TO TYPECHECK with GHC 7.10 and GHC 8.x: -- t = getBazaar (left sell s) sell :: a -> Bazaar a b b sell w = Bazaar ($ w) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] pins f = getConst (f (\ra -> Const [Identity ra])) newtype Bazaar a b t = Bazaar { getBazaar :: (forall f. Applicative f => (a -> f b) -> f t) } instance Functor (Bazaar a b) where fmap f (Bazaar k) = Bazaar (fmap f . k) instance Applicative (Bazaar a b) where pure a = Bazaar $ \_ -> pure a Bazaar mf <*> Bazaar ma = Bazaar $ \afb -> mf afb <*> ma afb }}} The following error is emitted on GHC 8.0: {{{ failing.hs:13:11: error: • Couldn't match type ‘f’ with ‘Const [Identity a]’ ‘f’ is a rigid type variable bound by the type signature for: failing :: forall (f :: * -> *). Applicative f => Traversal s t a b -> Traversal s t a b -> (a -> f b) -> s -> f t at failing.hs:11:1 Expected type: a -> Const [Identity a] b Actual type: a -> f b • In the first argument of ‘t’, namely ‘afb’ In the expression: t afb In a case alternative: _ -> t afb • Relevant bindings include t :: (a -> Const [Identity a] b) -> Const [Identity a] t (bound at failing.hs:18:26) sell :: a -> Bazaar a b b (bound at failing.hs:24:5) pins :: ((a -> Const [Identity a] b) -> Const [Identity a] t) -> [Identity a] (bound at failing.hs:27:5) afb :: a -> f b (bound at failing.hs:11:20) right :: Traversal s t a b (bound at failing.hs:11:14) left :: Traversal s t a b (bound at failing.hs:11:9) failing :: Traversal s t a b -> Traversal s t a b -> Traversal s t a b (bound at failing.hs:11:1) }}} I don't understand why `Bazaar t = ...` vs `t = getBazaar ...` makes a difference in GHC 7.10 at all. So I'm not sure if this is a regression or actually something that got fixed in GHC 8.0... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb
by GHC 20 Oct '16

20 Oct '16

#12236: Windows profiling: T11627b segfaults for WAY=prof_hc_hb ----------------------------------------+--------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #11627 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Reproducible with 7.10.3, 8.0.1 and today's HEAD ( afa6e8309e8e7a069abcf7879791d53cdf22f00a). The test was added by @jme in #11627. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12140: Clarify Trac menus for new reporters
by GHC 18 Oct '16

18 Oct '16

#12140: Clarify Trac menus for new reporters -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- An officemate of mine rarely posts bugs here. He finds the interface to posting a bug confusing. I have to say I agree, if I consider the perspective of an infrequent reporter. (The reason he rarely posts bugs is that he rarely has bugs to post, not because of the confusing interface.) Specifically, there are many fields to fill out when posting a bug. Some of these are important to us (`Version` probably being the most). Some are better for developers to set (`Milestone`, `Test case`). Some are less important (`Operating System` for a bug in the type-checker). Some are essentially ignored (`Type of failure`, in my experience). Yet a new reporter doesn't know any of this and will diligently try to fill out them all. Can we label the fields as to importance somehow? Mark some as advanced/dev only? Make some available only after posting the ticket (`Test case`, `Differential`)? I don't suppose there are masses of people out there trying to post bugs and stymied by this problem, but I do think we can clean this up a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12411: GHC panic on TypeApplications + TemplateHaskell
by GHC 18 Oct '16

18 Oct '16

#12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications, TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails {{{ $ ghci -XTemplateHaskell -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import Control.Lens Prelude Control.Lens> data A = B { _int :: Int } Prelude Control.Lens> pure @Q []; makeLenses ''A ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tcMonoExpr _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Control.Lens> }}} sorry, don't have time for more detail -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12411> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12562: GHC panic on rebuild (idInfo r_XsTP)
by GHC 18 Oct '16

18 Oct '16

#12562: GHC panic on rebuild (idInfo r_XsTP) -------------------------------------+------------------------------------- Reporter: cocreature | 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: -------------------------------------+------------------------------------- First of all let me apologize for the terrible testcase. I tried to find a smaller one (and am still trying) but haven’t managed to do so. The good news is that at least for me it’s reproducible === Steps to reproduce === {{{ git clone 'git@github.com:bscarlet/llvm-general.git' -b llvm-3.8 cd llvm-general cabal new-build llvm-general curl -s https://gist.githubusercontent.com/cocreature/c6807d7906756a2d58b8fe774141b… > out.patch git apply out.patch cabal new-build llvm-general }}} The patch just adds a newline somewhere to create a rebuild. I’ve seen this panic for completely different changes (all in this project) so I don’t think the change matters. I’ve also seen this panic with stack, cabal new-build and cabal build (using sandboxes). === Output === {{{ In order, the following will be built (use -v for more details): llvm-general-3.8.0.0 Preprocessing library llvm-general-3.8.0.0... [84 of 92] Compiling LLVM.General.Internal.Module ( src/LLVM/General/Internal/Module.hs, /home/moritz/tmp/llvm-general/dist- newstyle/build/llvm-general-3.8.0.0/build/LLVM/General/Internal/Module.o ) [85 of 92] Compiling LLVM.General.Module ( src/LLVM/General/Module.hs, /home/moritz/tmp/llvm-general/dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Module.o ) [LLVM.General.Internal.Module changed] [89 of 92] Compiling LLVM.General.Internal.PassManager ( src/LLVM/General/Internal/PassManager.hs, /home/moritz/tmp/llvm-general /dist-newstyle/build/llvm- general-3.8.0.0/build/LLVM/General/Internal/PassManager.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): idInfo r_XsTP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} === Comments === In this case this can be resolved by running cabal new-build again. However I’ve also had cases where this didn’t fix it and I had to blow away dist-newstyle. I haven’t yet managed to find a reproducible testcase for the latter. Matthew Pickering mentioned that he encountered this (or a similar) bug while building GHC. I tried core-lint but that didn’t help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #12589: GHC panic with defer-typed-holes
by GHC 18 Oct '16

18 Oct '16

#12589: GHC panic with defer-typed-holes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Does this still happen in HEAD? {{{#!hs import qualified GHC.Generics as GHC import Generics.SOP import Generics.SOP.TH import Data.Proxy gminbound' :: (Generic a, Code a ~ (xs:xss), All2 Bounded (Code a)) => a gminbound' = minBound & I & hcpure (Proxy @Bounded) & apInjs_POP & head & to }}} Fails but doesn't crash with {{{ $ ghci -ignore-dot-ghci -XTypeApplications -XTypeOperators -XDataKinds -XGADTs -XFlexibleContexts /tmp/tX96.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tX96.hs, interpreted ) /tmp/tX96.hs:8:3: error: Variable not in scope: (&) :: t4 -> (a0 -> I a0) -> t3 /tmp/tX96.hs:9:3: error: Variable not in scope: (&) :: t3 -> t5 -> t2 /tmp/tX96.hs:10:3: error: Variable not in scope: (&) :: t2 -> (POP f1 xss0 -> [SOP f1 xss0]) -> t1 /tmp/tX96.hs:11:3: error: Variable not in scope: (&) :: t1 -> ([a1] -> a1) -> t0 /tmp/tX96.hs:12:3: error: Variable not in scope: (&) :: t0 -> (Rep a2 -> a2) -> a Failed, modules loaded: none. Prelude> }}} but crashes with `-fdefer-typed-holes` {{{ $ ghci -ignore-dot-ghci -fdefer-typed-holes -XTypeApplications -XTypeOperators -XDataKinds -XGADTs -XFlexibleContexts /tmp/tX96.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/tX96.hs, interpreted ) /tmp/tX96.hs:8:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t4 -> (a0 -> I a0) -> t3 /tmp/tX96.hs:9:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t3 -> t5 -> t2 /tmp/tX96.hs:10:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t2 -> (POP f1 xss0 -> [SOP f1 xss0]) -> t1 /tmp/tX96.hs:11:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t1 -> ([a1] -> a1) -> t0 /tmp/tX96.hs:12:3: warning: [-Wtyped-holes] Variable not in scope: (&) :: t0 -> (Rep a2 -> a2) -> a ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): opt_univ fell into a hole {aabX} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} ---- More minimal example, still requires [https://hackage.haskell.org/package /generics-sop-0.2.2.0 generics-sop]: {{{#!hs import Generics.SOP a = minBound & hcpure (Proxy @Bounded) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12616: type synonyms confuse generalized newtype deriving role checking
by GHC 18 Oct '16

18 Oct '16

#12616: type synonyms confuse generalized newtype deriving role checking -------------------------------------+------------------------------------- Reporter: daviddarais | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: generalized | Operating System: Unknown/Multiple newtype deriving roles rankntypes | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Below is a small Haskell file showing the problem. It defines a simple `MonadTrans` typeclass, but using a type operator `~>`. When using the type operator, GHC complains that generalized newtype deriving gets stuck on a nominal role, but when the type operator is not used then GND works just fine. Perhaps this is just expected behavior with mixing RankNTypes and GND (and roles), but it's rather unfortunate. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} module GND where type m ~> n = forall a. m a -> n a class MonadTrans t where -- > this line works: -- lift :: (Monad m) => m a -> t m a -- > this line doesn't: lift :: (Monad m) => m ~> t m data StateT s m a = StateT { runStateT :: s -> m (a, s) } instance MonadTrans (StateT s) where lift xM = StateT $ \ s -> do { x <- xM ; return (x,s) } newtype OtherStateT s m a = OtherStateT { runOtherStateT :: StateT s m a } deriving (MonadTrans) }}} The error message is: {{{ GND.hs:23:13: error: • Couldn't match representation of type ‘m1 ~> StateT s m1’ with that of ‘m1 a1 -> OtherStateT s m1 a1’ arising from a use of ‘GHC.Prim.coerce’ • In the expression: GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) In an equation for ‘lift’: lift = GHC.Prim.coerce (lift :: (~>) m (StateT s m)) :: forall (m :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). Monad m => (~>) m (OtherStateT s m) When typechecking the code for ‘lift’ in a derived instance for ‘MonadTrans (OtherStateT s)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘MonadTrans (OtherStateT s)’ • Relevant bindings include lift :: m ~> OtherStateT s m (bound at GND.hs:23:13) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11214: Remove JavaScriptFFI from --supported-extensions list
by GHC 18 Oct '16

18 Oct '16

#11214: Remove JavaScriptFFI from --supported-extensions list -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- GHC supports the `JavaScriptFFI` extension syntactically, but it just rejects all `foreign import javascript` declarations in the typechecker. Similar to the change in #11102 I think the proper thing to do is to make GHC say that `JavaScriptFFI` is not supported. Cabal 1.24 can then use this information in dependency resolution. GHCJS would then just add this to the list by itself, since it has its own front end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12044: Remove sortWith in favor of sortOn
by GHC 17 Oct '16

17 Oct '16

#12044: Remove sortWith in favor of sortOn -------------------------------------+------------------------------------- Reporter: cblp | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 2659 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is Data.List.sortOn that does the same as GHC.Exts.sortWith, and even seems to be more effective. GHC.Exts.sortWith should be deprecated or removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12044> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11108: Weak references related crash
by GHC 17 Oct '16

17 Oct '16

#11108: Weak references related crash ----------------------------------------+---------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I've been getting a Segmentation fault relating to Weak reference use as part of a FRP library (reflex). Attached is a more minimal example which crashes. With debugging on the original problem gave me these problems (on different runs): Most frequently just Segmentation fault (with no stack trace) Occasionally this: {{{ bench: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} and more rarely this: {{{ bench: internal error: WEAK object entered! (GHC version 7.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33