July 2017 - ghc-tickets

[GHC] #13980: Broken ghc-flag links in the users guide
by GHC 02 Aug '17

02 Aug '17

#13980: Broken ghc-flag links in the users guide -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- I'm working on cleaning up the users guide, and I have come across an issue with referencing ghc-flags. Essentially, it has to with flags that take arguments. You can see a couple examples if you go to the flag reference here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html #redirecting-output The top flags all have valid links, but the code to generate them is doing it slightly wrong. Let's consider `-o ⟨filename⟩` for instance. There needs to be a specific reference name for this flag. This name serves a couple purposes. First, it forms the end of the url (i.e. .../separate_compilation.html#ghc-flag--o). Second, the form of cross- references to it (i.e. {{{:ghc-flag:`-o`}}}). There are two options: Option 1 (The current system): We exclude the arguments from the reference name of the flag. So {{{:ghc- flag:`-o`}}} is a valid reference that gets rendered as __-o__. The main issue with this system is loss of information. If someone wanted to include the flags in the link, they would have to do {{{:ghc-flag:`-o ⟨filename⟩ <-o>`}}}, which would render as __-o ⟨filename⟩__ but link to the same place as __-o__. This also leads to possibly different choices for the argument name. In fact, the definition has `⟨file⟩` but the reference table has `⟨filename⟩`. Option 2: We include the arguments in the reference name. So to make the reference, one would have to match the definition exactly: {{{:ghc-flag:`-o ⟨file⟩`}}} which would be rendered as __-o ⟨file⟩__, and {{{:ghc-flag:`-o ⟨filename⟩`}}} would not be a valid reference. This solves the loss of information issue from option 1, but does require the person documenting to check for the exact argument wording. I would argue for the second option as it is more consistent, but either is workable. Also note that the current parser automatically converts < (less than) into ⟨, so dealing with special characters is very easy. And these issues also apply to flags that use '='. I thought it best to ask before I converted everything to one way of dealing with these. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue
by GHC 02 Aug '17

02 Aug '17

#12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{#!hs src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS
by GHC 02 Aug '17

02 Aug '17

#13981: Family instance consistency checks happens too early when hs-boot defined type occurs on LHS -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here: {{{ -- F.hs {-# LANGUAGE TypeFamilies #-} module F where type family F a :: * -- A.hs-boot module A where data T -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import {-# SOURCE #-} A import F type instance F T = Int -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import {-# SOURCE #-} A import F type instance F T = Bool -- A.hs module A where import B import C }}} From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check. But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary
by GHC 02 Aug '17

02 Aug '17

#14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #12369.) The documentation for data families currently [http://git.haskell.org/ghc.git/blob/791947db6db32ef7d4772a821a0823e558e3c05… claims]: {{{ - Data families have been generalised a bit: a data family declaration can now end with a kind variable ``k`` instead of ``Type``. Additionally, data/newtype instance no longer need to list all the patterns of the family if they don't wish to; this is quite like how regular datatypes with a kind signature can omit some type variables. }}} Moreover, the commit which added this (4239238306e911803bf61fdda3ad356fd0b42e05) cites this particular example: {{{#!hs data family Sing (a :: k) data instance Sing :: Bool -> Type where ... }}} However, in practice, this does //not// typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import Data.Kind data family Sing (a :: k) data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170725: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:8:1: error: • Number of parameters must match family declaration; expected 0 • In the data instance declaration for ‘Sing’ | 8 | data instance Sing :: Bool -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #13327: Figure out how to make sense of Data instances for poly-kinded datatypes
by GHC 02 Aug '17

02 Aug '17

#13327: Figure out how to make sense of Data instances for poly-kinded datatypes -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4028 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Something's funny with `Data.Data`. In particular, what instance do you expect when you write this? {{{#!hs data T phantom = T deriving Data }}} You might expect: {{{#!hs instance Typeable phantom => Data (T phantom) where ... }}} And indeed, it is possible to define a `Data` instance like this. But in practice, GHC actually derives this instance: {{{#!hs instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f }}} The reason is because GHC has special cases for when it derives `Data` instances for datatypes of kind `* -> *` or `* -> * -> *`. These special cases cause the derived `Data` instances to insert definitions for `dataCast1` or `dataCast2`, respectively, and their implementations (`gcast1` or `gcast2`, respectively) require the stronger instance context. See #4028 for a longer discussion about this. Things get far less predictable when you throw in `PolyKinds`, however. If you try this instead: {{{#!hs data T (phantom :: k) = T deriving Data }}} Then you do //not// get `instance Data phantom => Data (T phantom)` as above. Instead, you get this: {{{#!hs instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 }}} As it turns out, GHC's special-casing for deriving `Data` is not privy to datatypes of kind `k -> *` or `k1 -> k2 -> *`, just `* -> *` and `* -> * -> *`. This is all a bit disconcerting because if you look at `Data.Data`, there are many instances of the flavor: {{{#!hs deriving instance Data (p :: *) => Data (U1 p) -- U1 :: k -> * }}} This makes sense in a pre-`PolyKinds` world, but really, the most general type for this `Data` instance would be: {{{#!hs deriving instance (Typeable k, Typeable (p :: k)) => Data (U1 p) }}} Even worse, choosing the less polymorphic instance `Data (p :: *) => Data (U1 p)` via `StandaloneDeriving` doesn't even cause GHC to emit a definition for `dataCast1`—it just restricts the kind with no benefit! This whole situation doesn't sit well with me, especially since as we add more poly-kinded `Data` instances to `Data.Data`, we have to ask ourselves each time what the "right" `Data` instance is. It would be great if we could answer these questions: 1. Should we expand the special-casing for datatypes of kind `k -> *` or `k1 -> k2 -> *`? Or do `dataCast1` and `dataCast2` even make sense for poly-kinded datatypes? 2. Is there a way to modify `DeriveDataTypeable` such that emitting definitions for `dataCast1` and `dataCast2` don't require us to default some kind variables to `*`? Perhaps `TypeInType` could help us here somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened"
by GHC 01 Aug '17

01 Aug '17

#14063: Compiling with --backpack with undefined dependency results in "the 'impossible' happened" -------------------------------------+------------------------------------- Reporter: rcook | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC 8.2.1: {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 }}} And compiling with `--backpack` as follows: {{{ > ghc --backpack foo.bkp [1 of 4] Processing foo-indef [1 of 2] Compiling Str[sig] ( foo-indef\Str.hsig, nothing ) [2 of 2] Compiling Foo ( foo-indef\Foo.hs, nothing ) [2 of 4] Processing foo-string Instantiating foo-string [1 of 1] Compiling Str ( foo-string\Str.hs, foo- string\Str.o ) [3 of 4] Processing foo-int Instantiating foo-int [1 of 1] Compiling Str ( foo-int\Str.hs, foo-int\Str.o ) [4 of 4] Processing main ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): no package name CallStack (from HasCallStack): error, called at compiler\backpack\DriverBkp.hs:573:32 in ghc:DriverBkp Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [foo-indef/Foo.hi] Error 1 }}} See attached `foo.bkp` file. While the Backpack file ''is'' invalid, in that the `main` unit mentions the `foo` dependency, which does not exist, this shouldn't lead to a GHC panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14063> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14058: Cannot bundle pattern synonym with exported data family
by GHC 01 Aug '17

01 Aug '17

#14058: Cannot bundle pattern synonym with exported data family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd like to write this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Foo (Sing(.., SCons)) where data family Sing (a :: k) data instance Sing (z :: [a]) where SNil :: Sing '[] (:%) :: Sing x -> Sing xs -> Sing (x:xs) pattern SCons :: forall a (z :: [a]). () => forall (x :: a) (xs :: [a]). z ~ (x:xs) => Sing x -> Sing xs -> Sing z pattern SCons x xs = (:%) x xs {-# COMPLETE SNil, SCons #-} }}} But alas, GHC will not let me: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Bug.hs, interpreted ) Bug.hs:7:13: error: • Pattern synonyms can be bundled only with datatypes. • In the pattern synonym: SCons In the export: Sing(.., SCons) | 7 | module Foo (Sing(.., SCons)) where | ^^^^^^^^^^^^^^^ Failed, 0 modules loaded. }}} Can this restriction be lifted for data families? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13731: DeriveFunctor and friends don't understand type families
by GHC 01 Aug '17

01 Aug '17

#13731: DeriveFunctor and friends don't understand type families -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 DeriveFunctor #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} data Test ext a where Foo :: a -> Test ext a Extend :: (ExtensionType ext a) -> Test ext a type family ExtensionType ext a data ListExtension type instance ExtensionType ListExtension a = [a] deriving instance Functor (Test ListExtension) {- a.hs:15:1: error: • Can't make a derived instance of ‘Functor (Test ListExtension)’: Constructor ‘Extend’ must use the type variable only as the last argument of a data type • In the stand-alone deriving instance for ‘Functor (Test ListExtension)’ | 15 | deriving instance Functor (Test ListExtension) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, modules loaded: none. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors
by GHC 01 Aug '17

01 Aug '17

#13403: Derive instances (Applicative, Monad, ...) for structures lifted over functors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) 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: -------------------------------------+------------------------------------- I'll start small: Given that we know how to define various instances for [https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-Functor- Product.html Product] GHC could do it automatically. {{{#!hs data P f g a = f a ::: g a deriving (Functor, Applicative, Alternative) {- instance (Applicative f, Applicative g) => Applicative (P f g) where pure x = pure x ::: pure x (f:::g) <*> (x:::y) = (f <*> x) ::: (g <*> y) -} }}} And for specific constructors as well {{{#!hs data Q a = [a] :*: Maybe a deriving (Functor, Applicative, Alternative) {- instance Applicative Q where pure x = [x] :*: Just x (f:*:g) <*> (x:*:y) = (f <*> x) :*: (g <*> y) -} }}} == Alternative == Use `GeneralizedNewtypeDeriving` {{{#!hs newtype Q a = Q (Product [] Maybe a) deriving (Functor, Applicative, Alternative) pattern (:*:) :: [a] -> Maybe a -> Q a pattern a :*: b = Q (Pair a b) }}} == Future Work == This should work for a combination of various things, using `Const _` deprives us of `Alternative` {{{#!hs newtype U e a = U (([] `Product` Maybe `Product` Const e) a) deriving (Functor, Applicative) }}} using sums where [https://hackage.haskell.org/package/transformers-0.5.4.0/docs/Control- Applicative-Lift.html one summand is identity] gives us `Applicative` / `Alternative` {{{#!hs -- data Lift f a = Pure a | Other (f a) import Control.Applicative.Lift data V a = V ((Lift [] `Product` Maybe) a) deriving (Functor, Applicative, Alternative) }}} I want to be able to write this directly {{{#!hs data U e a = U [a] (Maybe a) (Const e a) deriving (Functor, Applicative) data V a = VL a (Maybe a) | VR [a] (Maybe a) deriving (Functor, Applicative, Alternative) }}} == Future, Future Work == [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Data- Functor-Kan-Lan.html left-Kan extension] {{{#!hs data Lan g h a where Lan :: (g b -> a) -> h b -> Lan g h a deriving (Functor, Applicative) }}} [https://hackage.haskell.org/package/kan-extensions-5.0.1/docs/Control- Monad-Codensity.html codensity] {{{#!hs data Endo a = Endo (a -> a) newtype CodEndo a = CE (forall xx. (a -> Endo xx) -> Endo xx) deriving (Functor, Applicative, Monad) }}} and [https://hackage.haskell.org/package/free-4.12.4/docs/Control-Comonad- Cofree.html comonad] {{{#!hs data Rose a = a :< [Rose a] deriving (Functor, Applicative, Monad, Comonad, ...) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9522: SPECIALISE pragmas for derived instances
by GHC 01 Aug '17

01 Aug '17

#9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4