April 2017 - ghc-tickets

[GHC] #13310: Cut a new array release
by GHC 18 Jul '17

18 Jul '17

#13310: Cut a new array release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- The `array` package needs a new release for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds)
by GHC 18 Jul '17

18 Jul '17

#12131: Can't solve constraints with UndecidableSuperClasses but can infer kind (+ undesired order of kinds) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11480 #12025 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Glorious Glasgow Haskell Compilation System, version 8.0.1. Code taken from [https://gist.github.com/ekmett/b26363fc0f38777a637d gist] with {{{#!hs fmap :: p a b -> q (f a) (f b) }}} replaced by {{{#!hs fmap :: Dom f a b -> Cod f (f a) (f b) }}} If you enable `DataKinds` and `TypeInType` `:kind` will happily tell you its kind: {{{ ghci> :kind 'Main.Nat 'Main.Nat :: forall j i (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j). (FunctorOf p q f, FunctorOf p q g) => (forall (a :: i). Ob p a => q (f a) (g a)) -> Main.Nat p q f g }}} but if you try `:type Nat` it spits out a long list of unsolved constraints {{{ ghci> :type Nat <interactive>:1:1: error: solveWanteds: too many iterations (limit = 1) Unsolved: WC {wc_simple = [W] $dFunctor_ag3Y :: Main.Functor f_ag3S (CDictCan) [W] $dFunctor_ag4d :: Main.Functor g_ag3T (CDictCan) [D] _ :: Main.Functor s_ag51 (CDictCan) [D] _ :: Main.Functor s_ag5a (CDictCan) [D] _ :: Main.Functor s_ag4W (CDictCan) [D] _ :: Main.Functor s_ag55 (CDictCan) [D] _ :: Category s_ag51 (CDictCan) [D] _ :: Category s_ag5a (CDictCan) [D] _ :: Category s_ag4W (CDictCan) [D] _ :: Category s_ag55 (CDictCan) [W] hole{ag4Y} :: Dom g_ag3T ~ Dom f_ag3S (CNonCanonical) [W] hole{ag53} :: Cod g_ag3T ~ Cod f_ag3S (CNonCanonical) [D] _ :: Dom (Dom f_ag3S) ~ Op (Dom f_ag3S) (CNonCanonical) [D] _ :: Cod (Dom f_ag3S) }}} This seems like #11480. This makes undecidable superclasses a harsh master and raises two questions that I'll bundle together: 1. Why can the `:kind` be inferred but not the `:type`? It works when given extra information: {{{ ghci> :type Nat @_ @_ @(->) @(->) Nat @_ @_ @(->) @(->) :: (Cod g ~ (->), Dom g ~ (->), Cod f ~ (->), Dom f ~ (->), Main.Functor g, Main.Functor f) => (forall a. Vacuous (->) a => f a -> g a) -> Main.Nat (->) (->) f g }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe Nat @_ @_ @_ @_ @[] @Maybe :: (forall a. Vacuous (->) a => [a] -> Maybe a) -> Main.Nat (->) (->) [] Maybe }}} {{{ ghci> :type Nat @_ @_ @_ @_ @[] @Maybe listToMaybe Nat @_ @_ @_ @_ @[] @Maybe listToMaybe :: Main.Nat (->) (->) [] Maybe }}} 2. Why is `j` positioned before `i` (most likely because of `forall a. ...` but I tried tinkering without success? Is there any trick to ordering it as you'd expect `forall i j (p :: Cat i) (q :: Cat j)` or is it not possible per #12025? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9805: Use TrieMaps to speed up type class instance lookup
by GHC 18 Jul '17

18 Jul '17

#9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, type class instance resolution is performed by doing a map lookup by type class, and then linearly matching against every instance. This is not great, and for a while, simonpj has been keen on using the TrieMap data structure in GHC, which has been previously used to implement a map from CoreExprs to various things (e.g. for CSE). What makes this a little tricky is that instance lookup isn't intended to be an exact match: we should unify so-called template variables and provide a substitution; furthermore, there may be multiple matches. After some prototyping, I think we should be able to make this work. The primary refactoring we have to do is *maintain the key associated with an entry in a TrieMap*. Unlike the current uses of TrieMaps, where it's acceptable to lose the underlying key associated with an entry in the TrieMap, we need to know the key when doing unification, because it may be reported in the substitution. There are a few knock-on effects of this: * We should add a method `foldWithKeyTM :: (Key m -> a -> b -> b) -> m a -> b -> b` to the `TrieMap` type class. * We need a variant of `UniqFM` which tracks the original key that was used. I propose we name it `UniqKM` (unique key map). A number of implementations of `TrieMap` need to be adjusted to use this instead of `UniqFM`. * Why can't we just represent keyed TrieMaps as `TypeMap (Type, a)`? It might be possible. An insurmountable difficulty would be if we need to know the partial key PRIOR to having finished traversing the TrieMap; however, for the parts of the unification algorithm I've implemented, this does not seem to be the case. The primary actual difficulty is that `Type` uses a named representation, whereas `TypeMap` keys are on-the-fly deBruijn numbered. There would at least be some annoying fiddliness. * Reversing the deBruijn numbered key into a `Type` is a bit goofy. Essentially, you need the reverse of the current `CmEnv`: a mapping from de Bruijn levels to the `Var` you've decided to allocate. (I've called this `CfEnv` in my prototype) * When we represent a TrieMap binder, we have to put the binder map on the OUTSIDE, as opposed to the inside as it is currently. Otherwise, we can't update the `CfEnv` with the new mapping before making the recursive call to fold-with-key. I'll attach the standalone Haskell file I used to prototype this, wherein I copy-pasted a lot of Haskell from GHC's source and implemented fuzzy map on a simplified version of `Type`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #13311: Audit shady uses of tcSplitSigmaTy
by GHC 12 Jul '17

12 Jul '17

#13311: Audit shady uses of tcSplitSigmaTy -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 (Type checker) | 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 fixing #12918, I ended up needing to introduce a helper function called `tcSplitNestedSigmaTys`, which is quite similar to `tcSplitSigmaTy`, except that it attempts to look through as many nested `forall`s as possible. (See the documentation for `tcSplitNestedSigmaTys` [http://git.haskell.org/ghc.git/blob/611f998fd545b45167170d9e60b7d9147178f0a… here]). In the process, I accidentally discovered a bug! First, consider this program: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b c. (Monoid b, Monoid c, Eq a) => a -> b -> c }}} This should be (and is) rejected, since we're trying to constrain `a` with `Eq` in `op`, but we don't have `-XConstraintedClassMethods` enabled. But what about this equivalent program? {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where class C a where op :: forall b. Monoid b => forall c. Monoid c => Eq a => a -> b -> c }}} By the same logic, this should also be rejected. But in GHC 8.0.2, it wasn't! That's because we were checking for the presence of constrained class variables using `tcSplitSigmaTy`, which only gives you `Monoid b` as the constraint, totally ignoring the bogus constraint inside of `forall c. Monoid c => Eq a => a -> b -> c`. When I fixed #12918 (a seemingly unrelated task), I ended up replacing that very use of `tcSplitSigmaTy` with `tcSplitNestedSigmaTys`. Now it gives you `(Monoid b, Monoid c, Eq a)` as expected when checking the constraints, and the second program is now rightly rejected on GHC HEAD. But I fear that there may be many more bogus uses of `tcSplitSigmaTy`. I should go through and try flushing out bugs of a similar caliber, and see if subbing in `tcSplitNestedSigmaTys` fixes these bugs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12089: :kind command allows unsaturated type family,
by GHC 12 Jul '17

12 Jul '17

#12089: :kind command allows unsaturated type family, -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- {{{#!hs data A = B type family F a where F B = String infixr 9 `Compose` class (f (g x)) => (f `Compose` g) x instance (f (g x)) => (f `Compose` g) x }}} GHCi accepts {{{ ghci> :kind Compose Eq F Compose Eq F :: A -> Constraint }}} but when used in code it gets rejected {{{ -- tvI6.hs:13:8-33: error: … -- • The type family ‘F’ should have 1 argument, but has been given none -- • In the type signature: -- foo :: (Eq `Compose` F) a => String -- Compilation failed. foo :: (Eq`Compose`F) a => String foo = undefined }}} Bug? Version 8.0.0.20160511 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8346: Rank 1 type signature still requires RankNTypes
by GHC 11 Jul '17

11 Jul '17

#8346: Rank 1 type signature still requires RankNTypes ----------------------------+---------------------------------------------- Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #2605 | ----------------------------+---------------------------------------------- When trying to figure out which type variable names are *actually* bound in `ScopedTypeVariables`, I tried floating `forall`s into the covariant argument of the function type. Essentially, I ran into the problem that programs like the following are rejected: {{{ #!hs {-# LANGUAGE ExplicitForAll #-} tuple :: forall a. a -> (forall b. b -> (a, b)) tuple = (,) }}} The message is as follows: {{{ Main.hs:2:10: Illegal polymorphic or qualified type: forall b. b -> (a, b) Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `tuple': tuple :: forall a. a -> (forall b. b -> (a, b)) }}} As far as I know, the rank of a type is defined by how deep quantifiers are nested in contravariant parts of that type. Or something like that. Also, as far as I know, `forall a. a -> (forall b. b -> (a, b))` is equivalent to `forall a b. a -> b -> (a, b)`, and more importantly, both are rank-1 polymorphic. There should be no need to use extensions that allow higher-ranked polymorphism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13568: Name is reported as ambiguous and not in scope
by GHC 11 Jul '17

11 Jul '17

#13568: Name is reported as ambiguous and not in scope -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- {{{ module A where data T = A }}} {{{ module B where import A data S = A foo :: A -> () foo = undefined }}} Compiling this example, the usage of `A` in `foo` is reported as both ambiguous and out of scope. I haven't mentioned data kinds at all so `A` should certainly refer to a type constructor which isn't in scope. The problem is that `DataKinds` is checked too late in `lookup_demoted`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12390: List rules for `Coercible` instances
by GHC 11 Jul '17

11 Jul '17

#12390: List rules for `Coercible` instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: 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: -------------------------------------+------------------------------------- `:info` on [https://downloads.haskell.org/~ghc/7.8.2/docs/html/libraries/base-4.7.0.0 /Data-Coerce.html#t:Coercible Data.Coerce.Coercible] doesn't display any instances, it's a special class so it should be special-cased {{{ ghci> :i Coercible type role Coercible representational representational class a ~R# b => Coercible (a :: k) (b :: k) -- Defined in ‘GHC.Types’ }}} The base case would be easy to display: {{{#!hs instance Coercible a a -- Generated on the fly }}} but it's trickier to describe the … instance succinctly: {{{#!hs instance Coercible b b' => Coercible (D a b c) (D a b' c') }}} same for newtypes. ---- Maybe it's better to list concrete examples {{{#!hs coerce @(Reader _ _) :: Reader a b -> (a -> Identity b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10150: Suppress orphan instance warning per instance
by GHC 11 Jul '17

11 Jul '17

#10150: Suppress orphan instance warning per instance -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the same way we have overlapping/incoherent instance pragmas which can be applied on a per instance basis, it would be good to have a `-fno-warn- orphan-instance` pragma which can be applied on a per-instance basis. Annoyingly, there is not an obvious syntax to use for this case, since SOP for a module with orphan instances is `{-# GHC_OPTIONS -fno-warn-orphans #-}` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12921: initTc: unsolved constraints
by GHC 10 Jul '17

10 Jul '17

#12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on a small project of mine, GHC panicked with the following error: {{{ lua-types-0.1.0.0: build Preprocessing executable 'lua-types' for lua-types-0.1.0.0... [2 of 3] Compiling Lua.Parser ( src/Lua/Parser.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.1.0/build/lua-types/lua-types- tmp/Lua/Parser.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] explist_a3nf :: t_a3ne[tau:1] (CHoleCan: explist) [W] funccall_a4dv :: t_a4du[tau:1] (CHoleCan: funccall)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} From a quick google search, it seems like this is a bug in the type checker. I'm not willing nor able to dive any further into the GHC code myself, though. I'll attach the code as it is, before looking for a workaround. I'm using stack, GHC version 8.0.1.20161117 for x86_64-apple-darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11