July 2018 - ghc-tickets

[GHC] #14185: Non-local bug reporting around levity polymorphism
by GHC 27 Jul '18

27 Jul '18

#14185: Non-local bug reporting around levity polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, | TypeErrorMessages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From comment:12:ticket:13105. In HEAD (or, at least, my version, on the `wip/rae` branch), this code {{{#!hs class Unbox (t :: *) (r :: TYPE k) | t -> r, r -> t where unbox :: t -> r box :: r -> t instance Unbox Int Int# where unbox (I# i) = i box i = I# i instance Unbox Char Char# where unbox (C# c) = c box c = C# c instance (Unbox a a', Unbox b b') => Unbox (a,b) (# a', b' #) where unbox (a,b) = (# unbox a, unbox b #) box (# a, b #) = (box a, box b) testInt :: Int testInt = box (unbox 1) testTup :: (Int, Char) testTup = box (unbox (1, 'a')) }}} fails with {{{ Bug.hs:27:11: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the expression: box (unbox 1) In an equation for ‘testInt’: testInt = box (unbox 1) | 27 | testInt = box (unbox 1) | ^^^^^^^^^^^^^ Bug.hs:27:16: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the first argument of ‘box’, namely ‘(unbox 1)’ In the expression: box (unbox 1) In an equation for ‘testInt’: testInt = box (unbox 1) | 27 | testInt = box (unbox 1) | ^^^^^^^ Bug.hs:42:11: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the expression: box (unbox (1, 'a')) In an equation for ‘testTup’: testTup = box (unbox (1, 'a')) | 42 | testTup = box (unbox (1, 'a')) | ^^^^^^^^^^^^^^^^^^^^ }}} I think it should succeed. Worse, when I comment out the `testTup` definition, the file succeeds... but note that two of the errors above are in `testInt`, which compiles fine on its own. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14627: qAddTopDecls: can't convert top-level declarations
by GHC 27 Jul '18

27 Jul '18

#14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program crashes 8.2.2 and HEAD (8.5.20171228). {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax (addTopDecls) $(do ds <- [d| f = Bool |] addTopDecls ds [d| g = cab |]) }}} Output: {{{ Exception when trying to run compile-time code: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20171228 for x86_64-unknown-linux): qAddTopDecls: can't convert top-level declarations Illegal variable name: ‘Bool’ When splicing a TH declaration: f_0 = Bool Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcSplice.hs:886:27 in ghc:TcSplice Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work
by GHC 27 Jul '18

27 Jul '18

#15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This may be related to #14860, but I think it's different. The following code fails to compile: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ConstraintKinds #-} import Prelude() import Data.Kind data Dict c = c => Dict type family F a :: Constraint foo :: forall a b. (a => F b, a) => Dict (F b) foo = Dict }}} {{{ • Could not deduce: F b arising from a use of ‘Dict’ from the context: (a => F b, a) }}} Yet the following all do compile: {{{#!hs bar :: forall a. F a => Dict (F a) bar = Dict baz :: forall a b. (a => b, a) => Dict b baz = Dict qux :: forall a b c. (a => c, a, c ~ F b) => Dict (F b) qux = Dict }}} It seems that a wanted `F b` can be solved with a given `F b`, but not with a given `a => F b`, which is bizarre. The fact that `qux` still works is also strange, as it means that you get a different result if you first simplify by substituting `c = F b`. As a more practical example, the following similarly fails to compile, due to the `Cod f` type family: {{{#!hs -- in addition to the above extensions {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} class Ob p a class (forall a. Ob (Dom f) a => Ob (Cod f) (f a)) => Functor f where type Dom f type Cod f liftOb :: forall f a. (Functor f, Ob (Dom f) a) => Dict (Ob (Cod f) (f a)) liftOb = Dict }}} While a version which uses fundeps instead does compile: {{{#!hs class (forall a. Ob dom a => Ob cod (f a)) => Functor dom cod f | f -> dom cod liftOb :: forall f a dom cod. (Functor dom cod f, Ob dom a) => Dict (Ob cod (f a)) liftOb = Dict }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #15416: Higher rank types in pattern synonyms
by GHC 27 Jul '18

27 Jul '18

#15416: Higher rank types in pattern synonyms -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes, PatternSynonyms, ViewPatterns #-} }}} Consider the following two pattern synonyms: {{{#!hs pattern N :: () => () => forall r. r -> (a -> r) -> r pattern N <- ((\f -> f Nothing Just) -> Nothing) where N = \n j -> n pattern J :: a -> forall r. r -> (a -> r) -> r pattern J x <- ((\f -> f Nothing Just) -> Just x) where J x = \n j -> j x }}} The pattern synonym type declaration syntax is very fragile and awkward wrt quantifiers but that's a story for another ticket. Now consider four ways to write the same function: using pattern synonyms we've defined above vs. using the exact view patterns they were defiend with; and using a series of equations vs. an explicit `case of`: {{{#!hs fooVPEqns, fooVPCase, fooPSEqns, fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a fooVPEqns ((\f -> f Nothing Just) -> Nothing) = Nothing fooVPEqns ((\f -> f Nothing Just) -> Just x) = Just x fooVPCase v = case v of ((\f -> f Nothing Just) -> Nothing) -> Nothing ((\f -> f Nothing Just) -> Just x) -> Just x fooPSEqns N = Nothing fooPSEqns (J x) = Just x fooPSCase v = case v of N -> Nothing J x -> Just x }}} Three of these compile and work fine, the fourth breaks: {{{#!hs QuantPatSyn.hs:22:9: error: • Couldn't match expected type ‘r0 -> (a -> r0) -> r0’ with actual type ‘forall r. r -> (a0 -> r) -> r’ • In the pattern: N In a case alternative: N -> Nothing In the expression: case v of N -> Nothing J x -> Just x • Relevant bindings include v :: forall r. r -> (a -> r) -> r (bound at QuantPatSyn.hs:21:11) fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a (bound at QuantPatSyn.hs:21:1) | 22 | N -> Nothing | ^ QuantPatSyn.hs:23:9: error: • Couldn't match expected type ‘r0 -> (a -> r0) -> r0’ with actual type ‘forall r. r -> (a -> r) -> r’ • In the pattern: J x In a case alternative: J x -> Just x In the expression: case v of N -> Nothing J x -> Just x • Relevant bindings include v :: forall r. r -> (a -> r) -> r (bound at QuantPatSyn.hs:21:11) fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a (bound at QuantPatSyn.hs:21:1) | 23 | J x -> Just x | ^^^ }}} The exact wording of the error message (the appearance of `forall` in the "actual type") makes me think this is an error on the typechecker's side: the part of the typechecker that handles pattern synonyms doesn't handle higher rank types correctly. Another symptom can be observed with the following: {{{#!hs pattern V :: Void -> (forall r. r) pattern V x <- ((\f -> f) -> x) where V x = absurd x barVPEqns, barVPCase, barPSEqns, barPSCase :: (forall r. r) -> Void barVPEqns ((\f -> f) -> x) = x barVPCase v = case v of ((\f -> f) -> x) -> x barPSEqns (V x) = x barPSCase v = case v of V x -> x }}} {{{#!hs QuantPatSyn.hs:43:9: error: • Cannot instantiate unification variable ‘r0’ with a type involving foralls: forall r. r GHC doesn't yet support impredicative polymorphism • In the pattern: V x In a case alternative: V x -> x In the expression: case v of { V x -> x } | 43 | V x -> x | ^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15416> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15421: Refactor (~) to reduce the superclass stack
by GHC 27 Jul '18

27 Jul '18

#15421: Refactor (~) to reduce the superclass stack -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Currently (see `Note [The equality types story]` in `TysPrim`) we have {{{ -- Hetereogeneous equality class a ~# b => a ~~ b instance a ~# b => a ~~ b -- Homogeneous equality class a ~~ b => (a :: k) ~ (b :: k) instance a ~~ b => a ~ b }}} Note that `(~#)` is a superclass of `(~~)`, and `(~~)` is a superclass of `(~)`. This means that in the common case of using `(~)` we need two superclass selections to get to the `(~#)` we want. Nothing really wrong with that, but it bloats programs, and is confusing to read when debugging. I propose to change this to {{{ -- Homogeneous equality class a ~# b => (a :: k) ~ (b :: k) instance a ~# b => a ~ b }}} That is, implement `(~)` in precisely the same way as `(~~)`. This makes `(~)` a tiny bit more baked-in to the compiler, but in exchange it behaves in the same way as `(~~)`, instead of behaving in a slightly different way. There should be no observable effect for users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13116: Allow Overloaded things in patterns
by GHC 26 Jul '18

26 Jul '18

#13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This ticket is motivated by the use of `OverloadedLabels` of the [http://hackage.haskell.org/package/choice-0.2.0 choice package]. One can use a type `Choice "block"` with values `Do #block` and `Don't #block` by using `OverloadedLabels`. However, in patterns this syntax is forbidden. {{{ case block of Do #block -> ... Don't #block -> ... }}} It would be nice if overloaded labels desugared to something sensible in patterns, perhaps {{{ case block of Do ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... Don't ((==) (fromLabel (proxy# :: Proxy# "foo")) -> True) -> ... }}} `OverloadedLists` and `OverloadedStrings` could benefit from a similar solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric
by GHC 26 Jul '18

26 Jul '18

#15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- `DerivingVia` together with `DeriveGeneric` can generate wrong instances for `Generic`. Consider the following: {{{#!haskell {-# LANGUAGE DeriveGeneric, DerivingStrategies, DerivingVia, GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, UndecidableInstances #-} module Data.Foldable.Bad where import GHC.Generics newtype Bad a = Bad a deriving (Generic) data Foo = Foo Int deriving (Read, Show, Eq, Ord) deriving (Generic) via Bad Foo }}} which gives the following representation, which is considered to be wrong for `Foo`: {{{#!haskell ghci> from $ Foo 12 M1 {unM1 = M1 {unM1 = M1 {unM1 = K1 {unK1 = Foo 12}}}} ghci> :t it it :: D1 ('MetaData "Bad" "Data.Foldable.Bad" "main" 'True) (C1 ('MetaCons "Bad" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 Foo))) x }}} Also, `DerivingStrategies` + GND + `DeriveGeneric` already can generate wrong instance: {{{#!haskell newtype Bad2 = Bad2 Bool deriving newtype (Generic) {- ghci> from $ Bad2 False M1 {unM1 = L1 (M1 {unM1 = U1})} ghci> :t it it :: D1 ('MetaData "Bool" "GHC.Types" "ghc-prim" 'False) (C1 ('MetaCons "False" 'PrefixI 'False) U1 :+: C1 ('MetaCons "True" 'PrefixI 'False) U1) x -} }}} I tested this against GHC 8.6.1-alpha1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15433: Internal error with PartialTypeSignatures and TH
by GHC 25 Jul '18

25 Jul '18

#15433: Internal error with PartialTypeSignatures and TH -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- File: {{{ {-# LANGUAGE TemplateHaskell #-} type T = $([t| _ |]) }}} gives a bad error message in 8.4 and HEAD: {{{ • GHC internal error: ‘_’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1sn :-> ATcTyCon T :: k0] • In the type ‘(_)’ In the type declaration for ‘T’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15413: Poor error message when trying to import non-existent class methods
by GHC 25 Jul '18

25 Jul '18

#15413: Poor error message when trying to import non-existent class methods -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ $ cat A.hs module A where class C a where foo :: a -> Int bar :: a -> Int $ cat B.hs module B where import A (C (foo, bar, baz)) instance C Int where foo = id bar = id $ ghci B.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) B.hs:3:11: error: Module ‘A’ does not export ‘C(foo, bar, baz)’ | 3 | import A (C (foo, bar, baz)) | ^^^^^^^^^^^^^^^^^ Failed, one module loaded. }}} If you're importing a dozen or so methods, not mentioning the specific method that couldn't be imported gets quite annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15438: Misleading error message for higher rank type
by GHC 25 Jul '18

25 Jul '18

#15438: Misleading error message for higher rank type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider {{{ foo :: (forall a b. C a b => b -> b) -> Int foo = error "urk" }}} With GHC (for ages, incl 8.6) we get {{{ • Could not deduce (C a0 b) from the context: C a b bound by the type signature for: foo :: forall a b. C a b => b -> b <======= Not true! at Foo.hs:7:8-43 The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: (forall a b. C a b => b -> b) -> Int }}} But `foo`'s type signature is NOT `foo :: forall a b. C a b => b -> b`!! Let's fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2