March 2017 - ghc-tickets

[GHC] #13309: Use liftA2 in ApplicativeDo
by GHC 16 May '17

16 May '17

#13309: Use liftA2 in ApplicativeDo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Now that `liftA2` is in `Applicative`, we want to be sure to use it when desugaring `ApplicativeDo`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13309> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13473: Variables in patterns made with QuasiQuotes sometimes don't get bound
by GHC 16 May '17

16 May '17

#13473: Variables in patterns made with QuasiQuotes sometimes don't get bound -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- In GHCi 8.0.2 {{{ >>> import Language.Haskell.TH >>> import Language.Haskell.TH.Quote >>> :set -XQuasiQuotes >>> quoter = QuasiQuoter { quotePat = varP . mkName } >>> [quoter|x|] = 1 >>> x error: Variable not in scope: x }}} I think "x" ought to be 1. Previous versions of GHCi don't let me be so free about defining and using quasiquotes, so here is a minimal example with modules: {{{ -- In QQ.hs module QQ where import Language.Haskell.TH import Language.Haskell.TH.Quote quoter :: QuasiQuoter quoter = QuasiQuoter { quotePat = varP . mkName } }}} and {{{ -- In Main1.hs module Main1 where import QQ [quoter|x|] = 1 main = print x }}} With GHC 7.10.3 this compiles (and prints "1" when run), but in GHC 8.0.2 this complains "x" is not in scope. The same problem manifests itself when the pattern quasi quote is used in a "let" binding. Peculiarly, this appears ''not'' to affect cases where the pattern is a function argument. The following compiles and runs (printing "1") on both 7.10.3 and 8.0.2. {{{ -- In Main2.hs module Main2 where import QQ f [quoter|x|] = x main = print (f 1) }}} I understand there were some changes around splices and declaration groups (which presumably are part of why GHCi plays with quasi quotes), so I'm not sure this is really a bug! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12600: Overloaded method causes insufficient specialization
by GHC 13 May '17

13 May '17

#12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | 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: -------------------------------------+------------------------------------- The `foo` function in the following code does not get specialized completely by `ghc -O2`, even though all the overloaded functions in the module are marked `INLINE`. Specifically, it gets compiled into a call to a function with an `Eq Int` dictionary passed at runtime. {{{#!hs module Foo where class Eq1 f where eq1 :: (Eq a) => f a -> f a -> Bool data F a = F !a !a data G f a = G !(f a) !(f a) instance Eq1 F where eq1 = \(F a b) (F c d) -> -- In order to reproduce the problem, the body of this function needs to be -- large enough to prevent GHC from voluntarily inlining it. larger $ larger $ larger $ larger $ larger $ larger $ a == c && b == d {-# INLINE eq1 #-} larger :: a -> a larger = id {-# NOINLINE larger #-} instance (Eq1 f) => Eq1 (G f) where eq1 = \(G a b) (G c d) -> eq1 a c && eq1 b d {-# INLINE eq1 #-} foo :: G F Int -> G F Int -> Bool foo a b = eq1 a b }}} Looking at the dumps, it looks like there may be a problem is the specializer. It creates a specialization of `eq1` with the type `(Eq a) => G F a -> G F a -> Bool` rather than the fully-specialized type: `G F Int -> G F Int -> Bool` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13346: Run nofib with -fspec-constr-keen
by GHC 13 May '17

13 May '17

#13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Per Ben Gamari's comment on https://phabricator.haskell.org/D3186, we should try running `nofib` with `-fspec-constr-keen`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | 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: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12962: No automatic SCC annotations for functions marked INLINABLE
by GHC 12 May '17

12 May '17

#12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- Judging from .prof files and the -xc and -prof callstacks, GHC adds no automatic SCC annotations for functions marked `INLINABLE`. The user's guide only mentions `INLINE`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h…, not `INLINABLE`. Is it a bug in documentation or implementation? In my case I managed to work around by using `-fexpose-all-unfoldings` instead of the tons of `INLINABLE` I was using before, but in general case, adding all the SCC annotations by hand seems prohibitive. e.g., in code that needs a lot of `INLINABLE` to enable specialization. Since `-fexpose-all-unfoldings` does not inhibit profiling and compiling with no optimization doesn't help recover it, the culprit is probably not the actual inlining or specialization, but rather handling of the `INLINABLE` pragma itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12962> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym
by GHC 12 May '17

12 May '17

#11964: Without TypeInType, inconsistently accepts Data.Kind.Type but not type synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- For convenience, I'll use GHCi to demonstrate flag behavior. First, we define a file: ``` {-# LANGUAGE TypeInType #-} import Data.Kind type Star = Type newtype T k (t :: k) = T () ``` Next, we load it up in GHCi, WITHOUT `-XTypeInType`. Now we observe strange behavior: ``` ezyang@sabre:~$ ghc-8.0 --interactive C.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( C.hs, interpreted ) Ok, modules loaded: Main. *Main> :k T Type Int T Type Int :: * *Main> :k T Star Int <interactive>:1:3: error: • Data constructor ‘Star’ cannot be used here (Perhaps you intended to use DataKinds) • In the first argument of ‘T’, namely ‘Star’ In the type ‘T Star Int’ ``` Of course, if we pass `-TypeInType` to GHCi that fixes the problem (BTW, `DataKinds` does NOT solve the problem.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11966: Surprising behavior with higher-rank quantification of kind variables
by GHC 12 May '17

12 May '17

#11966: Surprising behavior with higher-rank quantification of kind variables -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 (Type checker) | 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: -------------------------------------+------------------------------------- Sorry about the rubbish title. I wrote the following code, which type checks: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Test where import Data.Kind (Type) -- Simplification type family Col (f :: k -> j) (x :: k) :: Type -- Base types data PGBaseType = PGInteger | PGText -- Transformations data Column t = Column Symbol t newtype Nullable t = Nullable t newtype HasDefault t = HasDefault t -- Interpretations data Expr k data Record (f :: forall k. k -> Type) = Record {rX :: Col f ('Column "x" 'PGInteger) ,rY :: Col f ('Column "y" ('Nullable 'PGInteger)) ,rZ :: Col f ('HasDefault 'PGText)} }}} However, if I play with this in GHCI, I can get the following error: {{{ λ> let x = undefined :: Record Expr <interactive>:136:29-32: error: • Expected kind ‘forall k. k -> Type’, but ‘Expr’ has kind ‘forall k. k -> *’ • In the first argument of ‘Record’, namely ‘Expr’ In an expression type signature: Record Expr In the expression: undefined :: Record Expr }}} It seems that if I write {{{#!hs data Expr :: forall k. k -> Type }}} things work, but I'm unclear if/why that is necessary, and the error message certainly needs to be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11966> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon
by GHC 12 May '17

12 May '17

#12083: ghc-8.0.1-rc4: tyConRoles sees a TcTyCon -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc4 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: Yes. | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UnicodeSyntax #-} import Prelude.Unicode type Constrd a = Num a ⇒ a data ADT a = ADT (Constrd a) ExistentiallyLost data ExistentiallyLost = ∀ u. TC u ⇒ ExistentiallyLost u class u ~ (ATF1 u, ATF2 u) ⇒ TC u where type ATF1 u ∷ * type ATF2 u ∷ * uie_handlers ∷ ADT Int -- Loop: -- - ADT depends on ExistentiallyLost (also the Constrd appendage) -- - ExistentiallyLost depends on TC -- - TC depends on ADT }}} --> {{{ [1 of 1] Compiling Main ( /home/deepfire/src/ghc-testcases /tyconroles-sees-a-tctycon-tyalias.hs, interpreted ) <- ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160421 for x86_64-unknown-linux): tyConRoles sees a TcTyCon Constrd Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13271: GHC Panic With Injective Type Families
by GHC 12 May '17

12 May '17

#13271: GHC Panic With Injective Type Families ----------------------------------------+--------------------------------- Reporter: wayofthepie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following causes GHC to panic: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilyDependencies #-} module T where import GHC.TypeLits data T1 = T1 type T2 = TypeError (Text "You can't do that!") type family X i = r | r -> i where X 1 = T1 X 2 = T2 }}} {{{ $ ghc T.hs [1 of 1] Compiling T ( T.hs, T.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon T2 }}} This may be related to https://ghc.haskell.org/trac/ghc/ticket/11560. Without injectivity it gives the expected type error with the message "You can't do that!" {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} module T where import GHC.TypeLits data T1 = T1 type T2 = TypeError (Text "You can't do that!") type family X i where X 1 = T1 X 2 = T2 }}} {{{ $ ghc T.hs [1 of 1] Compiling T ( T.hs, T.o ) T.hs:9:1: error: • You can't do that • In the type synonym declaration for ‘T2’ }}} This isn't something anyone would intentionally write, as it could never type check with the type synonym T2 being a TypeError, but a panic is a panic so I said I'd raise it anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4