GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:10:04Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/2126Misleading error message for newtype with no constructors2019-07-07T19:10:04Zchevalier@alum.wellesley.eduMisleading error message for newtype with no constructorsFurther adventures in error message pedantry! If I compile this module:
```
module Foo where
newtype X
```
I get:
```
$ ghc -c Foo.hs
Foo.hs:3:0:
`X' has no constructors (-XEmptyDataDecls permits this)
In the newtype declara...Further adventures in error message pedantry! If I compile this module:
```
module Foo where
newtype X
```
I get:
```
$ ghc -c Foo.hs
Foo.hs:3:0:
`X' has no constructors (-XEmptyDataDecls permits this)
In the newtype declaration for `X'
```
Naively, I do what it suggests:
```
$ ghc -c Foo.hs -XEmptyDataDecls
Foo.hs:3:0:
A newtype must have exactly one constructor, but `X' has none
In the newtype declaration for `X'
```
It would be better to just print the second error message even when the user doesn't pass `-XEmptyDataDecls`, and not lead them down a maze of twisty little passages...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Misleading error message for newtype with no constructors","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Further adventures in error message pedantry! If I compile this module:\r\n{{{\r\nmodule Foo where\r\n\r\nnewtype X\r\n}}}\r\nI get:\r\n{{{\r\n$ ghc -c Foo.hs\r\n\r\nFoo.hs:3:0:\r\n `X' has no constructors (-XEmptyDataDecls permits this)\r\n In the newtype declaration for `X'\r\n}}}\r\nNaively, I do what it suggests:\r\n{{{\r\n$ ghc -c Foo.hs -XEmptyDataDecls\r\n\r\nFoo.hs:3:0:\r\n A newtype must have exactly one constructor, but `X' has none\r\n In the newtype declaration for `X'\r\n}}}\r\n\r\nIt would be better to just print the second error message even when the user doesn't pass {{{-XEmptyDataDecls}}}, and not lead them down a maze of twisty little passages...","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2114Bad error message for omitting -XExistentialQuantification flag2019-07-07T19:10:08Zchevalier@alum.wellesley.eduBad error message for omitting -XExistentialQuantification flagIf I compile this program:
```
module Foo where
data T = forall a . MkT a
```
with:
```
ghc-6.8.1 extest.hs -c
```
I get the error:
```
extest.hs:3:9: Not a constructor: `forall'
```
I think it would be a better error message to ...If I compile this program:
```
module Foo where
data T = forall a . MkT a
```
with:
```
ghc-6.8.1 extest.hs -c
```
I get the error:
```
extest.hs:3:9: Not a constructor: `forall'
```
I think it would be a better error message to suggest passing in the -XExistentialQuantification flag.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Bad error message for omitting -XExistentialQuantification flag","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If I compile this program:\r\n{{{\r\nmodule Foo where\r\n\r\ndata T = forall a . MkT a\r\n}}}\r\nwith:\r\n{{{\r\nghc-6.8.1 extest.hs -c\r\n}}}\r\n\r\nI get the error:\r\n{{{\r\nextest.hs:3:9: Not a constructor: `forall'\r\n}}}\r\n\r\nI think it would be a better error message to suggest passing in the -XExistentialQuantification flag.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2112Bad error message for malformed GADTs2019-07-07T19:10:08Zchevalier@alum.wellesley.eduBad error message for malformed GADTsCompiling the following code:
```
data Foo a where
Bar :: a -> a
```
results in the following error message:
```
$ ghc-6.8.1 gadt.hs -XGADTs
gadt.hs:5:3:
Malformed constructor result type: a
In the result type of a data co...Compiling the following code:
```
data Foo a where
Bar :: a -> a
```
results in the following error message:
```
$ ghc-6.8.1 gadt.hs -XGADTs
gadt.hs:5:3:
Malformed constructor result type: a
In the result type of a data constructor: a
In the data type declaration for `Foo'
$
```
It would be nice if the error message mentioned the name of the offending data constructor (`Bar` in this case) -- since there might be more than one.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Bad error message for malformed GADTs","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Compiling the following code:\r\n\r\n{{{\r\ndata Foo a where\r\n Bar :: a -> a\r\n}}}\r\n\r\nresults in the following error message:\r\n{{{\r\n$ ghc-6.8.1 gadt.hs -XGADTs\r\n\r\ngadt.hs:5:3:\r\n Malformed constructor result type: a\r\n In the result type of a data constructor: a\r\n In the data type declaration for `Foo'\r\n$ \r\n}}}\r\n\r\nIt would be nice if the error message mentioned the name of the offending data constructor ({{{Bar}}} in this case) -- since there might be more than one.","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2079GHC 6.8.* doesn't recognize type variables2019-07-07T19:10:18Zdaniel.is.fischerGHC 6.8.* doesn't recognize type variablesThe module
```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{- # LANGUAGE FlexibleInstances # -}
module Leandro where
data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf
data ListAssoc a b = Node a b...The module
```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FunctionalDependencies #-}
{- # LANGUAGE FlexibleInstances # -}
module Leandro where
data Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf
data ListAssoc a b = Node a b (ListAssoc a b) | Empty
class Container c a b |c -> a, c -> b where
empty :: c
add :: c -> a -> b -> c
search :: c -> a -> Maybe b
del :: c -> a -> c
toListPair :: c -> [(a,b)]
instance (Ord a) => Container (Abb a b) a b where
empty = Leaf
add Leaf x y = Branch x y Leaf Leaf
add arb@(Branch ni nd ri rd) x y
|x == ni = arb
|x > ni = Branch ni nd ri (add rd x y)
|otherwise = Branch ni nd (add ri x y) rd
search Leaf x = Nothing
search (Branch ni nd ri rd) x
|x == ni = Just nd
|x > ni = search rd x
|x < ni = search ri x
```
triggers the following error in ghci (6.8.1 and 6.8.2):
```
dafis@linux:~/Documents/haskell/move> ghci Leandro
GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
[1 of 1] Compiling Leandro ( Leandro.hs, interpreted )
Leandro.hs:17:0:
Illegal instance declaration for `Container (Abb a b) a b'
(All instance types must be of the form (T a1 ... an)
where a1 ... an are distinct type *variables*
Use -XFlexibleInstances if you want to disable this.)
In the instance declaration for `Container (Abb a b) a b'
Failed, modules loaded: none.
```
To the best of my knowledge, a and b in 'instance Container (Abb a b) a b where' are distinct type variables and neither hugs nor ghci-6.6.1 complain. Converting the third line to a language pragma makes the code acceptable to 6.8.\*.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 6.8.* doesn't recognize type variables","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The module\r\n{{{\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{- # LANGUAGE FlexibleInstances # -}\r\nmodule Leandro where\r\n\r\ndata Abb a b = Branch a b (Abb a b) (Abb a b) | Leaf\r\n\r\ndata ListAssoc a b = Node a b (ListAssoc a b) | Empty\r\n\r\nclass Container c a b |c -> a, c -> b where\r\n empty :: c\r\n add :: c -> a -> b -> c\r\n search :: c -> a -> Maybe b\r\n del :: c -> a -> c\r\n toListPair :: c -> [(a,b)]\r\n\r\ninstance (Ord a) => Container (Abb a b) a b where\r\n empty = Leaf\r\n add Leaf x y = Branch x y Leaf Leaf\r\n add arb@(Branch ni nd ri rd) x y\r\n |x == ni = arb\r\n |x > ni = Branch ni nd ri (add rd x y)\r\n |otherwise = Branch ni nd (add ri x y) rd\r\n search Leaf x = Nothing\r\n search (Branch ni nd ri rd) x\r\n |x == ni = Just nd\r\n |x > ni = search rd x\r\n |x < ni = search ri x\r\n}}}\r\ntriggers the following error in ghci (6.8.1 and 6.8.2):\r\n{{{\r\ndafis@linux:~/Documents/haskell/move> ghci Leandro\r\nGHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling Leandro ( Leandro.hs, interpreted )\r\n\r\nLeandro.hs:17:0:\r\n Illegal instance declaration for `Container (Abb a b) a b'\r\n (All instance types must be of the form (T a1 ... an)\r\n where a1 ... an are distinct type *variables*\r\n Use -XFlexibleInstances if you want to disable this.)\r\n In the instance declaration for `Container (Abb a b) a b'\r\nFailed, modules loaded: none.\r\n}}}\r\nTo the best of my knowledge, a and b in 'instance Container (Abb a b) a b where' are distinct type variables and neither hugs nor ghci-6.6.1 complain. Converting the third line to a language pragma makes the code acceptable to 6.8.*.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.3Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/2004Pattern matching against GADTs without -XGADTs has odd behavior.2019-07-07T19:10:41ZguestPattern matching against GADTs without -XGADTs has odd behavior.I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.
Repro case:
```
{-# LANGUAGE GADTs #-}
module Bug where
data Witness a b c where
Z :: Witness a as (a,as)
P...I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.
Repro case:
```
{-# LANGUAGE GADTs #-}
module Bug where
data Witness a b c where
Z :: Witness a as (a,as)
P :: Witness a as xs -> Witness a (b,as) (b,xs)
data Expr a vars where
Lam :: String -> Expr a (b,vars) -> Expr (b -> a) vars
Ap :: Expr (b -> a) vars -> Expr b vars -> Expr a vars
subst :: Witness a vs vsa -> Expr a vs -> Expr b vsa -> Expr b vs
subst = undefined
subAp :: Expr a vs -> Expr a vs
subAp (Ap (Lam _ e) v) = subst Z v e
```
This compiles fine. But in GHCi:
```
> let { subAp2 :: Expr a vs -> Expr a vs ; subAp2 (Ap (Lam _ e) v) = subst Z v e }
<interactive>:1:79:
Couldn't match expected type `a1' against inferred type `a2'
`a1' is a rigid type variable bound by
the type signature for `subAp2' at <interactive>:1:21
`a2' is a rigid type variable bound by
the constructor `Lam' at <interactive>:1:54
Expected type: Expr a1 (Decl b vs)
Inferred type: Expr a2 (Decl b1 vs)
In the third argument of `subst', namely `e'
In the expression: subst Z v e
```
Interestingly, if I do `:set -XGADTs` followed by that declaration, it works.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Pattern matching against GADTs without -XGADTs has odd behavior.","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I'm getting a weird error message declaring a function in GHCi, but the same function declared in the source file works.\r\n\r\nRepro case:\r\n\r\n{{{\r\n{-# LANGUAGE GADTs #-}\r\nmodule Bug where\r\n\r\ndata Witness a b c where\r\n Z :: Witness a as (a,as)\r\n P :: Witness a as xs -> Witness a (b,as) (b,xs)\r\n\r\ndata Expr a vars where\r\n Lam :: String -> Expr a (b,vars) -> Expr (b -> a) vars\r\n Ap :: Expr (b -> a) vars -> Expr b vars -> Expr a vars\r\n\r\nsubst :: Witness a vs vsa -> Expr a vs -> Expr b vsa -> Expr b vs\r\nsubst = undefined\r\n\r\nsubAp :: Expr a vs -> Expr a vs\r\nsubAp (Ap (Lam _ e) v) = subst Z v e\r\n}}}\r\n\r\nThis compiles fine. But in GHCi:\r\n{{{\r\n> let { subAp2 :: Expr a vs -> Expr a vs ; subAp2 (Ap (Lam _ e) v) = subst Z v e }\r\n\r\n<interactive>:1:79:\r\n Couldn't match expected type `a1' against inferred type `a2'\r\n `a1' is a rigid type variable bound by\r\n the type signature for `subAp2' at <interactive>:1:21\r\n `a2' is a rigid type variable bound by\r\n the constructor `Lam' at <interactive>:1:54\r\n Expected type: Expr a1 (Decl b vs)\r\n Inferred type: Expr a2 (Decl b1 vs)\r\n In the third argument of `subst', namely `e'\r\n In the expression: subst Z v e\r\n}}}\r\n\r\nInterestingly, if I do {{{:set -XGADTs}}} followed by that declaration, it works.","type_of_failure":"OtherFailure","blocking":[]} -->6.10 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1662mistranslation of arrow notation2019-07-07T19:12:20ZRoss Patersonr.paterson@city.ac.ukmistranslation of arrow notation(Split from #1333)
arrowrun004 has a core lint failure for all ways:
```
*** Core Lint Errors: in result of Desugar ***
<no location info>:
In the expression: >>>_aEC @ () @ () @ GHC.Base.Int
>>>_aEC is out of scope
*** Offendi...(Split from #1333)
arrowrun004 has a core lint failure for all ways:
```
*** Core Lint Errors: in result of Desugar ***
<no location info>:
In the expression: >>>_aEC @ () @ () @ GHC.Base.Int
>>>_aEC is out of scope
*** Offending Program ***
[...]
Main.expr :: Main.ExprParser () GHC.Base.Int
[]
Main.expr =
>>>_aEC
@ ()
@ ()
@ GHC.Base.Int
(arr_aEB
[...]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | arrowrun004 |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"mistranslation of arrow notation","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.6.1","keywords":[],"differentials":[],"test_case":"arrowrun004","architecture":"Unknown","cc":[""],"type":"Bug","description":"(Split from #1333)\r\n\r\narrowrun004 has a core lint failure for all ways:\r\n{{{\r\n*** Core Lint Errors: in result of Desugar ***\r\n<no location info>:\r\n In the expression: >>>_aEC @ () @ () @ GHC.Base.Int\r\n >>>_aEC is out of scope\r\n*** Offending Program *** \r\n[...]\r\nMain.expr :: Main.ExprParser () GHC.Base.Int\r\n[]\r\nMain.expr =\r\n >>>_aEC\r\n @ ()\r\n @ ()\r\n @ GHC.Base.Int\r\n (arr_aEB\r\n[...]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/528GHC5.0 restricted bindings broken2019-07-07T19:20:21ZlewieGHC5.0 restricted bindings broken```
How did this compiler get thru its regression tests?
x () = y where y = 1
yields:
N.hs:4:
Could not deduce `Num t' from the context ()
Probable fix:
Add `Num t' to the banding(s) for {y}
arising from the literal `1' a...```
How did this compiler get thru its regression tests?
x () = y where y = 1
yields:
N.hs:4:
Could not deduce `Num t' from the context ()
Probable fix:
Add `Num t' to the banding(s) for {y}
arising from the literal `1' at N.hs:4
in the definition of function `y': 1
After a glance thru TcBinds, I see that in
`generalise', under the `RESTRICTED CASE', it calls
`generalise_help' to do most of the work. However,
`generalise_help' only appears to be designed to handle
the UNrestricted case, judging from the comments.
The good news is that the second implicit param bug is
probably just an instance of this same bug.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | None |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | ResolvedInvalid |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC5.0 restricted bindings broken","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"ResolvedInvalid","owner":{"tag":"OwnedBy","contents":"nobody"},"version":"None","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\nHow did this compiler get thru its regression tests?\n\nx () = y where y = 1\n\nyields:\n\nN.hs:4:\n Could not deduce `Num t' from the context ()\n Probable fix:\n\tAdd `Num t' to the banding(s) for {y}\n arising from the literal `1' at N.hs:4\n in the definition of function `y': 1\n\nAfter a glance thru TcBinds, I see that in\n`generalise', under the `RESTRICTED CASE', it calls\n`generalise_help' to do most of the work. However,\n`generalise_help' only appears to be designed to handle\nthe UNrestricted case, judging from the comments.\n\nThe good news is that the second implicit param bug is\nprobably just an instance of this same bug.\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/24299`tc_infer_hs_type` doesn't add module finalisers2024-03-28T14:05:28ZAndrei Borzenkov`tc_infer_hs_type` doesn't add module finalisers## Summary
I investigated https://gitlab.haskell.org/ghc/ghc/-/issues/23639 and found that `tc_hs_type` calls `addModFinalizersWithLclEnv` on untyped top-level splices, but `tc_infer_hs_type` does not. I found this behavior to be strang...## Summary
I investigated https://gitlab.haskell.org/ghc/ghc/-/issues/23639 and found that `tc_hs_type` calls `addModFinalizersWithLclEnv` on untyped top-level splices, but `tc_infer_hs_type` does not. I found this behavior to be strange and is likely a bug. After some investigation, I came up with a test case that exhibits the problem. Luckily, the fix for this bug should be a one line change.
## Steps to reproduce
```haskell
{-# LANGUAGE TemplateHaskell #-}
module T where
import Language.Haskell.TH.Syntax (addModFinalizer, runIO)
import GHC.Types (Type)
type Proxy :: forall a. a -> Type
data Proxy a = MkProxy
check :: ($(addModFinalizer (runIO (putStrLn "check")) >>
[t| Proxy |]) :: Type -> Type) Int -- There is kind signature, we are in check mode
check = MkProxy
infer :: ($(addModFinalizer (runIO (putStrLn "infer")) >>
[t| Proxy |]) ) Int -- no kind signature, inference mode is enabled
infer = MkProxy
```
Attempt to compile this code will result in the following stdout:
```
$ ghc T.hs -fforce-recomp
[1 of 1] Compiling T ( T.hs, T.o )
check
```
## Expected behavior
```
$ ghc T.hs -fforce-recomp
[1 of 1] Compiling T ( T.hs, T.o )
check
infer
```
## Environment
* GHC version used: masterAndrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/23972GHC-9.4 panics due to failing lookupIdSubst for KnownNat2023-09-19T19:09:46ZLars KuhtzGHC-9.4 panics due to failing lookupIdSubst for KnownNat## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7...## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7, GHC-9.2 and GHC-9.6 are not affected.
## Steps to reproduce
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import Numeric.Natural (Natural)
import GHC.TypeNats (KnownNat, natVal)
import Data.Proxy (Proxy(..))
newtype M (n :: Natural) = M Natural
-- Using a smaller value for `PC` makes the issue go away.
type PC :: Natural
type PC = 0x1_0000_0000_0000_0000
-- remove (or simplifying) one case makes the issue go away.
f :: forall n . KnownNat n => M n -> M n
f (M 0) = M 0
f (M x) = M (natVal @n Proxy + x)
-- removing one invocation of `f` makes the issue go away.
g :: KnownNat n => M n -> M n
g x = f (f x)
-- removing the let binding or one invocation of `g` makes the issue go away.
h :: M PC -> M PC
h x = let a = g (g x) in a
```
Compiling this module with GHC-9.4.7 and `-O1` or `-O2` as follows
```sh
ghc -O1 Bug.hs
```
Results in the output
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) [Source file changed]
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.7:
lookupIdSubst
$dKnownNat_sUW
InScope {wild_X2 z_anJ $krep_aQG $krep_aQH $krep_aQI $krep_aQJ
$krep_aQK h $tc'M $trModule $tcM f g $trModule_sUK $trModule_sUL
$trModule_sUM $trModule_sUN $krep_sUO $tcM_sUP $tcM_sUQ $krep_sUR
$tc'M_sUS $tc'M_sUT $sg_sV3}
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/Subst.hs:260:17 in ghc:GHC.Core.Subst
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
GHC compiles the module.
## Environment
The issue was reproduced with
* GHC-9.4.6 and GHC-9.6.7
* ubuntu/linux (amd64) and macOS (amd64 as well as aarch64).https://gitlab.haskell.org/ghc/ghc/-/issues/23938Core lint failure when building hgeometry-combinatorial with GHC-9.8/HEAD2023-09-19T06:12:24ZTeo CamarasuCore lint failure when building hgeometry-combinatorial with GHC-9.8/HEADOn this head.hackage [job](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1656213), hgeometry-combinatorial is failing with a core lint error:
```
*** Core Lint errors : in result of Simplifier ***
src/Data/Permutation.hs:118:31: war...On this head.hackage [job](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1656213), hgeometry-combinatorial is failing with a core lint error:
```
*** Core Lint errors : in result of Simplifier ***
src/Data/Permutation.hs:118:31: warning:
Role incompatibility: expected nominal, got representational
in (MVector
(Sym (D:R:PrimStateST0[0] <s_a1lDZ>_N)
; (PrimState (ST (Sym (D:R:PrimStateST0[0] <s_a1lDZ>_N)))_N)_N)
<Int>_R)_R
In the RHS of genIndexes :: forall a.
Enum a =>
Int -> [[a]] -> Vector (Int, Int)
In the body of lambda with binder a_a1lCv :: *
In the body of lambda with binder $dEnum_a1lCw :: Enum a_a1lCv
In the body of lambda with binder n_a1lxt :: Int
In the body of lambda with binder os_a1lxu :: [[a_a1lCv]]
In the body of lambda with binder s_a1lDZ :: *
In the body of lambda with binder s1_a8wx :: State# s_a1lDZ
In a case alternative: (True)
In the body of lambda with binder s1_aiPN :: State#
(PrimState (ST s_a1lDZ))
In the body of letrec with binders size_aiQ0 :: Int
In a case alternative: ((#,#) ipv_a1m88 :: State#
(PrimState (ST (PrimState (ST s_a1lDZ)))),
ipv1_a1m89 :: MVector
(PrimState (ST (PrimState (ST s_a1lDZ)))) Int)
In the body of letrec with binders size_X2 :: Int
In a case alternative: ((#,#) ipv2_a1m8c :: State#
(PrimState (ST (PrimState (ST s_a1lDZ)))),
ipv3_a1m8d :: MVector
(PrimState (ST (PrimState (ST s_a1lDZ)))) Int)
In a case alternative: (I# unbx_a8y6 :: Int#)
In a case alternative: (MVector ipv_s1m9R :: Int#,
ipv_s1m9S :: Int#,
ipv_s1m9T :: MutableByteArray# s_a1lDZ)
In a case alternative: (MVector ipv_s1m9V :: Int#,
ipv_s1m9W :: Int#,
ipv_s1m9X :: MutableByteArray# s_a1lDZ)
Substitution: <InScope = {a_a1lCv s_a1lDZ}
IdSubst = []
TvSubst = [a1lCv :-> a_a1lCv, a1lDZ :-> s_a1lDZ]
CvSubst = []>
```
I don't have capacity to reduce this to a standalone reproducer right now, but I thought I'd make a ticket for it.
This is building with GHC-9.8.Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/23761ImplicitParams gives wrong result when used in a constraint tuple on GHC 9.8....2023-08-08T16:57:55ZChristiaan BaaijImplicitParams gives wrong result when used in a constraint tuple on GHC 9.8.1-alpha1## Summary
ImplicitParams returns the wrong result when the IP constraint is part of a constraint tuple.
This failure appeared in GHC 9.8.1-alpha1 and does not seem to be present in earlier versions of GHC.
## Steps to reproduce
The f...## Summary
ImplicitParams returns the wrong result when the IP constraint is part of a constraint tuple.
This failure appeared in GHC 9.8.1-alpha1 and does not seem to be present in earlier versions of GHC.
## Steps to reproduce
The following program returns the wrong result on GHC 9.8.1-alpha1
```haskell
{-# LANGUAGE ImplicitParams #-}
module Main where
type IPInt =
( ?ipInt :: Int
, (Int ~ Int) -- Comment this out and main prints 7 instead of 3
)
hasIPInt ::
IPInt =>
Int
hasIPInt = ?ipInt
addToIPInt
:: forall r
. IPInt
=> Int
-> (IPInt => r)
-> r
addToIPInt = \en f -> addToIPInt0 ?ipInt en f
where
addToIPInt0
:: Int
-> Int
-> (IPInt => r)
-> r
addToIPInt0 gen en f =
let ?ipInt = gen + en
in f
main :: IO ()
main = print (let ?ipInt = 3 in addToIPInt 4 hasIPInt)
```
## Expected behavior
The expected output is `7`, but the program returns `3`.
## Environment
* GHC version used: 9.8.1-alpha1
Optional:
* Operating System: Linux (Ubuntu 22.04.2 LTS)
* System Architecture: x86_649.8.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23408Potential bug/oddity in resolving `Coercible` constraints2023-05-23T17:42:04ZparsonsmattPotential bug/oddity in resolving `Coercible` constraints## Summary
The work codebase uses `persistent` and `esqueleto`, and `esqueleto` defines a bunch of operators that overlap/conflict with the `persistent` ones. This has become enough of an issue that I'm working on creating an abstractio...## Summary
The work codebase uses `persistent` and `esqueleto`, and `esqueleto` defines a bunch of operators that overlap/conflict with the `persistent` ones. This has become enough of an issue that I'm working on creating an abstraction for them.
```haskell
(Persistent.=.) :: (PersistField typ) => EntityField rec typ -> typ -> Update rec
class SqlAssignment lhs rhs result where
(=.) :: lhs -> rhs -> result
instance
( PersistField typ, field ~ EntityField rec' typ', rec ~ rec', typ ~ typ'
) => SqlAssignment field typ (Persistent.Update rec) where
(=.) = (Persistent.=.)
```
While working on this, I ran into an issue where `Coercible` constraints aren't being inferred correctly for instances of a data family. We have several lines like:
```haskell
let fooId = coerce otherId
update fooId [FooName =. "hello"]
```
These lines compile fine with the `=.` from `persistent`, but fail with a "Couldn't match representation of type 'UUID' with that of 'Key Foo'` error.
`update` is a class member, given type:
```haskell
class PersistStoreWrite backend where
update :: forall record m. (MonadIO m, PersistRecordBackend record backend)
=> Key record -> [Update record] -> ReaderT backend m ()
```
So, here's my best guess:
GHC sees `update (coerce barId) [FooCount =. 1]`, which causes it to start Inferring things:
1. `FooCount :: EntityField Foo Int` - this is known.
2. `update :: Key rec -> [Update rec]` - this is known.
3. `FooCount =. 1` turns into a constraint `(Num a, SqlAssignment lhs a result)`.
4. The `update` causes `result` to be known as `Update Foo`, which is sufficient to select the `SqlAssignment lhs rhs (Persistent.Update rec)` instance.
5. This introduces some wanted constraints: `lhs ~ EntityField rec' typ'`, `rhs ~ typ'`, and finally `rec ~ rec'`. Crucially, we introduce these as *type equality constraints*.
6. `lhs ~ EntityField rec' typ'` is fine - we get `EntityField Foo Int`, which propagates to `rhs ~ tyc ~ Int` and `rec' ~ Foo ~ rec`, so we have inferred `Update Foo` as our `result` type.
7. Finally, to `update` - we have a type of `update :: (rec ~ Foo) => Key rec -> [Update rec]`. But our subexpression on the `update` is `coerce barId`.
8. `coerce barId` has a type `Coercible (Key Bar) r => r`. `Coercible` is a magically instantiated class, and something about how the `r ~ Foo` is provided as an instance constraint defeats how the class can be solved out.
## Steps to reproduce
Hey, fortunately a minimal reproducer fits in a single file!
```haskell
{-# language TypeFamilies, TypeApplications, GADTs, FunctionalDependencies, FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-}
module Lib where
import Data.Coerce
import Data.Proxy
update :: Key a -> [Proxy a] -> IO ()
update _ _ = pure ()
data User
data family Key a
newtype instance Key User = UserKey String
(=.) :: p a -> b -> Proxy a
(=.) _ _ = Proxy
class SqlAssignment lhs result where
assignment :: proxy lhs -> rhs -> Proxy result
instance (rec ~ rec') => SqlAssignment rec rec' where
assignment = (=.)
-- wtf
assignmentNoClass :: (rec ~ rec') => proxy rec -> b -> Proxy rec'
assignmentNoClass = assignment
userName :: Proxy User
userName = Proxy
someFunc :: IO ()
someFunc = do
-- works: no class on `=.`
update (coerce "hello") [userName =. "asdf"]
-- works: type annotation on `coerce`
update (coerce "asdf" :: Key User) [userName `assignment` "asdf"]
-- works: somehow adding a top-level non-class-member makes this ok???
update (coerce "asdf") [userName `assignmentNoClass` "asdf"]
-- works: type signature on result of `assignment`
update (coerce "asdf") [userName `assignment` "asdf" :: Proxy User]
-- does not work
update (coerce "asdf") [userName `assignment` "asdf"]
```
The data family appears to be relevant, here - given a `newtype Key a = Key String`, GHC is always able to deduce the `Coercible (Key a) String`. So I think the issue must be related to the data family in particular - just knowing `(a ~ User)` isn't enough to "unlock" that `Coercible (Key User) String` is valid, since that's a `newtype`. But literally any other type hint brings that information into scope.
## Expected behavior
I expect that GHC can solve a `Coercible a b` constraint when `b` is known, even if that knowledge comes about through type equality constraints from instance resolution.
## Environment
* GHC version used: 8.10.7, 9.0.2, 9.2.7, 9.4.5, 9.6.1
Optional:
* Operating System: Ubuntu
* System Architecture: x86https://gitlab.haskell.org/ghc/ghc/-/issues/23371GHC enters endless loop in ghc 9.4 (fixed in ghc >= 9.6)2023-05-16T14:29:27ZMagnus ViernickelGHC enters endless loop in ghc 9.4 (fixed in ghc >= 9.6)## Summary
I was playing around with some constraints stuff and encountered a weird thing where the compiler (apparently) enters an endless loop when trying to add a `Show` instance. This is indeed an erroneous program, but I still don'...## Summary
I was playing around with some constraints stuff and encountered a weird thing where the compiler (apparently) enters an endless loop when trying to add a `Show` instance. This is indeed an erroneous program, but I still don't want the compiler enters an endless loop.
I hope this is no duplicate (didn't quite read through all 1000 issues that contain "loop")
## Steps to reproduce
```haskell
{-# LANGUAGE BlockArguments #-}
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -Wall #-}
module Has where
import Data.Functor.Identity (Identity (Identity))
import Data.Kind (Constraint, Type)
type Has :: forall k. (k -> Constraint) -> (k -> Type) -> k -> Type
data Has c f a where
Proves :: c a => f a -> Has c f a
type Top :: forall k. k -> Constraint
class Top a
instance Top a
class CFunctor c f | f -> c where
cfmap :: c b => (a -> b) -> f a -> (c b => f b -> r) -> r
instance CFunctor c (Has (c :: Type -> Constraint) f) where
cfmap f x k = k $ Proves (cfmap f x \(Proves y) -> y)
newtype Unconstrained f a = MkUnconstrained {getFunctor :: f a}
instance Functor f => CFunctor Top (Unconstrained f) where
cfmap f x k = k $ MkUnconstrained (f <$> getFunctor x)
deriving via (Unconstrained Identity) instance CFunctor Top Identity
-- instance Show (Has c f a) where
-- show = cfmap show
```
comment out the last two lines, ghci should hang
## Expected behavior
The compiler terminates.
## Environment
* GHC version used: 945
Optional:
- system: `"x86_64-linux"`
- host os: `Linux 6.3.1-zen1, NixOS, 23.05 (Stoat), 23.05.20230506.897876e`
## Additional information
- the issue does not occur with 961
- commenting out TypeFamilies causes a warning to be show by the `deriving via` declaration9.4.6sheafsam.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/23156GHC version 9.4.4: heap overflow; the same with 9.6.1, but 9.2.7 compiles fine2023-07-03T09:33:13ZMikolaj KonarskiGHC version 9.4.4: heap overflow; the same with 9.6.1, but 9.2.7 compiles fine## Summary
Heap overflow when compiling, both with -O0 and with -O1.
Edit: Disclaimer: lots of `UndecidableInstances` in this code, though not in the file on which GHC diverges.
## Steps to reproduce
Clone this repo at this commit
h...## Summary
Heap overflow when compiling, both with -O0 and with -O1.
Edit: Disclaimer: lots of `UndecidableInstances` in this code, though not in the file on which GHC diverges.
## Steps to reproduce
Clone this repo at this commit
https://github.com/Mikolaj/horde-ad/commit/773bc01382748b073fddee776b6fd8e6657c35df
then run (you can ignore `cabal.project`, the fork of `mnist-idx` is no longer needed)
`cabal build -j1 --disable-optimization`
Or any other `build` invocation. I haven't found a set of options for which it does compile.
## Expected behavior
Compiles.
## Environment
Fails the same with 9.4.4 and 9.6.1 (with `--allow-newer`). Fails the same in CI:
https://github.com/Mikolaj/horde-ad/actions/runs/4492044812/jobs/7901371200#step:18:629
Compiles and all tests pass with 9.2.7.Simon Peyton JonesSimon Peyton Joneshttps://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/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/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/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 Jones