GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-05-02T15:39:25Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23321Panic on piResultTys12023-05-02T15:39:25ZRodrigo MesquitaPanic on piResultTys1I've come across a GHC panic which I wasn't able to reproduce after I cleaned cabal's build directory.
Unfortunately there might not be much to do about this except for a quick audit of the code that might lead to the bug.
Otherwise, I...I've come across a GHC panic which I wasn't able to reproduce after I cleaned cabal's build directory.
Unfortunately there might not be much to do about this except for a quick audit of the code that might lead to the bug.
Otherwise, I think we can close this until it comes up in a reproducible environment.
I just thought it might be useful to at least report.
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.4:
piResultTys1
Type
[MappedBuffer]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:1397:5 in ghc:GHC.Core.Type
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```https://gitlab.haskell.org/ghc/ghc/-/issues/23308Panic on malformed newtype2023-05-18T20:00:47ZPedro MiniczPanic on malformed newtypeThe following causes a panic on GHC 9.6.1:
```haskell
data A = A !B
newtype B = B C C
data C = C A
```
Result:
```text
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.1:
mkNewTyConRhs
B [C, C...The following causes a panic on GHC 9.6.1:
```haskell
data A = A !B
newtype B = B C C
data C = C A
```
Result:
```text
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.1:
mkNewTyConRhs
B [C, C]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Tc/TyCl/Build.hs:70:27 in ghc:GHC.Tc.TyCl.Build
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
```
GHC versions 9.4.5 and 9.2.5 do not panic and report the error correctly. I haven't tested other versions.
This is similar to #15523.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23224Type inference for nested bindings2023-05-08T16:21:36ZSimon Peyton JonesType inference for nested bindingsThis ticket is spun out from [a side-saga in !10123](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123#note_490721).
In the package `statistics` this extremely delicate function is in `Statistic.Sample.Histogram`:
```
histogram_...This ticket is spun out from [a side-saga in !10123](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123#note_490721).
In the package `statistics` this extremely delicate function is in `Statistic.Sample.Histogram`:
```
histogram_ :: (Num b, RealFrac a, G.Vector v0 a, G.Vector v1 b) =>
Int -> a -> a -> v0 a -> v1 b
histogram_ numBins lo hi xs0 = G.create (GM.replicate numBins 0 >>= bin xs0)
where
bin xs bins = go 0
where
go i | i >= len = return bins
| otherwise = do
let x = xs `G.unsafeIndex` i
b = truncate $ (x - lo) / d
write' bins b . (+1) =<< GM.read bins b
go (i+1)
write' bins' b !e = GM.write bins' b e
len = G.length xs
d = ((hi - lo) / fromIntegral numBins) * (1 + realToFrac m_epsilon)
```
Here `bin` gets this inferred type:
```
bin :: forall {m1 :: * -> *} {v1 :: * -> *} {v2 :: * -> * -> *} {b1}.
(GM.PrimMonad m1, G.Vector v1 a)
=> v1 a -> v2 (GM.PrimState m1) b1 -> m (v2 (GM.PrimState m1) b1)
```
And `go` ends up with this inferred type:
```
go :: forall m2. (GM.PrimState m2 ~ GM.PrimState m1, GM.PrimMonad m2)
=> Int -> m2 (v2 (GM.PrimState m1) b1)
```
Critically, `go` has the following residual constraint
```
[W] Num b1
[W] GM.MVector v2 b1
```
The problem is that *`bin` is quantified over `b1`, but not over `Num b1`*. So in the end we get a complaint that `Num b1` isn't solvable, as indeed it isn't in
`bin`'s definition (which remember has a `forall b1` at the top).
**It is a mistake to quantify over `b1` but not over constraints that mention `b1`**! Why does that happen? Because currently:
* `approximateWC` ignores *all* constraints under an equality
The function `go` has just such an equality, so the `approximateWC` for `bin`
sees:
```
WC { wc_simple = ...bin's simple constraints...
, wc_implict = IC { ic_info = "Binding for g"
, ic_skols = m2 -- g's foralls
, ic_givens = (PrimState m2 ~ PrimState m1), ...
, ic_wanteds = [W] Num b1, ... } }
```
Note that equality wrapping the `Num b1` constraint.
**Conclusion**. Gah! With these doubly-nested definitions, type familes, etc, it is not
surprising that type inference is terribly delicate.
## The right solution
The right solution is to add type signatures. Here they are.
So much simpler than the ones GHC infers, and they make the code
vastly easier to understand:
```
histogram_ :: forall a b v0 v1.
(Num b, RealFrac a, G.Vector v0 a, G.Vector v1 b) =>
Int -> a -> a -> v0 a -> v1 b
bin :: forall s. v0 a -> Mutable v1 s b -> ST s (Mutable v1 s b)
go :: Int -> ST s (Mutable v1 s b)
```
We need a couple of extra imports to support these signatures:
```
import Control.Monad.ST( ST )
import Data.Vector.Generic.Base( Mutable )
```
## The "make GHC cleverer" solution
We can make `approximateWC` a bit cleverer. Read `Note [ApproximateWC]` in
GHC.Tc.Solver. You'll see that the reason for not
floating a constraint past an equality is really all about *equality*
constraints.
However, we can probably float *class* constraints just fine. In
general, abstracting over too *many* constraints is fine -- it just
moves them to the call site.
The ice is thin here. But in these very subtle situations, it's best
to write a type signature anyway.
When partial type signatures are involved, it's even more tricky: see #19106.https://gitlab.haskell.org/ghc/ghc/-/issues/23199Bogus no_fixed_dependencies test in pickQuantifiablePreds2023-05-08T16:21:37ZSimon Peyton JonesBogus no_fixed_dependencies test in pickQuantifiablePredsConsider this module:
```haskell
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
module Foo where
class C a b c | b -> c where
op :: a -> b -> c
bar1 :: C a Int Char => a -> Char
bar1 x = op x (3 :: Int) :: Char
bar2 ...Consider this module:
```haskell
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
module Foo where
class C a b c | b -> c where
op :: a -> b -> c
bar1 :: C a Int Char => a -> Char
bar1 x = op x (3 :: Int) :: Char
bar2 x = op x (3 :: Int) :: Char
```
`bar1` is accepted by GHC 9.6, but `bar2` is rejected:
```
Foo.hs:11:10: error: [GHC-39999]
• No instance for ‘C a Int Char’ arising from a use of ‘op’
• In the expression: op x (3 :: Int) :: Char
In an equation for ‘bar2’: bar2 x = op x (3 :: Int) :: Char
```
Why?
Look in GHC.Tc.Solver,
`Note [Do not quantify over constraints that determine a variable]`.
The acual test is
```haskell
no_fixed_dependencies cls tys
= and [ qtvs `intersectsVarSet` tyCoVarsOfTypes fd_lhs_tys
| fd <- cls_fds
, let (fd_lhs_tys, _) = instFD fd cls_tvs tys ]
where
(cls_tvs, cls_fds) = classTvsFds cls
```
So when inferring `bar2`'s type we have
the constraint `[W] C alpha Int Char`, where we are planning to quantify
over `alpha`. That should be absolutely fine. But bizarrely the
`no_fixed_dependencies` test decides not to quantify over this constraint
on the grounds that there is a fundep `b -> c` whose LHS (here just `Int`)
does not mention a quantified variable.
Utterly wrong. And in fact *this* is why we mysteriously do not quantify
over the `Add (T m) m2 Int)` constraint in #22194,
see [this comment](https://gitlab.haskell.org/ghc/ghc/-/issues/22194#note_453533).https://gitlab.haskell.org/ghc/ghc/-/issues/23192A constraint is both redundant and not deducible.2023-05-08T16:21:35ZPhil de JouxA constraint is both redundant and not deducible.## Summary
GHC says that a constraint is redundant but then says the constraint is not deducible if I remove it.
## Steps to reproduce
From the [redundant-but-not-deducible](https://github.com/typechecker/redundant-but-not-deducible) ...## Summary
GHC says that a constraint is redundant but then says the constraint is not deducible if I remove it.
## Steps to reproduce
From the [redundant-but-not-deducible](https://github.com/typechecker/redundant-but-not-deducible) package:
```haskell
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# OPTIONS_GHC -Werror=redundant-constraints #-}
module EventThing where
class Monad m => Event m where
thingsForEvent :: m [Int]
things :: Event m => m [Int]
things = thingsForEvent
-- class Thingy m where
class Monad m => Thingy m where
thingies :: m [Int]
-- instance Event m => Thingy m where
instance (Monad m, Event m) => Thingy m where
thingies = things
```
With `ghc-9.2.3 .. ghc-9.4.4` (but not in `ghc-9.6.1`) this module fails to
compile with the following error:
```
src/EventThing.hs error: [-Wredundant-constraints, -Werror=redundant-constraints]
• Redundant constraint: Monad m
• In the instance declaration for ‘Thingy m’
|
__ | instance (Monad m, Event m) => Thingy m where
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Removing the redundant constraint, the module then also fails:
```
src/EventThing.hs: error:
• Could not deduce (Monad m)
arising from the superclasses of an instance declaration
from the context: Event m
bound by the instance declaration at src/EventThing.hs
Possible fix:
add (Monad m) to the context of the instance declaration
• In the instance declaration for ‘Thingy m’
|
__ | instance Event m => Thingy m where
| ^^^^^^^^^^^^^^^^^^^
```
Using the commented out class and instance lines, the module compiles without error.
## Expected behavior
If a constraint is redundant then removing it should be no problem.
## Environment
The `module EventThing` compiles with `ghc-8.10.7 .. ghc-9.2.2` fine but from
`ghc-9.2.3 .. ghc-9.4.4` it doesn't. With `ghc-9.6.1` it is good again.
* Operating System: ubuntu-22.04
* System Architecture: x86_64sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23171Panic ltPSize2023-05-16T11:56:13ZChris WendtPanic ltPSize## Summary
Write a brief description of the issue.
## Steps to reproduce
- Compile GHC at https://gitlab.haskell.org/chrismwendt/ghc/-/tree/994062840b5c77c76dfed0644ac4059d7e2de136. That commit is only one tiny commit ahead of this co...## Summary
Write a brief description of the issue.
## Steps to reproduce
- Compile GHC at https://gitlab.haskell.org/chrismwendt/ghc/-/tree/994062840b5c77c76dfed0644ac4059d7e2de136. That commit is only one tiny commit ahead of this commit on upstream's master: https://gitlab.haskell.org/ghc/ghc/-/tree/ee17001e54c3c6adccc5e3b67b629655c14da43a.
- Clone and checkout https://github.com/chrismwendt/ghci-reload-error-monadic-bang/tree/dd610a35522ffc265bf72c58cc3717d4a1fb4101
Run a `stack build` with that GHC version on the path:
```
$ ls -lh bin
total 0
lrwxr-xr-x 1 chrismwendt staff 67B Mar 16 02:25 ghc-9.4.4@ -> /Users/chrismwendt/gitlab.haskell.org/ghc/ghc/_build/stage1/bin/ghc
$ env PATH="$PWD/bin:$PATH" stack build
Warning: Stack has not been tested with GHC versions above 9.4, and using 9.7.20230316, this may fail.
Warning: Stack has not been tested with Cabal versions above 3.8, but version 3.9.0.0 was found, this may fail.
Warning: WARNING: Ignoring monadic-bang's bounds on transformers (^>=0.5.6.2); using transformers-0.6.1.0.
Reason: allow-newer enabled.
monadic-bang > build (lib)
monadic-bang > Preprocessing library for monadic-bang-0.1.0.0..
monadic-bang > Building library for monadic-bang-0.1.0.0..
monadic-bang > [6 of 8] Compiling MonadicBang.Utils [Source file changed]
monadic-bang > [7 of 8] Compiling MonadicBang.Internal
monadic-bang >
monadic-bang > <no location info>: error:
monadic-bang > panic! (the 'impossible' happened)
monadic-bang > GHC version 9.7.20230316:
monadic-bang > ltPSize
monadic-bang > HandleFailure
monadic-bang > Call stack:
monadic-bang > CallStack (from HasCallStack):
monadic-bang > callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
monadic-bang > pprPanic, called at compiler/GHC/Tc/Utils/TcType.hs:2428:5 in ghc:GHC.Tc.Utils.TcType
monadic-bang > CallStack (from HasCallStack):
monadic-bang > panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
monadic-bang >
monadic-bang >
monadic-bang > Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
monadic-bang >
```
## Expected behavior
Not panic.
## Environment
Optional:
* Operating System: macOS Ventura 13.2.1
* System Architecture: ARM M19.6.2sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23084Can't infer type2023-03-07T15:25:13ZIcelandjackCan't infer typeThis is from an old ghc though (ghc 8.10.0.20191123):
```haskell
{-# Language BlockArguments #-}
{-# Language DerivingStrategies #-}
{-# Language GADTs #-}
{-# Language InstanceSigs #-}
{-#...This is from an old ghc though (ghc 8.10.0.20191123):
```haskell
{-# Language BlockArguments #-}
{-# Language DerivingStrategies #-}
{-# Language GADTs #-}
{-# Language InstanceSigs #-}
{-# Language StandaloneKindSignatures #-}
{-# Language TypeApplications #-}
import Type.Reflection
import Data.Kind
import Data.Maybe
import Control.Monad
type Name :: Type -> Type
data Name a
= FreeName String Int
| BoundName Int Int
deriving stock Eq
type AnyName :: Type
data AnyName where
AnyName :: TypeRep a -> Name a -> AnyName
instance Eq AnyName where
(==) :: AnyName -> AnyName -> Bool
AnyName rep name == AnyName rep' name' = isJust @() do
HRefl <- eqTypeRep rep rep'
guard (name == name')
```
I tried this and it worked, but when I omitted the type argument for `isJust`
```haskell
{-
error:
• Couldn't match type ‘a0’ with ‘()’
‘a0’ is untouchable
inside the constraints: (* ~ *, a1 ~ a)
bound by a pattern with constructor:
HRefl :: forall k1 (a :: k1). a :~~: a,
in a pattern binding in
a 'do' block
at ..:26:5-9
Expected type: Maybe a0
Actual type: Maybe ()
• In a stmt of a 'do' block: guard (name == name')
In the first argument of ‘isJust’, namely
‘do HRefl <- eqTypeRep rep rep'
guard (name == name')’
In the expression:
isJust
do HRefl <- eqTypeRep rep rep'
guard (name == name')
|
27 | guard (name == name')
| ^^^^^^^^^^^^^^^^^^^^^
-}
instance Eq AnyName where
(==) :: AnyName -> AnyName -> Bool
AnyName rep name == AnyName rep' name' = isJust do
HRefl <- eqTypeRep rep rep'
guard (name == name')
```
but shouldn't it be able to infer the unit type?sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://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/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/23017Remove loopy superclass solve mechanism in GHC 9.102023-11-15T18:52:22Zsheafsam.derbyshire@gmail.comRemove loopy superclass solve mechanism in GHC 9.10For migration purposes, we re-instated the mechanism which allows GHC to solve a superclass constraint with another superclass constraint in a way which might not terminate at runtime (see MR !9921). Whenever this behaviour is relied upo...For migration purposes, we re-instated the mechanism which allows GHC to solve a superclass constraint with another superclass constraint in a way which might not terminate at runtime (see MR !9921). Whenever this behaviour is relied upon, we get a warning (starting from GHC 9.6), which says that this will stop working in GHC 9.10. This ticket tracks the task of removing this feature in GHC 9.10.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/22987Regression in newtype coercions between 9.6.0-alpha2 and alpha32023-03-30T18:38:53ZBodigrimRegression in newtype coercions between 9.6.0-alpha2 and alpha3```haskell
module Lib where
import Data.Coerce
newtype Fix f = Fix (f (Fix f))
data FooF r = A | B r
type Foo = Fix FooF
newtype NewFoo = NewFoo Foo
newFoo :: NewFoo -> Bool
newFoo x = case y of
Fix A -> True
_ -> False
where...```haskell
module Lib where
import Data.Coerce
newtype Fix f = Fix (f (Fix f))
data FooF r = A | B r
type Foo = Fix FooF
newtype NewFoo = NewFoo Foo
newFoo :: NewFoo -> Bool
newFoo x = case y of
Fix A -> True
_ -> False
where
y = coerce x
```
This program compiles in GHC 9.2, 9.4 and 9.6.0-alpha2, but not in 9.6.0-alpha3.
```
$ ghc-9.6.0.20230128 NewFoo.hs
[1 of 1] Compiling Lib ( NewFoo.hs, NewFoo.o )
$ ghc-9.6.0.20230210 NewFoo.hs
[1 of 1] Compiling Lib ( NewFoo.hs, NewFoo.o )
NewFoo.hs:18:9: error:
• Reduction stack overflow; size = 201
When simplifying the following type: Fix FooF
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the expression: coerce x
In an equation for ‘y’: y = coerce x
In an equation for ‘newFoo’:
newFoo x
= case y of
Fix A -> True
_ -> False
where
y = coerce x
|
18 | y = coerce x
| ^^^^^^
$ ghc-9.6.0.20230210 -freduction-depth=0 NewFoo.hs
[1 of 1] Compiling Lib ( NewFoo.hs, NewFoo.o )
ghc-9.6.0.20230210: Stack space overflow: current size 33616 bytes.
ghc-9.6.0.20230210: Use `+RTS -Ksize -RTS' to increase it.
```
I have no particular opinion whether this behaviour is expected and/or desired. However, my concern is twofold:
* Technical: release notes does not seem to have anything related, I cannot find any mentions of "newtype".
* Social: breaking changes to the type checker between alpha2 and alpha3 push maintainers to delay releases until the very final GHC 9.6.1, thus causing the ecosystem to lag behind even longer (and a new GHC to be battle tested even later).9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/22985ASSERT failed! compiler/GHC/Core/RoughMap.hs:356 mfsolve package2023-11-15T17:25:22ZMatthew PickeringASSERT failed! compiler/GHC/Core/RoughMap.hs:356 mfsolve packageMinimised to one file but could be minimised further. It's something to do with the synonym `type Phase n = n`.
Failure found here: https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/283
```haskell
{-# LANGUAGE DeriveGeneric,...Minimised to one file but could be minimised further. It's something to do with the synonym `type Phase n = n`.
Failure found here: https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/283
```haskell
{-# LANGUAGE DeriveGeneric, PatternGuards, PatternSynonyms,
MultiParamTypeClasses, FlexibleContexts, DeriveDataTypeable,
GeneralizedNewtypeDeriving #-}
{-
-}
module Math.MFSolve (addTrigTerms)
where
data Expr v n = Expr (LinExpr v n) [TrigTerm v n]
-- | A linear expression of several variables.
-- For example: @2*a + 3*b + 2@ would be represented as
-- @LinExpr 2 [(a, 2), (b, 3)]@.
data LinExpr v n = LinExpr n [(v, n)]
type Period v n = [(v, n)]
type Phase n = n
type TrigTerm v n = ([(v, n)], [(Phase n, LinExpr v n)])
data HM k a
-- | An angular function of the form @c + n*sin(theta + alpha)@
-- where @theta@, and @n@ are linear terms, @alpha@ and @c@ are constants.
type LinearMap v n = HM v (LinExpr v n)
type TrigEq v n = (Period v n, LinExpr v n, Phase n, n)
type TrigEq2 v n = HM (Period v n)
(HM v (Expr v n))
pattern LConst c = LinExpr c
addLin :: (Ord v, Num n, Eq n) => LinExpr v n -> LinExpr v n -> LinExpr v n
addLin (LinExpr c1 terms1) (LinExpr c2 terms2) = undefined
addExpr :: (Ord n, Ord v, Floating n) => Expr v n -> Expr v n -> Expr v n
addExpr (Expr lt1 trig1) (Expr lt2 trig2) =
Expr (addLin lt1 lt2) trig3
where
trig3 = merge trig1 trig2 addTrigTerms
-- merge two association lists, by combining equal keys with
-- the given function, and keeping keys sorted.
merge :: Ord k => [(k, v)] -> [(k, v)] -> (v -> v -> v) -> [(k, v)]
merge [] l _ = l
merge l [] _ = l
merge (a@(k,v):as) (b@(k2,v2):bs) f = case compare k k2 of
LT -> a: merge as (b:bs) f
EQ -> (k, f v v2): merge as bs f
GT -> b: merge (a:as) bs f
-- add trigonometric terms with the same period
addTrigTerms :: (Ord a, Ord t, Floating a)
=> [(a, LinExpr t a)] -> [(a, LinExpr t a)]
-> [(a, LinExpr t a)]
addTrigTerms [] p = p
addTrigTerms terms terms2 =
foldr mergeTerms terms terms2
where
mergeTerms (alpha, n) ((beta, m):rest) =
case addTrigTerm alpha n beta m of
Just (_, LConst 0) -> rest
Just (gamma, o) ->
mergeTerms (gamma, o) rest
Nothing ->
(beta, m) : mergeTerms (alpha, n) rest
mergeTerms a [] = [a]
```
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230214:
ASSERT failed!
Phase
Call stack:
CallStack (from HasCallStack):
assertPpr, called at compiler/GHC/Core/RoughMap.hs:356:5 in ghc:GHC.Core.RoughMap
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
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://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/22912Introduce a warning for possibly loopy superclass solve2023-04-02T20:27:10Zsheafsam.derbyshire@gmail.comIntroduce a warning for possibly loopy superclass solveIn https://gitlab.haskell.org/ghc/ghc/-/issues/20666#note_479125, @simonpj suggests a mechanism which would allow us to provide a deprecation period for the changes introduced by MR !7050. These changes are necessary to avoid constructin...In https://gitlab.haskell.org/ghc/ghc/-/issues/20666#note_479125, @simonpj suggests a mechanism which would allow us to provide a deprecation period for the changes introduced by MR !7050. These changes are necessary to avoid constructing non-terminating class dictionaries, as explained in `Note [Recursive superclasses]` in `GHC.Tc.TyCl.Instance`, but can be counter-intuitive to users and cause breakage to their libraries. So it seems more prudent to introduce a flag, on by default, which temporarily allows this prohibited superclass solving mechanism but emits a loud warning whenever this happens, suggesting that the user fix the code and turn off the flag.
These tickets are examples of the breakage that immediate adoption caused:
* #22891
* #20666
* #22894
* #22905
* #11762
* #114279.6.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22911Kind equality should be part of `checkEqType`2023-03-30T07:14:37ZSimon Peyton JonesKind equality should be part of `checkEqType`The function `GHC.Tc.Utils.checkEqType` checks the invariants demanded of a canonical equality constraint, and reports which ones do not hold. Alas, it omits one very important one: checking that
```
typeKind t1 `eqType` typeKind t2
...The function `GHC.Tc.Utils.checkEqType` checks the invariants demanded of a canonical equality constraint, and reports which ones do not hold. Alas, it omits one very important one: checking that
```
typeKind t1 `eqType` typeKind t2
```
This ticket is to propose that we move that test into `checkEqType`.
In the call from `GHC.Tc.Utils.Unify` that would be a nice improvement. But in `GHC.Tc.Solver.Canonical` we check for the kind-inhomogenity` rather early, and it's not immediately obvious to me how to refactor. And yet it would clearly be a Good Thing to do so.
@rae: any opinions?https://gitlab.haskell.org/ghc/ghc/-/issues/22908too eager constraint simplification(?) for nullary type classes without exist...2023-10-12T15:54:29ZBertram Felgenhauertoo eager constraint simplification(?) for nullary type classes without existing instance## Summary
Type inference involving nullary classes without any instance is too eager.
## Steps to reproduce
Consider the following interaction with `ghci`:
```
ghci> :set -XMultiParamTypeClasses
ghci> class Foo where foo :: Int
ghc...## Summary
Type inference involving nullary classes without any instance is too eager.
## Steps to reproduce
Consider the following interaction with `ghci`:
```
ghci> :set -XMultiParamTypeClasses
ghci> class Foo where foo :: Int
ghci> :t foo -- expected: foo :: Foo => Int
<interactive>:1:1: error:
• No instance for Foo arising from a use of ‘foo’
• In the expression: foo
ghci> bar () = foo -- expected to work without type signature
<interactive>:4:10: error:
• No instance for Foo arising from a use of ‘foo’
• In the expression: foo
In an equation for ‘bar’: bar () = foo
ghci> bar :: Foo => () -> Int; bar () = foo
```
or the following module which fails to compile:
```
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo where foo :: Int
-- bar :: Foo => () -> Int
bar () = foo
{-
[1 of 2] Compiling Main ( Foo.hs, Foo.o )
Foo.hs:6:10: error:
• No instance for Foo arising from a use of ‘foo’
• In the expression: foo
In an equation for ‘bar’: bar () = foo
|
6 | bar () = foo
| ^^^
-}
```
These examples start working once an instance for `Foo` is provided.
## Expected behavior
I expected GHC to infer types of the shape `Foo => ...` rather than producing type errors.
## Environment
* GHC version used: 9.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/22891Regression in superclass inference between GHC 9.6.0 alpha1 and alpha22023-03-03T16:25:41ZBodigrimRegression in superclass inference between GHC 9.6.0 alpha1 and alpha2**See master ticket #22912**
```haskell
{-# LANGUAGE UndecidableInstances #-}
module Foo where
class Foo f
class Foo f => Bar f g
instance Bar f f => Bar f (h k)
```
This program used to compile with GHC 9.2, 9.4 and 9.6.0-alpha1, ...**See master ticket #22912**
```haskell
{-# LANGUAGE UndecidableInstances #-}
module Foo where
class Foo f
class Foo f => Bar f g
instance Bar f f => Bar f (h k)
```
This program used to compile with GHC 9.2, 9.4 and 9.6.0-alpha1, but suddenly stopped to compile with 9.6.0-alpha2, which now complains that
```
programs$ ghc-9.6.0.20230128 -fforce-recomp Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:9:10: error: [GHC-39999]
• Could not deduce ‘Foo f’
arising from the superclasses of an instance declaration
from the context: Bar f f
bound by the instance declaration at Foo.hs:9:10-31
Possible fix:
add (Foo f) to the context of the instance declaration
• In the instance declaration for ‘Bar f (h k3)’
|
9 | instance Bar f f => Bar f (h k)
| ^^^^^^^^^^^^^^^^^^^^^^
```
Is this regression expected? [Release notes](https://gitlab.haskell.org/ghc/ghc/-/blob/master/docs/users_guide/9.6.1-notes.rst) are silent about it. [Migration guide](https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6#superclass-expansion-is-more-conservative) mentions changes to superclass expansion involving type families (BTW this is missing from release notes), but there are no type families in my example and there is no suggestion of "Possible fix: If the constraint looks soluble from a superclass of the instance context, read 'Undecidable instances and loopy superclasses' in the user manual".
If this regression is still an expected consequence of #20666 / !7050, please include it in the release notes and amend migration guide, clarifying that regressions are not limited to superclasses involving type families. I suggest to use it instead the current example in the migration guide: this case is clearly much simpler (and much more surprising, if I may say). I would also expect to receive a suggestion to read "Undecidable instances and loopy superclasses", as the migration guide advertises.9.6.1Simon Peyton JonesRichard Eisenbergrae@richarde.devsheafsam.derbyshire@gmail.comSimon Peyton Joneshttps://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.4https://gitlab.haskell.org/ghc/ghc/-/issues/22793Type checker crash with some polykinded junk2023-03-04T07:32:24ZDavid FeuerType checker crash with some polykinded junk## Summary
I was doing something kind of impractical with quantified constraints
and such, and crashed the type checker. Fortunately (?) I was able to
reproduce the crash with a greatly stripped down example.
## Steps to reproduce
```...## Summary
I was doing something kind of impractical with quantified constraints
and such, and crashed the type checker. Fortunately (?) I was able to
reproduce the crash with a greatly stripped down example.
## Steps to reproduce
```haskell
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE MultiParamTypeClasses #-}
module Buggle where
import Data.Kind
type Foo :: forall k. k -> k -> Constraint
class Foo s a
bob :: forall {k1} {ks} {ka} q (p :: k1 -> q -> Type) (f :: ka -> q) (s :: ks) (t :: ks) (a :: ka) (b :: ka). Foo s a => p a (f b) -> p s (f t)
bob f = undefined
```
When I compile this, I see no error messages, but also no compilation products. `-ddump-tc-trace` includes a bunch of call stacks for whatever reason. The first to come up:
```
newNoTcEvBinds unique = axp
attemptM recovering with insoluble constraints
WC {wc_impl =
Implic {
TcLevel = 1
Skolems =
Given-eqs = NoGivenEqs
Status = Unsolved
Given =
Wanted =
WC {wc_impl =
Implic {
TcLevel = 1
Skolems =
Given-eqs = NoGivenEqs
Status = Unsolved
Given =
Wanted =
WC {wc_impl =
Implic {
TcLevel = 2
Skolems = k1_auh[sk:2]
ks_aui[sk:2]
ka_auj[sk:2]
q_auk[sk:2]
(p_aul[sk:2] :: k1_auh[sk:2] -> q_auk[sk:2] -> *)
(f_aum[sk:2] :: ka_auj[sk:2] -> q_auk[sk:2])
(s_aun[sk:2] :: ks_aui[sk:2])
(t_auo[sk:2] :: ks_aui[sk:2])
(a_aup[sk:2] :: ka_auj[sk:2])
(b_auq[sk:2] :: ka_auj[sk:2])
Given-eqs = NoGivenEqs
Status = Unsolved
Given =
Wanted =
WC {wc_simple =
[W] hole{co_avp} {1;{{co_ave}}}:: ks_aui[sk:2]
GHC.Prim.~# k1_auh[sk:2] (CNonCanonical)
[W] hole{co_avt} {1;{{co_avp}}}:: ka_auj[sk:2]
GHC.Prim.~# k1_auh[sk:2] (CNonCanonical)}
Binds = CoEvBindsVar<avn>
an explicit forall {k1_auh} {ks_aui} {ka_auj} q_auk
(p_aul :: k1_auh -> q_auk -> Type)
(f_aum :: ka_auj -> q_auk) (s_aun :: ks_aui)
(t_auo :: ks_aui) (a_aup :: ka_auj)
(b_auq :: ka_auj) }}
Binds = CoEvBindsVar<axn>
the type signature for ‘bob’ }}
Binds = CoEvBindsVar<axp>
UnkSkol (please report this as a bug)
Call stack:
CallStack (from HasCallStack):
unkSkolAnon, called at compiler/GHC/Tc/Solver.hs:231:57 in ghc:GHC.Tc.Solver }}
```
## Expected behavior
I expect compilation to either succeed or produce an error message.
## Environment
* GHC version used: 9.4.4
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/22742ghc panic: runtimeRepLevity_maybe2023-01-23T14:30:43ZVladislav Zavialovghc panic: runtimeRepLevity_maybe## Summary
An ill-typed program triggers a panic while printing an error message.
## Steps to reproduce
Compile this:
```haskell
module Bug where
import GHC.Exts (TYPE)
data T (a :: TYPE r) = MkT
f :: T @(f a b) () -> ()
f MkT = (...## Summary
An ill-typed program triggers a panic while printing an error message.
## Steps to reproduce
Compile this:
```haskell
module Bug where
import GHC.Exts (TYPE)
data T (a :: TYPE r) = MkT
f :: T @(f a b) () -> ()
f MkT = ()
```
GHC tries to print an error message (as can be seen from the error code `GHC-83865`) but then panics:
```
Bug.hs:7:17: error: [GHC-83865]ghc: panic! (the 'impossible' happened)
GHC version 9.7.20230110:
runtimeRepLevity_maybe
'BoxedRep
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:796:22 in ghc:GHC.Core.Type
```
## Expected behavior
A proper error message.
## Environment
* GHC version used: HEAD.Rinat Striungislazybonesxp@gmail.comRinat Striungislazybonesxp@gmail.com