- ghc-tickets - Haskell.org

[GHC] #12088: Promote data family instance constructors
by GHC 06 Dec '18

06 Dec '18

#12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `TcEnv.hs` there is a note AFamDataCon: not promoting data family constructors. It states that we can't use a promoted data family instance constructor because we would have to interleave the checking of instances and data types. But with the fix of #11348, we now do exactly this. In the example from the note {{{#!hs data family T a data instance T Int = MkT data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} -ddump-rn-trace shows these groups {{{ rnTycl dependency analysis made groups [[data family T a_apG] [] [data instance T Int = MkT], [data Proxy (a_apF :: k_apE)] [] [], [data S = MkS (Proxy MkT)] [] []] }}} That's to say, the instance `T Int` will in fact be checked before `S`. So let's remove this restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53

Re: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs
by GHC 06 Dec '18

06 Dec '18

#7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T7503a Blocked By: | Blocking: Related Tickets: #14451, #12088 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by simonpj): * related: #14451 => #14451, #12088 Comment: #12088 seems to be in the same territory -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7503#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15989: Adding extra quantified constraints leads to resolution failure
by GHC 06 Dec '18

06 Dec '18

#15989: Adding extra quantified constraints leads to resolution failure -------------------------------------+------------------------------------- Reporter: eror | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE QuantifiedConstraints, FlexibleContexts #-} import Control.Monad.Reader data T x = T { anX :: x, anInt :: Int } ok :: ( forall x x'. MonadReader (T x) (m x') ) => m y Bool ok = fmap not (pure True) bad :: ( forall x x'. MonadReader (T x) (m x') , forall x. Monad (m x) ) => m y Bool bad = fmap not (pure True) better :: ( forall x x'. MonadReader (T x) (m x') , forall x. Applicative (m x) , forall x. Functor (m x) ) => m y Bool better = fmap not (pure True) }}} `ok` and `better` compile, but `bad` fail to resolve, despite having strictly more in the context than `ok`: {{{ BadQC.hs:15:7: error: • Could not deduce (Functor (m y)) arising from a use of ‘fmap’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^^^^^^^^^^^^ BadQC.hs:15:17: error: • Could not deduce (Applicative (m y)) arising from a use of ‘pure’ from the context: (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) bound by the type signature for: bad :: forall (m :: * -> * -> *) y. (forall x x'. MonadReader (T x) (m x'), forall x. Monad (m x)) => m y Bool at BadQC.hs:(12,1)-(14,15) • In the second argument of ‘fmap’, namely ‘(pure True)’ In the expression: fmap not (pure True) In an equation for ‘bad’: bad = fmap not (pure True) | 15 | bad = fmap not (pure True) | ^^^^^^^^^ Failed, no modules loaded. }}} Also: * `( forall x. MonadReader (T x) (m x), forall x. Monad (m x) )` compiles — the error seems to require two quantified type variables * `( forall x x'. Monad (m x), forall x. Monad (m x) )` reports an ambiguity error on the constraint, which makes sense; if I turn on `AllowAmbiguousTypes`, it fails with the same error as above — the error isn't caused by MPTCs, and it doesn't matter that `x'` is unused * `( forall x x'. Foldable (m x), forall x. Monad (m x) )` and `( forall x x'. Monad (m x), forall x. Foldable (m x) )` compile — being in the same class hierarchy matters * `( forall x x'. Applicative (m x), forall x. Monad (m x) )` fails on `fmap` (but not `pure`) — which is the superclass doesn't seem to matter -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15989> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14727: Unboxed sum performance surprisingly poor
by GHC 06 Dec '18

06 Dec '18

#14727: Unboxed sum performance surprisingly poor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: UnboxedSums | 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 tried performing worker-wrapper manually on `Data.IntMap.lookup`: {{{#!hs lookup# :: Int -> IntMap a -> (# (# #) | a #) lookup# = -- The obvious modification of the current implementation lookup :: Int -> IntMap a -> Maybe a lookup k m = case lookup# k m of (# | a #) -> Just a _ -> Nothing }}} Unfortunately, the `lookup` benchmark ''slowed down''. I verified that the benchmark indeed performs an immediate case analysis on the result (with `fromMaybe`), so it ''should'' go faster. And yet it goes slower. Caveat: I have not yet gotten things set up to be able to check with 8.4, so if there have been improvements in `UnboxedSum` performance since `8.2.2`, this may all be silly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum
by GHC 06 Dec '18

06 Dec '18

#14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's the code in question: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE UnboxedTuples #-} {-# OPTIONS_GHC -O2 #-} module Byte.Array.Window ( findByte , boxMaybeInt ) where import Data.Primitive (ByteArray) import Data.Word (Word8) import GHC.Types (RuntimeRep,TYPE) import GHC.Int (Int(I#)) import GHC.Exts (Int#) import qualified Data.Primitive as PM type Maybe# (a :: TYPE (r :: RuntimeRep)) = (# (# #) | a #) boxMaybeInt :: Maybe# Int# -> Maybe Int boxMaybeInt = \case (# | a #) -> Just (I# a) (# (# #) | #) -> Nothing unboxInt :: Int -> Int# unboxInt (I# i) = i -- | Finds the first occurrence of the given byte. -- TODO: optimize this to search through a whole -- Word64 at a time if the bytearray is pinned. findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int findByte !off !len !w !arr = boxMaybeInt (go off) where go :: Int -> Maybe# Int# go !ix = if ix < len then if PM.indexByteArray arr ix == w then (# | unboxInt ix #) else go (ix + 1) else (# (# #) | #) }}} When compiled with GHC 8.5 with `-ddump-simpl -dsuppress-all`, here is the relevant part of the resulting Core: {{{ -- RHS size: {terms: 33, types: 13, coercions: 0, joins: 1/1} $wfindByte $wfindByte = \ ww_s38C ww1_s38G ww2_s38K ww3_s38O -> joinrec { $wgo_s38v $wgo_s38v ww4_s38t = case <# ww4_s38t ww1_s38G of { __DEFAULT -> Nothing; 1# -> case indexWord8Array# ww3_s38O ww4_s38t of wild_a36w { __DEFAULT -> case eqWord# wild_a36w ww2_s38K of { __DEFAULT -> jump $wgo_s38v (+# ww4_s38t 1#); 1# -> Just (I# ww4_s38t) } } }; } in jump $wgo_s38v ww_s38C -- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0} findByte findByte = \ w_s38w w1_s38x w2_s38y w3_s38z -> case w_s38w of { I# ww1_s38C -> case w1_s38x of { I# ww3_s38G -> case w2_s38y of { W8# ww5_s38K -> case w3_s38z of { ByteArray ww7_s38O -> $wfindByte ww1_s38C ww3_s38G ww5_s38K ww7_s38O } } } } }}} I expected that the tail recursive `go` helpful function from my original code would still be a function that returns an unboxed sum when optimized and turned into Core. However, it isn't. The call to `boxMaybeInt` gets pushed into `go`. This means that when `findByte` is called and the result cased on, an allocation is going to happen. I think it would be preferable for `boxMaybeInt` to not get pushed into the worker, since `boxMaybeInt (go off)` could be inlined and the allocation of `Maybe` could be prevented (assuming that it was cased on right afterward). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15677: Valid hole fits and GADT type variable names
by GHC 06 Dec '18

06 Dec '18

#15677: Valid hole fits and GADT type variable names -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: TypedHoles, | Operating System: Unknown/Multiple GADTs | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} module Foo where import Data.Kind data HList :: [Type] -> Type where HNil :: HList '[] HCons :: x -> HList xs -> HList (x:xs) foo :: HList a -> HList a foo HNil = HNil foo (HCons (b :: bType) bs) = HCons _ bs }}} Here is the suggestion that the typed hole in `foo` provides: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) Bug.hs:16:37: error: • Found hole: _ :: x Where: ‘x’ is a rigid type variable bound by a pattern with constructor: HCons :: forall x (xs :: [*]). x -> HList xs -> HList (x : xs), in an equation for ‘foo’ at Bug.hs:16:6-26 • In the first argument of ‘HCons’, namely ‘_’ In the expression: HCons _ bs In an equation for ‘foo’: foo (HCons (b :: bType) bs) = HCons _ bs • Relevant bindings include bs :: HList xs (bound at Bug.hs:16:25) b :: x (bound at Bug.hs:16:13) foo :: HList a -> HList a (bound at Bug.hs:15:1) Constraints include a ~ (x : xs) (from Bug.hs:16:6-26) Valid hole fits include b :: x (bound at Bug.hs:16:13) | 16 | foo (HCons (b :: bType) bs) = HCons _ bs | ^ }}} One thing immediately stands out here: the hole has type `x`, but `x` appears no where in the definition of `foo`! I had expected this suggestion to mention `bType`, since I went through the effort of declaring `b` to have that type through a pattern signature, but GHC instead uses types from the definition of the `HCons` constructor itself. This seems less than ideal, since one would expect GHC to only ever mention types that are lexically in scope at a particular definition site. One thing which complicates this idea is that there can be multiple in- scope type variables that all refer to the same type. For instance, if I define this function: {{{#!hs bar :: HList a -> HList a -> HList a bar HNil HNil = HNil bar (HCons (b :: bType) bs) (HCons (c :: cType) cs) = HCons _ bs }}} What should the suggested type of the hole be: `bType`, or `cType`? Either choice is equally valid. After talking with Tritlo and simonpj about this, we came to the consensus that we should just pick one of the type variables to report at the top of the error message: {{{ • Found hole: _ :: bType }}} And then later in the message, include any type variable synonyms that have been brought into scope (via pattern signatures or otherwise). I imagine this might look something like: {{{ • Type variable synonyms include `cType` equals `bType` }}} This is quite similar to an existing feature of valid hole fits where we report `Constraints include`. (Indeed, we briefly considered just reporting these type variable synonyms as explicit equality constraints, but doing so would be somewhat misleading, since that's not how pattern signatures actually work in practice.) One implementation challenge is to figure out how to construct a mapping from `x` to `bType`. One place where inspiration can be drawn from is the `ATyVar` constructor of `TcTyThing`: {{{#!hs data TcTyThing = ... | ATyVar Name TcTyVar -- The type variable to which the lexically scoped type -- variable is bound. We only need the Name -- for error-message purposes; it is the corresponding -- Name in the domain of the envt }}} `ATyVar` already stores a "reverse mapping" of sorts to give better a more accurate `Name` in the event that it is pretty-printed, which is quite similar to what we need to do with `x` and `bType`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5793: make nofib awesome
by GHC 06 Dec '18

06 Dec '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #15357 #15333 => #15357 #15333 #15999 Comment: I opened #15999 to track the implicit task in comment:38. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc
by GHC 06 Dec '18

06 Dec '18

#7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9883 Related Tickets: #9883 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) Comment: Lovely design in comment:11. I don't think anything stops us from extending it to support pattern matching and ranges by adding more classes for these features. Another use case that I have in mind is `NonEmpty`. As it stands, using it with `OverloadedLists` is unsafe, as `[]` will fail at run-time instead of compile-time. With the design of comment:11 we could do this: {{{#!hs instance Cons (NonEmpty a) where type Head (NonEmpty a) = a type Tail (NonEmpty a) = [a] cons = (:|) instance TypeError ... => Nil (NonEmpty a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7495#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15203: Wrong location reported for kind error
by GHC 05 Dec '18

05 Dec '18

#15203: Wrong location reported for kind error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- When I try to compile {{{#!hs {-# LANGUAGE PolyKinds, ConstraintKinds, TypeFamilies, FlexibleContexts #-} module Bug where import Data.Proxy type T (a :: k1) (b :: k2) = (a ~ b, Show (Proxy (a :: k1)), Show (Proxy (b :: k2))) }}} I get {{{ Bug.hs:7:80: error: • Couldn't match ‘k1’ with ‘k2’ • In the type declaration for ‘T’ | 7 | type T (a :: k1) (b :: k2) = (a ~ b, Show (Proxy (a :: k1)), Show (Proxy (b :: k2))) | ^^ }}} The problem is that the `k2` that's highlighted has nothing at all to do with the error. Indeed, some experimentation shows that GHC will highlight the first occurrence of `k2` to the right of the `=`. The error is actually from unification caused by `a ~ b`. I noticed this because I've been tightening up the way GHC does left-to- right ordering during implicit quantification (while working on something more substantial). In so doing, I made sure to prefer kind variable occurrences to the ''left'' of the = over those to the right. But then I got a testsuite failure due to a changed location of an error. This is caused by the call to `report_sig_tv_err` in `tcTyClTyVars`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5793: make nofib awesome
by GHC 05 Dec '18

05 Dec '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > I blame non-determinism in code layout or some other caching effect until I have a better hypothesis. These are the candidats we want to flag away for runtime measurements, especially real/eff, or make them actually do something meaningful. They generally compile down to a loop of a handfull of instructions. So flipping an `if` (invert the condition, swap then and else expressions) can already lead to noteable differences as the cpu might need proccess one more instruction. For the really small loops we can also get counterintuitive behaviour. Eg I reduced on of them by one instruction and performance got slower because of instruction sheduling effects. Having an "effective runtime" modus that excludes these seems worthwhile. But I'm torn on excluding them by default. Ideally people would see these unexpected results. Then look at the generated code and be able to tell if the code is actually worse or if it's just one of these edge cases. But that requires a lot of low level knowledge, which not everyone has. So people might throw out perfectly good ideas/patches because of missleading nofib results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:39> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0