November 2018 - ghc-tickets

[GHC] #15793: Type family doesn't reduce with visible kind application
by GHC 16 Jan '19

16 Jan '19

#15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we un-comment `f2` {{{#!hs {-# Language RankNTypes #-} {-# Language TypeFamilies #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} import Data.Kind type family F1 (a :: Type) :: Type where F1 a = Maybe a f1 :: F1 a f1 = Nothing type family F2 :: forall (a :: Type). Type where F2 @a = Maybe a -- f2 :: F2 @a -- f2 = Nothing }}} this program fails with {{{ • Couldn't match kind ‘forall a1. *’ with ‘* -> *’ When matching types F2 :: forall a. * Maybe :: * -> * Expected type: F2 Actual type: Maybe a • In the expression: Nothing In an equation for ‘f2’: f2 = Nothing | 20 | f2 = Nothing | ^^^^^^^ Failed, no modules loaded. }}} It also succeeds replacing `Nothing` with `undefined` {{{#!hs f2 :: F2 @a f2 = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15793> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15807: GHC panic with visible kind applications
by GHC 16 Jan '19

16 Jan '19

#15807: GHC panic with visible kind applications ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeApplications | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Using the https://phabricator.haskell.org/D5229 diff This is '''fine''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: Type -> Type). Type -> Type where MkApp :: f a -> App @f a }}} Kind polymorphic is '''fine''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall k (f :: k -> Type). k -> Type where MkApp :: f a -> App @k @(f :: k -> Type) (a :: k) }}} But offing the visibility of `k` '''fails''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: k -> Type). k -> Type where MkApp :: f a -> App @(f :: k -> Type) (a :: k) }}} {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: k -> Type). k -> Type where MkApp :: f a -> App @f a }}} {{{ $ ghci -ignore-dot-ghci 581_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 581_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! 2 1 f_a1yB[tau:1] f_a1yx[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:778:54 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15797: GHC panic using visible kind application
by GHC 16 Jan '19

16 Jan '19

#15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language TypeFamilies #-} {-# Language ScopedTypeVariables #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind class Ríki (obj :: Type) where type Obj :: obj -> Constraint type Obj = Bæ @obj class Bæ (a :: k) instance Bæ @k (a :: k) data EQ :: forall ob. ob -> ob -> Type where EQ :: EQ a a instance Ríki (EQ @ob) }}} {{{ $ ghci -dcore-lint 568_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 568_bug.hs, interpreted ) WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {ob_a1zs co_a1zt} tenv [] cenv [a1zt :-> co_a1zt] tys [Bæ] cos [] needInScope [a1zn :-> co_a1zn, a1zs :-> ob_a1zs] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error <no location info>: warning: In the type ‘Bæ’ Unfilled coercion hole: {co_a1zn} <no location info>: warning: In the type ‘Bæ’ co_a1zn :: (ob_a1zs -> ob_a1zs -> *) ~# * [LclId[CoVarId]] is out of scope Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15797> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15798: Flag to warn when deriving strategy is not explicitly specified
by GHC 16 Jan '19

16 Jan '19

#15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In my code, I aim to always specify deriving strategies. I would like to add a flag `-fwarn-unspecified-deriving` that would cause a warning to be emitted when someone wrote this: {{{ newtype Foo = Foo Int deriving (Show) }}} The user would be required to instead write: {{{ newtype Foo = Foo Int deriving newtype (Show) }}} Or they could use `stock` if that was the behavior they wanted. This flag would be off by default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15779: Follow-ups to D5169
by GHC 16 Jan '19

16 Jan '19

#15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simonmar points out that there are a few follow-up tasks after Phab:D5169: > > 1. We should build these at installation time, so they don't have to go into the binary distribution (the same goes for the vanilla way` libHSfoo.o` files) > 2. This also needs to be done in Hadrian > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15360: Template Haskell splicing drops lots of type arguments
by GHC 16 Jan '19

16 Jan '19

#15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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 conversion functions (in the `Convert` module) drop type arguments in various places. Here are two examples: {{{ data T a b c = Mk a b c bar :: $( return $ AppT (InfixT (ConT ''Int) ''T (ConT ''Bool)) (ConT ''Double) ) bar = Mk 5 True 3.14 }}} This correct code leads to an error {{{ Expecting one more argument to ‘T Int Bool’ }}} because the `Double` is forgotten. Similarly, {{{ baz :: $( return $ AppT (ParensT (ConT ''Maybe)) (ConT ''Int) ) baz = Just 5 }}} fails because `baz :: (Maybe)` isn't valid. On the other hand, {{{ frob :: forall (a :: $( [t| * Int |] )). a -> a frob x = x }}} is spuriously accepted, because GHC has forgotten about the `Int` argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns.
by GHC 15 Jan '19

15 Jan '19

#13648: ApplicativeDo selects "GHC.Base.Monad.return" when actions are used without patterns. -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 Keywords: | 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: -------------------------------------+------------------------------------- GHC 8.0.2 and 8.2.1-rc1 (rc2 not checked) have a bug where -XApplicativeDo causes "GHC.Base.Monad.return" to be used instead of the locally available "return", and a spurious "return ()" shows up. This desugaring is not adhering to the -XRebindableSyntax spec (see: #12490). Example: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RebindableSyntax #-} -- Bug vanishes if this next line is removed: {-# LANGUAGE ApplicativeDo #-} module Main where import Prelude (String, print) class MyFunctor f where fmap :: (a -> b) -> f a -> f b class MyApplicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b class MyMonad m where return :: a -> m a (>>) :: m a -> m b -> m b (>>=) :: m a -> (a -> m b) -> m b fail :: String -> m a join :: m (m a) -> m a testCase1 m1 m2 = do m1 m2 return () testCase2 m1 m2 = do _ <- m1 _ <- m2 return () main = print "42" }}} {{{ :t testCase1 testCase1 :: (MyFunctor f, MyApplicative f, MyMonad f, Monad f) => f a2 -> f a1 -> f () :t testCase2 :: testCase2 :: (MyFunctor f, MyApplicative f) => f t -> f a -> f () }}} The desugaring for testCase1 shows the issue: {{{#!hs testCase1' m1 m2 = (<*>) (fmap (\() () -> ()) (m1 >> (GHC.Base.Monad.return ()))) (m2 >> (GHC.Base.Monad.return ())) -- or: testCase1' m1 m2 = (fmap (\() () -> () ) (m1 >> (return ()))) <*> (m2 >> (return ())) }}} I would be able to work on this if someone pointed me in the right direction. It looks like it would be in `compiler/rename/RnEnv` and `compiler/rename/RnExpr`, as with #12490? As a proposed fix, I would want to implement a limited-scope fix before the 8.2.1 release which would not address the thornier issue of #10892. The patch would: 1. Replace `GHC.Base.Monad.return` with local `pure`, removing the `Monad` constraint. 2. Replace `>>` with `*>`, removing the `MyMonad` constraint. This isn't a _complete_ fix, as this would still induce an unnecessary use of the local `fmap`, but it would reduce the desugaring bug in `testCase1` to only that local `fmap`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type
by GHC 14 Jan '19

14 Jan '19

#15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DerivingVia #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Functor.Const (Const(..)) import GHC.Exts (Any) newtype Age = MkAge Int deriving Eq via Const Int Any }}} This fails to compile with a spectacularly unhelpful error message: {{{ $ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Derived instances ==================== Derived class instances: instance GHC.Classes.Eq Bug.Age where (GHC.Classes.==) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes.==) :: Bug.Age -> Bug.Age -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes./=) :: Bug.Age -> Bug.Age -> GHC.Types.Bool Derived type family instances: Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful | 9 | deriving Eq | ^^ }}} There are two things that are strange here: * Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors. * It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`: {{{#!hs newtype Age = MkAge Int deriving Eq via Const Int (Any :: k) }}} //Then// it's rejected properly: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’ but is not mentioned in the derived class ‘Eq’, which is illegal | 9 | deriving Eq | ^^ }}} Something about implicit quantification must be sneaking by this validity check. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15831> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15010: Application (warp) server crashing periodically with "TSO object entered"
by GHC 14 Jan '19

14 Jan '19

#15010: Application (warp) server crashing periodically with "TSO object entered" -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We are seeing one of our warp servers periodically crash with the following error: {{{ Apr 06 10:44:28 stdouterr.log: binary-name-elided: internal error: TSO object entered! Apr 06 10:44:28 stdouterr.log: (GHC version 8.0.2 for x86_64_unknown_linux) }}} We are sometimes seeing CPU/memory spikes concurrently with this error, but not always. We are running very similar servers for other applications and they are '''not''' experiencing this error. But this server is one of our highest- load ones. Other tickets I found with this error: * https://ghc.haskell.org/trac/ghc/ticket/12383 * https://ghc.haskell.org/trac/ghc/ticket/8316 But these seem to be happening in ghci and ghc itself, not in a binary compiled by ghc. Questions I have: * What exactly is this error? * Is there anything else we can do on our side to help debug? Any artifacts that should be produced upon crash? * Should we consider upgrading our GHC version from 8.0.2 to get a bugfix? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14645: Allow type family in data family return kind
by GHC 14 Jan '19

14 Jan '19

#14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC currently allows {{{#!hs data family DF1 :: k1 -> k2 }}} where it's expected (and checked) that all data ''instances'' have a return kind of `Type`. (Perhaps `k2` expands to `Type -> Type`, for example.) However, it rejects {{{#!hs type family TF (x :: Type) :: Type data family DF2 :: x -> TF x }}} when that's clearly just as sensible as the first definition. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12