GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-03-03T15:23:57Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/230189.6 assertion failure - constraint vs type2023-03-03T15:23:57ZMatthew Pickering9.6 assertion failure - constraint vs type```haskell
module Data.NonEmpty.Class where
import qualified Control.DeepSeq as DeepSeq
class NFData f where
rnf :: DeepSeq.NFData a => f a -> ()
instance NFData Maybe where
rnf = DeepSeq.rnf
```
```
> ~/head.hackage/ghc/bin/gh...```haskell
module Data.NonEmpty.Class where
import qualified Control.DeepSeq as DeepSeq
class NFData f where
rnf :: DeepSeq.NFData a => f a -> ()
instance NFData Maybe where
rnf = DeepSeq.rnf
```
```
> ~/head.hackage/ghc/bin/ghc Class.hs -O
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.0.20230220:
ASSERT failed!
Coercion = Kind (Sym (N:NFData[0] <a_aMw>_N))
LHS ty = *
RHS ty = Constraint
cs = Tc(0)
coercion role = nominal
Call stack:
CallStack (from HasCallStack):
assertPpr, called at compiler/GHC/Core/Coercion.hs:1126:5 in ghc:GHC.Core.Coercion
mkSelCo_maybe, called at compiler/GHC/Core/Coercion.hs:1118:16 in ghc:GHC.Core.Coercion
mkSelCo, called at compiler/GHC/Core/Coercion.hs:620:5 in ghc:GHC.Core.Coercion
mkRuntimeRepCo, called at compiler/GHC/Core/Unify.hs:1584:16 in ghc:GHC.Core.Unify
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/23038A nice pattern synonym record field became naughty in GHC 9.62023-03-03T15:22:44Zsheafsam.derbyshire@gmail.comA nice pattern synonym record field became naughty in GHC 9.6Consider the following:
```haskell
pattern N1 :: forall a. () => forall. () => a -> Any
pattern N1 { fld1 } <- ( unsafeCoerce -> fld1 )
where N1 = unsafeCoerce
pattern N2 :: forall. () => forall a. () => a -> Any
pattern N2 { fld2 } ...Consider the following:
```haskell
pattern N1 :: forall a. () => forall. () => a -> Any
pattern N1 { fld1 } <- ( unsafeCoerce -> fld1 )
where N1 = unsafeCoerce
pattern N2 :: forall. () => forall a. () => a -> Any
pattern N2 { fld2 } <- ( unsafeCoerce -> fld2 )
where N2 = unsafeCoerce
test1, test2 :: forall a. Any -> a
test1 = fld1
test2 = fld2
```
We should accept `test1`, and reject `test2` because we have an existential variable escaping its scope (`fld2` is a "naughty record selector").
This is indeed what happens on GHC 9.4. However, on GHC 9.6, `test1` is rejected as it considers `fld1` to also be a naughty record selector.
This regression showed up when compiling the [`cleff`](https://hackage.haskell.org/package/cleff) package, which contains the following:
```haskell
pattern Any :: forall a. a -> Any
pattern Any {fromAny} <- (unsafeCoerce -> fromAny)
where Any = unsafeCoerce
```
```
src/Cleff/Internal/Monad.hs:46:26: error: [GHC-55876]
• Cannot use record selector ‘fromAny’ as a function due to escaped type variables
• In the first argument of ‘($)’, namely ‘fromAny’
In the expression:
fromAny $ Vec.lookup (unHandlerPtr (Rec.index @e re)) mem
In an equation for ‘readEnv’:
readEnv (Env _ re mem)
= fromAny $ Vec.lookup (unHandlerPtr (Rec.index @e re)) mem
Suggested fix: Use pattern-matching syntax instead
|
46 | readEnv (Env _ re mem) = fromAny $ Vec.lookup (unHandlerPtr (Rec.index @e re)) mem
|9.6.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/22960EPS contention may be slowing down parallel make2023-02-27T20:15:03ZTeo CamarasuEPS contention may be slowing down parallel make### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If a...### Summary
I think it's likely that contention of the EPS is blocking parallel make from reaching its full potential on large shallow module graphs.
The EPS is stored in a global IORef and is regularly checked during typechecking.
If an interface hasn't yet been loaded, then it will be loaded, typecheched (potentially loading further interfaces), and then atomically merged with the current value of the EPS.
From a quick glance at the code I'm seeing two potential issues:
1) Duplicated work due to two threads racing:
In a situation where two threads both discover that an interface is missing from the EPS, I think, they will duplicate work to load it.
2) Atomically updating the EPS blocks reads:
AFAIK using `atomicModifyIORef'` blocks reads, as it updates the IORef with a thunk that it then evaluates. While the thunk is under evaluation, other threads will be blocked if they try to look at it.
I say potential issues because I haven't done enough investigating to confirm if this is actually an issue.
I'll try to do that in the next couple of weeks and come up with some strategies to mitigate it if it does turn out to be a problem.
### Context
I was led to the EPS by looking at the DWARF decoded stacks of threads blocking on blackholes while compiling `Cabal`.
Code that was looking things up in the EPS stood out to me. I used this branch of ghc https://gitlab.haskell.org/teo/ghc/-/commits/wip/blackhole-introspectionBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22928Mention changes to coercible solving in changelog and migration guide2023-02-23T11:01:59Zsheafsam.derbyshire@gmail.comMention changes to coercible solving in changelog and migration guideAs pointed out in #22924, there are some user-facing changes to the constraint solver relating to representational equality that landed in 3e827c3f, which I believe deserve at the very least a mention in the release notes and migration g...As pointed out in #22924, there are some user-facing changes to the constraint solver relating to representational equality that landed in 3e827c3f, which I believe deserve at the very least a mention in the release notes and migration guide.9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/22924Regression in Coercible solver with type constructor variables2023-02-20T13:40:14ZXia Li-yaoRegression in Coercible solver with type constructor variables## Summary
GHC 9.6.0 alpha2 rejects the following use of `coerce` that was accepted in 9.4
## Steps to reproduce
```haskell
{-# LANGUAGE FlexibleInstances #-}
module G where
import Data.Functor.Const (Const ())
import Data.Coerce
f ...## Summary
GHC 9.6.0 alpha2 rejects the following use of `coerce` that was accepted in 9.4
## Steps to reproduce
```haskell
{-# LANGUAGE FlexibleInstances #-}
module G where
import Data.Functor.Const (Const ())
import Data.Coerce
f :: Coercible (f a) a => Const a () -> Const (f a) ()
f = coerce
```
## Expected behavior
That compiles on GHC 9.4.
On 9.6 alpha2:
```
G.hs:8:5: error: [GHC-18872]
• Couldn't match representation of type: Const a ()
with that of: Const (f a) ()
arising from a use of ‘coerce’
The data constructor ‘Data.Functor.Const.Const’
of newtype ‘Const’ is not in scope
• In the expression: coerce
In an equation for ‘f’: f = coerce
• Relevant bindings include
f :: Const a () -> Const (f a) () (bound at G.hs:8:1)
|
8 | f = coerce
| ^^^^^^
```https://gitlab.haskell.org/ghc/ghc/-/issues/1158Problem with GADTs and explicit type signatures2023-02-13T16:23:12ZguestProblem with GADTs and explicit type signatures```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
data Exp a where
Val :: a -> Exp b
App :: Exp a -> Exp b
instance Sh...```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE AllowAmbiguousTypes #-}
module Main where
data Exp a where
Val :: a -> Exp b
App :: Exp a -> Exp b
instance Show (Exp a) where
show (Val _) = "Val"
show (App _) = "App"
class LiftToExp a b where
liftToExp :: a -> Exp b
instance LiftToExp (Exp a) a where
liftToExp = id
instance Floating a => LiftToExp a b where
liftToExp v = Val v :: Exp b
{-
Uncommenting the type signature below causes GHCi to fail to load the file:
Test.hs:48:15: error:
• Overlapping instances for LiftToExp a a0
arising from a use of ‘liftToExp’
Matching givens (or their superclasses):
LiftToExp a a1
bound by the type signature for:
test :: LiftToExp a a1 => a -> Exp b
at Test.hs:47:1-38
Matching instances:
instance LiftToExp a b -- Defined at Test.hs:22:10
instance LiftToExp (Exp a) a -- Defined at Test.hs:19:10
(The choice depends on the instantiation of ‘a, a0’)
• In the first argument of ‘App’, namely ‘(liftToExp x)’
In the expression: App (liftToExp x)
In an equation for ‘test’: test x = App (liftToExp x)
However typing :t test at the GHCi prompt gives this exact signature.
-}
--test :: (LiftToExp a a1) => a -> Exp b
test x = App (liftToExp x)
main = putStrLn $ show (test (3.0::Float)::Exp Int)
```Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/14086Empty case does not detect kinds2023-02-12T12:50:17ZDavid FeuerEmpty case does not detect kinds```hs
{-# language TypeInType, EmptyCase #-}
module Silly where
import Data.Kind
f :: Type -> Int
f x = case x of
```
GHC warns
```
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: _ :: *
```
...```hs
{-# language TypeInType, EmptyCase #-}
module Silly where
import Data.Kind
f :: Type -> Int
f x = case x of
```
GHC warns
```
Pattern match(es) are non-exhaustive
In a case alternative: Patterns not matched: _ :: *
```
In fact, `Type` is only a type because of `TypeInType`. It has no actual values, so the empty case is exhaustive.
To be honest, I kind of wish GHC would give me a warning for doing something so silly as to even give a function an argument of type `Type`, but I imagine that might be hard.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Empty case does not detect kinds","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# language TypeInType, EmptyCase #-}\r\nmodule Silly where\r\nimport Data.Kind\r\n\r\nf :: Type -> Int\r\nf x = case x of\r\n}}}\r\n\r\nGHC warns\r\n\r\n{{{\r\n Pattern match(es) are non-exhaustive\r\n In a case alternative: Patterns not matched: _ :: *\r\n}}}\r\n\r\nIn fact, `Type` is only a type because of `TypeInType`. It has no actual values, so the empty case is exhaustive.\r\n\r\nTo be honest, I kind of wish GHC would give me a warning for doing something so silly as to even give a function an argument of type `Type`, but I imagine that might be hard.","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/21501Confusion around visible type application in pattern synonym pattern2023-02-09T17:22:10ZRichard Eisenbergrae@richarde.devConfusion around visible type application in pattern synonym patternSee also #19847
Sometimes, I like to declare
```hs
import Data.Kind
import Type.Reflection
pattern TypeApp ::
forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
result ~ f arg =>
TypeRep arg ...See also #19847
Sometimes, I like to declare
```hs
import Data.Kind
import Type.Reflection
pattern TypeApp ::
forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
result ~ f arg =>
TypeRep arg ->
TypeRep result
pattern TypeApp arg_rep <- App (eqTypeRep (typeRep @f) -> Just HRefl) arg_rep
```
This pattern synonym allows me to match on a `TypeRep` to see whether its an application of some known type constructor, like `List` or `Maybe`.
GHC accepts this declaration, as it should.
But using causes chaos:
```hs
f :: TypeRep a -> String
f (TypeApp @[] rep) = show rep
```
produces
```
Bug.hs:18:4: error:
• No instance for (Typeable f0) arising from a use of ‘TypeApp’
• In the pattern: TypeApp @[] rep
In an equation for ‘f’: f (TypeApp @[] rep) = show rep
|
18 | f (TypeApp @[] rep) = show rep
| ^^^^^^^^^^^^^^^
Bug.hs:18:4: error:
• Could not deduce (k1 ~ *)
from the context: a ~ f0 arg
bound by a pattern with pattern synonym:
TypeApp :: forall {k1} {k2} (f :: k1 -> k2) (result :: k2).
Typeable f =>
forall (arg :: k1).
(result ~ f arg) =>
TypeRep arg -> TypeRep result,
in an equation for ‘f’
at Bug.hs:18:4-18
‘k1’ is a rigid type variable bound by
the type signature for:
f :: forall {k1} (a :: k1). TypeRep a -> String
at Bug.hs:17:1-24
• In the pattern: TypeApp @[] rep
In an equation for ‘f’: f (TypeApp @[] rep) = show rep
• Relevant bindings include
f :: TypeRep a -> String (bound at Bug.hs:18:1)
|
18 | f (TypeApp @[] rep) = show rep
| ^^^^^^^^^^^^^^^
```
I have no clue what GHC is thinking here. Even when I try making `k1` and `k2` *specified* (in parens, not braces) and stating `@Type @Type`, GHC is no better off, producing roughly the same messages.
For the record, this was encountered while I was writing a library that is intended to be useful in the Real World.https://gitlab.haskell.org/ghc/ghc/-/issues/19847Type application in pattern does not substitute correctly2023-02-09T17:22:09ZRichard Eisenbergrae@richarde.devType application in pattern does not substitute correctlySee also
* #19577
* #22383
* #21501
Inspired by @Icelandjack's https://gitlab.haskell.org/ghc/ghc/-/issues/19691#note_352594, I typed in
```hs
pattern Is :: forall (b :: Type) (a :: Type). Typeable b => (a ~ b) => TypeRep a
pattern Is ...See also
* #19577
* #22383
* #21501
Inspired by @Icelandjack's https://gitlab.haskell.org/ghc/ghc/-/issues/19691#note_352594, I typed in
```hs
pattern Is :: forall (b :: Type) (a :: Type). Typeable b => (a ~ b) => TypeRep a
pattern Is <- (eqTypeRep (typeRep @b) -> Just HRefl)
where Is = typeRep
def :: TypeRep a -> a
def = \case
Is @Int -> 10
Is @Bool -> False
```
which looks pretty sensible to me. HEAD tells me
```
Scratch.hs:40:3: error:
• No instance for (Typeable b0) arising from a use of ‘Is’
• In the pattern: Is @Int
In a case alternative: Is @Int -> 10
In the expression:
\case
Is @Int -> 10
Is @Bool -> False
|
40 | Is @Int -> 10
| ^^^^^^^
Scratch.hs:40:3: error:
• Could not deduce: a ~ Int
from the context: a ~ b0
bound by a pattern with pattern synonym:
Is :: forall b a. Typeable b => (a ~ b) => TypeRep a,
in a case alternative
at Scratch.hs:40:3-9
Expected: b0
Actual: Int
‘a’ is a rigid type variable bound by
the type signature for:
def :: forall a. TypeRep a -> a
at Scratch.hs:38:1-21
• In the pattern: Is @Int
In a case alternative: Is @Int -> 10
In the expression:
\case
Is @Int -> 10
Is @Bool -> False
• Relevant bindings include
def :: TypeRep a -> a (bound at Scratch.hs:39:1)
|
40 | Is @Int -> 10
| ^^^^^^^
Scratch.hs:41:3: error:
• No instance for (Typeable b1) arising from a use of ‘Is’
• In the pattern: Is @Bool
In a case alternative: Is @Bool -> False
In the expression:
\case
Is @Int -> 10
Is @Bool -> False
|
41 | Is @Bool -> False
| ^^^^^^^^
Scratch.hs:41:15: error:
• Could not deduce: a ~ Bool
from the context: a ~ b1
bound by a pattern with pattern synonym:
Is :: forall b a. Typeable b => (a ~ b) => TypeRep a,
in a case alternative
at Scratch.hs:41:3-10
‘a’ is a rigid type variable bound by
the type signature for:
def :: forall a. TypeRep a -> a
at Scratch.hs:38:1-21
• In the expression: False
In a case alternative: Is @Bool -> False
In the expression:
\case
Is @Int -> 10
Is @Bool -> False
• Relevant bindings include
def :: TypeRep a -> a (bound at Scratch.hs:39:1)
|
41 | Is @Bool -> False
|
```
But that looks wrong: it shouldn't be looking for `Typeable b0` or `Typeable b1`, it should be looking for `Typeable Int` or `Typeable Bool`. While I have not investigated further, this smells like a missing application of a substitution somewhere.https://gitlab.haskell.org/ghc/ghc/-/issues/14766Hole-y partial type signatures greatly slow down compile times2023-02-09T11:00:59ZAlec TheriaultHole-y partial type signatures greatly slow down compile timesThis time, I actually mean it. :)
Originally reported [here](https://github.com/simonmar/happy/issues/109), I distilled the example from [this comment](https://github.com/simonmar/happy/issues/109#issuecomment-362957245) into a one file...This time, I actually mean it. :)
Originally reported [here](https://github.com/simonmar/happy/issues/109), I distilled the example from [this comment](https://github.com/simonmar/happy/issues/109#issuecomment-362957245) into a one file test case. `Sigs.hs` is exactly like `NoSigs.hs`, except for the fact that it has a bunch of extra type signatures that have a lot of holes. On my machine, this is what compilation times are (I gave up timing after 15 minutes):
<table><tr><td> GHC version </td>
<td> 8.0.2 </td>
<td> 8.2.1 </td>
<td> 8.4.1 (445554b6d9a2263f969e25bb9f532dd0c3a9dc8c) </td></tr>
<tr><td> `NoSigs.hs` </td>
<td> 24.13s </td>
<td> 22.93s </td>
<td> 34.05s </td></tr>
<tr><td> `Sigs.hs` </td>
<td> \>15m </td>
<td> \~13m </td>
<td> \>15m </td></tr></table>https://gitlab.haskell.org/ghc/ghc/-/issues/22331Coercion symmetry breaks with data families2023-02-07T18:06:06ZDavid FeuerCoercion symmetry breaks with data families## Summary
I'm seeing some major fragility combining `Coercible` with data families.
## Steps to reproduce
```haskell
data family Fool a
-- This works
joe :: Coercible (Fool a) (Fool b) => Fool a -> Fool b
joe = coerce
-- This does ...## Summary
I'm seeing some major fragility combining `Coercible` with data families.
## Steps to reproduce
```haskell
data family Fool a
-- This works
joe :: Coercible (Fool a) (Fool b) => Fool a -> Fool b
joe = coerce
-- This does not
bob :: Coercible (Fool a) (Fool b) => Fool b -> Fool a
bob = coerce
```
`bob` gives me an error
```
.../Internal.hs:1036:7: error:
• Could not deduce (b ~ a) arising from a use of ‘coerce’
from the context: Coercible (Fool a) (Fool b)
bound by the type signature for:
bob :: forall a b. Coercible (Fool a) (Fool b) => Fool b -> Fool a
at ...
‘b’ is a rigid type variable bound by
the type signature for:
bob :: forall a b. Coercible (Fool a) (Fool b) => Fool b -> Fool a
at ...
‘a’ is a rigid type variable bound by
the type signature for:
bob :: forall a b. Coercible (Fool a) (Fool b) => Fool b -> Fool a
at ...
• In the expression: coerce
In an equation for ‘bob’: bob = coerce
• Relevant bindings include
bob :: Fool b -> Fool a
```
## Expected behavior
I expect `joe` and `bob` both to compile. As a worse alternative, I expect neither to compile.
## Environment
* GHC version used: 9.4
Optional:
* Operating System:
* System Architecture:9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/22436Infinite loop in typechecker/renamer on ghc 9.2.42023-02-07T17:14:17ZjberrymanInfinite loop in typechecker/renamer on ghc 9.2.4## Summary
While working on our app I noticed a small change seems to lead to an infinite loop during typechecking / renaming, during `cabal repl` or compiling without optimizations.
`-ddump-tc-trace -ddump-rn-trace` Seems to stream ...## Summary
While working on our app I noticed a small change seems to lead to an infinite loop during typechecking / renaming, during `cabal repl` or compiling without optimizations.
`-ddump-tc-trace -ddump-rn-trace` Seems to stream output forever, it also looks like all memory was consumed
maybe this is a dupe of : https://gitlab.haskell.org/ghc/ghc/-/issues/21530
## Steps to reproduce
sorry for lack of small reproducer
- clone this branch: https://github.com/jberryman/graphql-engine/tree/jberryman/11-9-22-ghc-bug-DONT-DELETE
- `$ echo 12345 > "$(git rev-parse --show-toplevel)/server/CURRENT_VERSION"`
- you likely need to install the system libraries mentioned in: `packaging/graphql-engine-base/ubuntu.dockerfile`
- `$ cabal repl lib:graphql-engine`
reverting the commit at HEAD of that branch `55937fa5` no longer exhibits issue
## Expected behavior
compilation or type error
## Environment
* GHC version used: 9.2.4
Optional:
* Operating System: debian linux
* System Architecture: x86-64Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22899type-checking regression in 9.6.1-alpha2 - interaction between ApplicativeDo ...2023-02-07T16:33:08ZGanesh Sittampalamtype-checking regression in 9.6.1-alpha2 - interaction between ApplicativeDo and polymorphic arguments?## Summary
There's a compilation regression between GHC 9.4.3 and GHC 9.6.1-alpha2 which seems to be some interaction between `ApplicativeDo` and polymorphic arguments.
Cut down example below, which compiles in GHC 9.4.3 but fails in 9...## Summary
There's a compilation regression between GHC 9.4.3 and GHC 9.6.1-alpha2 which seems to be some interaction between `ApplicativeDo` and polymorphic arguments.
Cut down example below, which compiles in GHC 9.4.3 but fails in 9.6. It compiles fine in GHC 9.6 if I do any of:
- remove `ApplicativeDo`
- reorder the first two statements in the `do`
- remove the `pure ()`
- inline `go`.
It may be related to the `ApplicativeDo` desugaring itself as I've tried and failed to reproduce the regression with manually desugaring. I also later ran into another example of a regression in an applicative do block, this time with implicit parameters, that was also fixed by reorganising the code; I can also turn that into a test case if wanted.
Now that I understand the triggers I can probably work around it fairly easily in my real code, but I thought it may still be worth investigating as I can't spot any mention in [the migration guide](https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6) or other issues.
## Steps to reproduce
```
{-# LANGUAGE ApplicativeDo #-}
module X where
x :: Maybe ()
x = do
pure ()
let go = Nothing
f go
f :: (forall p . Maybe p) -> Maybe ()
f _ = Nothing
```
With GHC 9.4.3 this compiles fine.
With GHC 9.6.0-alpha2 I get:
```
X.hs:8:5: error: [GHC-46956]
• Couldn't match type ‘a0’ with ‘p’
Expected: Maybe p
Actual: Maybe a0
because type variable ‘p’ would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context:
forall p. Maybe p
at X.hs:8:5-6
• In the first argument of ‘f’, namely ‘go’
In a stmt of a 'do' block: f go
In the expression:
do pure ()
let go = Nothing
f go
• Relevant bindings include go :: Maybe a0 (bound at X.hs:7:7)
|
8 | f go
| ^^
```
## Expected behavior
I'm not sure. Maybe it should work in GHC 9.6? Maybe my code is wrong and I just get lucky with earlier GHCs?
## Environment
* GHC version used: 9.6.1-alpha2sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22670Unclear error message for ambigous instance when instance type does not occur...2023-02-04T09:21:38ZAndreas KlebingerUnclear error message for ambigous instance when instance type does not occur in any function argument.Consider a definition like this:
```
{-# LANGUAGE ScopedTypeVariables #-}
mfbs :: forall a. FiniteBits a => Int
mfbs = finiteBitSize (undefined :: a)
```
And the resulting error message:
```
lib\BitFields\ObjFields.hs:14:9: error:
...Consider a definition like this:
```
{-# LANGUAGE ScopedTypeVariables #-}
mfbs :: forall a. FiniteBits a => Int
mfbs = finiteBitSize (undefined :: a)
```
And the resulting error message:
```
lib\BitFields\ObjFields.hs:14:9: error:
* Could not deduce (FiniteBits a0)
from the context: FiniteBits a
bound by the type signature for:
mfbs :: forall a. FiniteBits a => Int
at lib\BitFields\ObjFields.hs:14:9-37
The type variable `a0' is ambiguous
Potentially matching instances:
instance FiniteBits a => FiniteBits (And a)
-- Defined in `Data.Bits'
instance FiniteBits a => FiniteBits (Iff a)
-- Defined in `Data.Bits'
...plus five others
(use -fprint-potential-instances to see them all)
* In the ambiguity check for `mfbs'
To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
In the type signature: mfbs :: forall a. FiniteBits a => Int
|
14 | mfbs :: forall a. FiniteBits a => Int
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
This makes sense. At a call site to `mfbs` there is "obviously" no way to tell the compiler which instance to use.
But I found the error message here very unhelpful if not harmful. It says `Could not deduce (FiniteBits a0) from the context: FiniteBits a`. Why does it refer to a0 when there should be only one `a` given the use of scoped type variables? I assume this is the fallout of an implementation detail in the ambiguity check.
Maybe for a function with a type like `f :: (C a,...) => ...` we could check if `a` occurs only in the constraints and if so give a more specific warning.https://gitlab.haskell.org/ghc/ghc/-/issues/7296ghc-7 assumes incoherent instances without requiring language `IncoherentInst...2023-02-03T20:59:39ZChristian Maederghc-7 assumes incoherent instances without requiring language `IncoherentInstances`the attached examples works with ghc-7 and returns
```
*Main> a
[Spec1 Spec2]
*Main> b
[]
```
(One may wish that b also returned \[Spec1 Spec2\])
ghc-6 complains with
```
Splittable.hs:16:36:
Overlapping instances...the attached examples works with ghc-7 and returns
```
*Main> a
[Spec1 Spec2]
*Main> b
[]
```
(One may wish that b also returned \[Spec1 Spec2\])
ghc-6 complains with
```
Splittable.hs:16:36:
Overlapping instances for Test a Spec2
arising from a use of `test' at Splittable.hs:16:36-43
Matching instances:
instance [overlap ok] Test a Spec2
-- Defined at Splittable.hs:20:13-24
instance [overlap ok] Test Bool Spec2
-- Defined at Splittable.hs:25:13-27
(The choice depends on the instantiation of `a'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
In the second argument of `($)', namely `test a b'
In the expression: map Spec1 $ test a b
In the definition of `test':
test a (Spec1 b) = map Spec1 $ test a b
Failed, modules loaded: none.
```
After adding `IncoherentInstances` the file also goes through ghc-6 with the same results.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sternkinder@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-7 assumes incoherent instances without requiring language `IncoherentInstances`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sternkinder@gmail.com"],"type":"Bug","description":"the attached examples works with ghc-7 and returns\r\n\r\n{{{\r\n *Main> a\r\n [Spec1 Spec2]\r\n *Main> b\r\n []\r\n}}}\r\n\r\n(One may wish that b also returned [Spec1 Spec2])\r\n\r\nghc-6 complains with\r\n\r\n{{{\r\nSplittable.hs:16:36:\r\n Overlapping instances for Test a Spec2\r\n arising from a use of `test' at Splittable.hs:16:36-43\r\n Matching instances:\r\n instance [overlap ok] Test a Spec2\r\n -- Defined at Splittable.hs:20:13-24\r\n instance [overlap ok] Test Bool Spec2\r\n -- Defined at Splittable.hs:25:13-27\r\n (The choice depends on the instantiation of `a'\r\n To pick the first instance above, use -XIncoherentInstances\r\n when compiling the other instance declarations)\r\n In the second argument of `($)', namely `test a b'\r\n In the expression: map Spec1 $ test a b\r\n In the definition of `test':\r\n test a (Spec1 b) = map Spec1 $ test a b\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\nAfter adding `IncoherentInstances` the file also goes through ghc-6 with the same results.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/14331Overzealous free-floating kind check causes deriving clause to be rejected2023-02-01T20:13:20ZRyan ScottOverzealous free-floating kind check causes deriving clause to be rejectedGHC rejects this program:
```hs
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
class C a b
data D = D deriving (C (a :: k))
```
```
GHCi, version 8.2.1: http://www.h...GHC rejects this program:
```hs
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
class C a b
data D = D deriving (C (a :: k))
```
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:8:1: error:
Kind variable ‘k’ is implicitly bound in datatype
‘D’, but does not appear as the kind of any
of its type variables. Perhaps you meant
to bind it (with TypeInType) explicitly somewhere?
|
8 | data D = D deriving (C (a :: k))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
But it really shouldn't, since it's quite possible to write the code that is should generate:
```hs
instance C (a :: k) D
```
Curiously, this does not appear to happen for data family instances, as this typechecks:
```hs
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
class C a b
data family D1
data instance D1 = D1 deriving (C (a :: k))
class E where
data D2
instance E where
data D2 = D2 deriving (C (a :: k))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Overzealous free-floating kind check causes deriving clause to be rejected","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC rejects this program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\nclass C a b\r\n\r\ndata D = D deriving (C (a :: k))\r\n}}}\r\n\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\n\r\nBug.hs:8:1: error:\r\n Kind variable ‘k’ is implicitly bound in datatype\r\n ‘D’, but does not appear as the kind of any\r\n of its type variables. Perhaps you meant\r\n to bind it (with TypeInType) explicitly somewhere?\r\n |\r\n8 | data D = D deriving (C (a :: k))\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nBut it really shouldn't, since it's quite possible to write the code that is should generate:\r\n\r\n{{{#!hs\r\ninstance C (a :: k) D\r\n}}}\r\n\r\nCuriously, this does not appear to happen for data family instances, as this typechecks:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nclass C a b\r\n\r\ndata family D1\r\ndata instance D1 = D1 deriving (C (a :: k))\r\n\r\nclass E where\r\n data D2\r\n\r\ninstance E where\r\n data D2 = D2 deriving (C (a :: k))\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/21405Assertion in reportWanteds is too strict2023-02-01T08:38:59Zsheafsam.derbyshire@gmail.comAssertion in reportWanteds is too strictThere's an assertion in `reportWanteds` that checks that we aren't suppressing all the errors.
```haskell
-- This check makes sure that we aren't suppressing the only error that will
-- actually stop compilation
; ...There's an assertion in `reportWanteds` that checks that we aren't suppressing all the errors.
```haskell
-- This check makes sure that we aren't suppressing the only error that will
-- actually stop compilation
; massert $
null simples || -- no errors to report here
any ignoreConstraint simples || -- one error is ignorable (is reported elsewhere)
not (all ei_suppress tidy_items) -- not all errors are suppressed
```
This is in the context of "Wanteds rewrite Wanteds", where we should always have one non-rewritten Wanted to report to the user.
This makes sense, but it doesn't seem to take into account implications. For instance, we could have an implication:
```
[W] hole{co1}
===>
[W] hole{co2} {{co1}} :: alpha ~# (beta |> co)
```
When we call `reportWanteds` on this implication, we have the unsolved unrewritten `[W] hole{co1}` to report. Fine. Then we recurse into the implication, and we have a single constraint `[W] hole{co2}` to report, which has been rewritten by `[W] hole{co1}`. This trips up the assertion (we only have rewritten Wanteds to report), even though at an outer level we reported an unrewritten Wanted.
@rae, do you agree that the assertion is wrong?https://gitlab.haskell.org/ghc/ghc/-/issues/22526Impredicative kinds & type synonyms seemingly don't work together2023-01-26T11:56:59ZLas SafinImpredicative kinds & type synonyms seemingly don't work together## Steps to reproduce
```haskell
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ImpredicativeTypes #-}
import Data.Proxy (Proxy)
import Data.Functor.Identity (Identity (Identity))
import Data.Kind (Type)
-- Changing ...## Steps to reproduce
```haskell
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE ImpredicativeTypes #-}
import Data.Proxy (Proxy)
import Data.Functor.Identity (Identity (Identity))
import Data.Kind (Type)
-- Changing this to a type family doesn't work either (EDIT: see new comment)
type P :: forall a. a -> Type
type P = Proxy
type Good :: Identity (forall a. a -> Type)
type Good = 'Identity @(forall a. a -> Type) Proxy
type Bad :: Identity (forall a. a -> Type)
type Bad = 'Identity @(forall a. a -> Type) P
{-
Example.hs:17:45: error:
• Expected kind ‘forall a. a -> Type’,
but ‘P’ has kind ‘a0 -> Type’
• In the second argument of ‘'Identity’, namely ‘P’
In the type ‘'Identity @(forall a. a -> Type) P’
In the type declaration for ‘Bad’
|
17 | type Bad = 'Identity @(forall a. a -> Type) P
-}
```
## Expected behavior
`Bad` should seemingly also work, but I would be satisfied with a work-around if there is one.
## Environment
* GHC version used: 9.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/19690Bottom dictionaries can be derived with QuantifiedConstraints, UndecidableIns...2023-01-26T04:02:51Zaadaa-fgtaaBottom dictionaries can be derived with QuantifiedConstraints, UndecidableInstances and UndecidableSuperClasses[I'm not sure if this is a bug or documentation issue. I'd prefer the former so I applied "bug" template]
## Summary
With `QuantifiedConstraints`, `UndecidableInstances` and `UndecidableSuperClasses` it is possible to
produce bottom di...[I'm not sure if this is a bug or documentation issue. I'd prefer the former so I applied "bug" template]
## Summary
With `QuantifiedConstraints`, `UndecidableInstances` and `UndecidableSuperClasses` it is possible to
produce bottom dictionary, which isn't mentioned in docs as far as I can see.
## Steps to reproduce
```haskell
{-# LANGUAGE UndecidableInstances, UndecidableSuperClasses, ConstraintKinds, FlexibleInstances,
GADTs, QuantifiedConstraints, TypeApplications, ScopedTypeVariables #-}
module QCLoop where
class c => Hold c
instance c => Hold c
data Dict c = c => Dict
anythingDict :: Dict c
anythingDict = go
where
go :: (Hold c => c) => Dict c
go = Dict
```
Produces bottom dictionary
```haskell
Rec {
$dHold_rxi :: forall {c :: Constraint}. Hold c
$dHold_rxi = $dHold_rxi
end Rec }
anythingDict :: forall (c :: Constraint). Dict c
anythingDict = \ (@c) -> Dict ($dHold_rxi `cast` <Co:2>)
```
## Expected behavior
Either the program is rejected with "could not deduce c" or "too many iterations", or documentation for
`UndecidableInstances` and/or `UndecidableSuperClasses` mentions that they may result in
non-termination not only in typechecker but also at runtime.
I would really prefer the former as the ability to "prove" anything with such code scares me a bit.
## Environment
* GHC version used: 8.10.4, 9.0.1 and 9.1.20210409
* Operating System: Linux (NixOS)
* System Architecture: x86-64https://gitlab.haskell.org/ghc/ghc/-/issues/22811Typechecking Failure When Going From Two “Forall”-quantified Variables to a S...2023-01-24T16:04:09ZNathaniel BurkeTypechecking Failure When Going From Two “Forall”-quantified Variables to a Single One (But Works Fine in Reverse)## Summary
GHC will accept converting from `forall (a :: Type) (b :: Type). Foo '(a, b)` to `forall (p :: (Type, Type)). Foo p` but not the other way around.
## Steps to reproduce
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-...## Summary
GHC will accept converting from `forall (a :: Type) (b :: Type). Foo '(a, b)` to `forall (p :: (Type, Type)). Foo p` but not the other way around.
## Steps to reproduce
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
import Data.Kind (Type)
data Foo :: (Type, Type) -> Type where
Foo :: forall p. Foo p
test1 :: forall p. Foo p
test1 = Foo
test2 :: forall a b. Foo '( a, b)
test2 = test1
test3 :: forall a b. Foo '( a, b)
test3 = Foo
-- Error here
test4 :: forall p. Foo p
test4 = test3
```
Trying to compile this code will output:
```
Test.hs:20:9: error:
* Couldn't match type `p' with '(a0, b0)
Expected: Foo p
Actual: Foo '(a0, b0)
`p' is a rigid type variable bound by
the type signature for:
test4 :: forall (p :: (*, *)). Foo p
at Test.hs:19:1-24
* In the expression: test3
In an equation for `test4': test4 = test3
* Relevant bindings include test4 :: Foo p (bound at Test.hs:20:1)
|
20 | test4 = test3
| ^^^^^
Failed, no modules loaded.
```
Explicitly annotating the kind of `p` like:
```hs
test4 :: forall (p :: (Type, Type)). Foo p
test4 = test3
```
does not help.
## Expected behavior
No compile error, definition of `test4` typechecks.
## Environment
* GHC version used: 9.4.4