October 2018 - ghc-tickets

[GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes.
by GHC 18 Oct '18

18 Oct '18

#15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: User Guide | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the user guide section on [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.ht… #ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9 `-rtsopts`] specifies that `-rtsopts=some` is the default setting in the text under it, while the specified default is `all`. Happy to submit a patch if someone can confirm that `all` is actually the default, and that I'm not misunderstanding the meaning here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15771: Could there be further refactoring to the `seq` typing rule
by GHC 18 Oct '18

18 Oct '18

#15771: Could there be further refactoring to the `seq` typing rule -------------------------------------+------------------------------------- Reporter: aspiwack | 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: -------------------------------------+------------------------------------- Seq has a special cased typing rule. It's been greatly simplified in aab3c6d18416b3bc8e1378dfc4d485a9307ca5c7 . But there is still duplication, with a different rule applying when `seq` is used in infix position (unchanged in that commit), and when used in prefix position. Could there be a way to reduce code duplication here? I find it really hard to convince myself that both cases do the same thing. Though, really, given levity polymorphism, does `seq` need a special typing rule at all anymore? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15771> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15680: Flag for printing absolute paths in diagnostics
by GHC 18 Oct '18

18 Oct '18

#15680: Flag for printing absolute paths in diagnostics -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- Currently, GHC will produce errors and warnings with relative paths pointing to the input that caused it. This is less than ideal for any tooling consuming these diagnostics, because build tools will concurrently build many packages in different working directories and interleave the output from multiple GHC invocations. In particular, this makes using `next-error` in emacs a lot less useful than it could be with cabal-install's output. [https://github.com/commercialhaskell/stack/blob/0740444175f41e6ea5ed236cd2c… Stack has some rather hackish code to post-process the diagnostics and to turn the relative paths absolute.] I can personally report that this makes the development process a lot more pleasant! I think it'd be much cleaner to have a GHC flag for this at the source. `-fabsolute-diagnostic-paths` or something similar, subject to bikeshedding. I had a look at implementing this myself, and `mkLocMessageAnn` in `ErrUtils` would be the locus of the change. However, I can't figure out how that function should learn what the current working directory is! Any tips? Is that information lurking somewhere in `DynFlags`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types
by GHC 17 Oct '18

17 Oct '18

#15766: GeneralizedNewtypeDeriving should support classes with ambiguous types -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- The following module has a class with an ambiguous type: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Ambig where class C a where c :: Int data A = A instance C A where c = 5 newtype B = B A deriving C }}} Thanks to TypeApplications, this typeclass is still usable. However, GeneralizedNewtypeDeriving fails on it: {{{ Ambig.hs:12:26: error: • Ambiguous type variable ‘a0’ arising from a use of ‘c’ prevents the constraint ‘(C a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance C A -- Defined at Ambig.hs:10:10 instance C B -- Defined at Ambig.hs:12:26 • In the third argument of ‘GHC.Prim.coerce’, namely ‘c’ In the expression: GHC.Prim.coerce @(Int) @(Int) c In an equation for ‘c’: c = GHC.Prim.coerce @(Int) @(Int) c When typechecking the code for ‘c’ in a derived instance for ‘C B’: To see the code I am typechecking, use -ddump-deriv | 12 | newtype B = B A deriving C | }}} It shouldn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15763: GHC forbids kind signatures in data family instances
by GHC 17 Oct '18

17 Oct '18

#15763: GHC forbids kind signatures in data family instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- If I say {{{#!hs class C (a :: k) instance (C :: Type -> Constraint) a }}} GHC is happy. Note that this is actually useful to do. But if I say {{{#!hs data family D (a :: k) data instance (D :: Type -> Type) a }}} GHC is unhappy: {{{ Malformed head of type or class declaration: (D :: Type -> Type) a }}} Fixing this will require a change to the `FamEqn` type, which doesn't have enough flexibility to deal with a kind signature there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15692: GHC panic from pattern synonyms + deferred type errors
by GHC 17 Oct '18

17 Oct '18

#15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, PatternSynonyms, GADTs #-} {-# Options_GHC -dcore-lint -fdefer-type-errors #-} import Data.Kind data Ctx :: Type -> Type where E :: Ctx(Type) (:&:) :: a -> Ctx(as) -> Ctx(a -> as) data ApplyT (k::Type) :: k -> Ctx(k) -> Type where AO :: a -> ApplyT(Type) a E AS :: ApplyT(ks) (f a) ctx -> ApplyT(k -> ks) f (a:&:ctx) pattern ASSO = AS (AS (AO False)) }}} {{{ $ ghci -ignore-dot-ghci 463.hs hs/463.hs:16:27: warning: [-Wdeferred-type-errors] • Couldn't match type ‘a a1 a2’ with ‘Bool’ Expected type: a3 Actual type: Bool • In the pattern: False In the pattern: AO False In the pattern: AS (AO False) | 16 | pattern ASSO = AS (AS (AO False)) | ^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): urk! lookup local fingerprint $mASSO [iESflb :-> ($trModule, 1ca40dc83a9c879effdb760462cc9a2d), iESgKD :-> ($tc'E, 79f67a27a14dc1bb6eecb39e4b061e2c), iESgKF :-> ($tc':&:, 24793c0c1652ffcf92e04f47d38fa075), iESgKH :-> ($tcCtx, a3f9358cbfe161bf59e75500d70ce0ae), iESgKI :-> ($tc'AO, 72111d1891cb082e989c20a2191a8b4b), iESgKK :-> ($tc'AS, ff019c04c400d5fbdd46ff8a816d4913), iESgKM :-> ($tcApplyT, cbfe28374b4115925c7213e6330ab115)] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15761: pprFamInstLHS drops parentheses
by GHC 17 Oct '18

17 Oct '18

#15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- If I say {{{#!hs data family (a + b) c d data instance (Int + Bool) Double = Float }}} GHC says {{{ • Expecting one more argument to ‘Int + Bool Double’ Expected a type, but ‘Int + Bool Double’ has kind ‘* -> *’ • In the data instance declaration for ‘+’ }}} Note the missing parens in the first line of the error. Will fix shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11307: Regresssion: parsing type operators
by GHC 17 Oct '18

17 Oct '18

#11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15759: GHC doesn't use fixity in type instances
by GHC 17 Oct '18

17 Oct '18

#15759: GHC doesn't use fixity in type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- If I say {{{#!hs data a * b infixl 7 * type family a + b infixl 6 + type instance Int * Bool + Double = Float }}} (with `-XNoStarIsType` -- `*` is not the issue here) I get {{{ • Illegal family instance for ‘*’ (* is not an indexed type family) • In the type instance declaration for ‘*’ }}} But that's wrong. The `*` should bind tighter than the `+`, meaning this is an instance for `+`, not `*`. This also fails for closed type families: {{{#!hs data a * b infixl 7 * type family a + b where Int * Bool + Double = Float infixl 6 + }}} Interestingly, a ''class'' instance works here. This did not bite me "in the wild", but came up while reading the GHC source code. Still, it is a real bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15756: The "-fcontext-stack=N" GHC flag is not documented
by GHC 17 Oct '18

17 Oct '18

#15756: The "-fcontext-stack=N" GHC flag is not documented -------------------------------------+------------------------------------- Reporter: terrorjack | 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: -------------------------------------+------------------------------------- Currently, there isn't an entry for the `-fcontext-stack=N` flag in the [Flag reference](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/… section of GHC documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1