December 2018 - ghc-tickets

[GHC] #15721: Command `:show bindings` throws exception for bindings without `let`
by GHC 17 Jan '19

17 Jan '19

#15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The command `:show bindings` works for `let a = 1`: {{{#!hs Prelude> let a = 1 Prelude> :show bindings a :: Num p => p = _ }}} But not for `a = 1`: {{{#!hs Prelude> a = 1 Prelude> :show bindings ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above. ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above. $trModule :: GHC.Types.Module = _ $trModule1 :: GHC.Types.TrName = _ $trModule2 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule2_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org $trModule3 :: GHC.Types.TrName = _ $trModule4 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule4_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org a :: Num p => p = _ a1 :: Integer = _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16059: checkValidType is defeated by a type synonym
by GHC 17 Jan '19

17 Jan '19

#16059: checkValidType is defeated by a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC throws an error message on this code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where f :: forall b (a :: Eq b => b). Int f = 42 }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181211: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:6: error: • Illegal constraint in a kind: Eq b => b • In the type signature: f :: forall b (a :: Eq b => b). Int | 6 | f :: forall b (a :: Eq b => b). Int | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, it does //not// throw an error message if you hide `Eq b => b` behind a type synonym, as the following variant of the code above is accepted: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where type Foo b = Eq b => b f :: forall b (a :: Foo b). Int f = 42 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #16114: strange "instance .. => .. => .. where ..."
by GHC 17 Jan '19

17 Jan '19

#16114: strange "instance .. => .. => .. where ..." -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 don't understand what's happening here: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Prelude> data T a Prelude> instance Eq a => Eq a => Eq (T a) where (==) = undefined <interactive>:2:10: error: • Class ‘Eq’ does not have a method ‘==’ • In the instance declaration for ‘Eq (T a)’ }}} Is that even syntactically correct? (ghc-8.4.4 says "malformed instance") If so, then I'd assume that `A => B => C` means `A && B => C`, that is, `(A,B) => C` in this case, but it does not, since this works: {{{ instance (Eq a, Eq a)=> Eq (T a) where (==) = undefined }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16116: Explicit foralls in associated type family equations are oblivious to class-bound variables
by GHC 17 Jan '19

17 Jan '19

#16116: Explicit foralls in associated type family equations are oblivious to class-bound variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- This doesn't typecheck on GHC HEAD: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a b instance C (Maybe a) where type forall b. T (Maybe a) b = Either a b }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: The RHS of an associated type declaration mentions out-of-scope variable ‘a’ All such variables must be bound on the LHS | 9 | type forall b. T (Maybe a) b = Either a b | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But it ought to. `a` isn't out of scope at all—it's bound by the class head `instance C (Maybe a)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16096: let x = ... and x = ... are not the same in GHCi
by GHC 17 Jan '19

17 Jan '19

#16096: let x = ... and x = ... are not the same in GHCi -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 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 #7253 we implemented support for `x = ...` in GHCi which is supposed to do the same thing as `let x = ...`, but they're currently different, as observed in #16089, #15721, and probably in other tickets. Here's a reproducer: {{{ ~ $ ghci -ddump-bcos GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help ... λ:1> let x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO ExprTopLevel_E0#0 []: let sat_s1vF = ... in ... bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 PUSH_L 0 PUSH_G GHC.Types.True PACK : 2 PUSH_G GHC.Types.[] PUSH_L 1 PACK : 2 PUSH_L 0 PUSH_APPLY_P PUSH_G GHC.Base.returnIO SLIDE 3 3 ENTER λ:2> x = [True,False] ==================== Proto-BCOs ==================== ProtoBCO x1_r1wJ#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.False (GHC.Types.[] @ GHC.Types.Bool) bitmap: 0 [] PUSH_G GHC.Types.[] PUSH_G GHC.Types.False PACK : 2 ENTER ProtoBCO Ghci2.x#0 []: GHC.Types.: @ GHC.Types.Bool GHC.Types.True x1_r1wJ bitmap: 0 [] PUSH_G x1_r1wJ PUSH_G GHC.Types.True PACK : 2 ENTER ... }}} Expected behavior: these two should generate the same byte code, and should be subject to same checks (e.g. for shadowing). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15905: Data familes should end in Type
by GHC 17 Jan '19

17 Jan '19

#15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Currently we allow {{{ data family Fix (f :: Type -> k) :: k }}} with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`. That seems attractive because we can then have {{{ data instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x) }}} But what about this? {{{ type family F a type instance F Int = Type -> Type data instance Fix (f :: Type -> F Int) (x :: Type) = … }}} The type inference engine (tcInferApps) will type the LHS as something like {{{ ((Fix (f :: Type -> F Int)) |> co1) (x |> co2) where co1 :: F Int ~ Type co2 :: Type ~ F Int }}} But the LHS of a family axiom has to look like {{{ F t1 t2 … tn }}} not {{{ ((F t1 |> co) t2 t3) |> co4) …tn }}} with casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh! And indeed GHC HEAD does accept the first, but rejects the second with the error message {{{ • Expected kind ‘* -> * -> *’, but ‘f :: Type -> F Int’ has kind ‘* -> F Int’ • In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’ In the data instance declaration for ‘Fix’ }}} That's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely how it happens, but it must be fragile: a change in solve order, or more aggressive solving might change the behaviour. I don't see how to solve this. I propose instead to require data family kinds to end in `Type`, not in a type ''variable'' (as we currently allow). I don't know how many people that would affect, but the current state of affairs looks untenable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15873: move to llvm 7 for 8.8.1
by GHC 17 Jan '19

17 Jan '19

#15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide"
by GHC 17 Jan '19

17 Jan '19

#15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: haddock | 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 often a bit annoyed that I cannot browse the haddocks for internal libraries. It would be nice if `base`, `ghc-prim`, `integer-gmp` and `integer-simple` could follow the example of `containers` and other libraries and offer docs for internal libraries too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13191: Make liftA2 a method of Applicative
by GHC 16 Jan '19

16 Jan '19

#13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3031 | Wiki Page: -------------------------------------+------------------------------------- Some functors support implementations of `liftA2` that are considerably faster than the usual definition. Furthermore, some people see `liftA2` as more intuitive and fundamental to the idea of `Applicative` than `<*>` is. This has been discussed on the libraries list in https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and (as an official proposal) in https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. All who expressed an opinion favored the proposal. One (David Menendez) specified that his support was weak. The others (Conal Elliot, Kris Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either supported the proposal strongly or merely indicated they were "+1". Conal Elliot wrote: [[BR]] [[BR]] > +1. > > I also sometimes define a specialized `liftA2` and then use it to define > `(<*>)`, which then gets used to define the real `liftA2`. > > I think of `liftA2` as playing a role similar to `foldMap` and `traverse`, while > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- compose > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > `traverse.traverse.traverse`. With functor composition, it's so much nicer to > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and `Traversable`) > rather than `liftA2 (<*>)`. [[BR]] Wren Romano wrote [[BR]] [[BR]] > I'm also all for adding liftA2 to the class and have noticed this > inefficiency/asymmetry when working on the class hierarchies for other > languages [[BR]] Kris NuttyCombe wrote [[BR]] [[BR]] > I'm in favor of this change. From my perspecive, liftA2 is actually the > fundamental Applicative operation, an <*> is merely a convenient > isomorphism. When I'm teaching, showing the symmetry between the following > always seems to help students: > > fmap :: (a -> b) -> f a -> f b > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > flip (>>=) :: (a -> f b) -> f a -> f b > > <*> is obviously exceptionally useful in practice. But liftA2 seems like the > more essential shape of that operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16101: Write a nix expression to enter a shell with specified build artifact
by GHC 16 Jan '19

16 Jan '19

#16101: Write a nix expression to enter a shell with specified build artifact -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It should be quite straightforward to write a nix expression which is parameterised by a CI job which downloads the artifact and enters into a nix shell which provisions that version of GHC. To be precise, consider the recent job: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427. It built these artifacts: https://gitlab.haskell.org/ghc/ghc/-/jobs/6427/artifacts/browse We should download the bindist and patch it suitably so it works like a normal GHC release. Some inspiration can probably be drawn from the scripts that Ben wrote for the head.hackage repo: https://github.com/hvr/head.hackage/blob/master/default.nix -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1