GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T15:31:18Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24571Pattern to type transformation doesn't work with TH splices.2024-03-26T15:31:18ZAndrei BorzenkovPattern to type transformation doesn't work with TH splices.## Summary
`pat_to_type_pat` doesn't perform transformation for `SplicePat`, so it is not possible to use TH splices to create a pattern for `forall->`
## Steps to reproduce
```
{-# LANGUAGE TemplateHaskell, RequiredTypeArguments #-}
...## Summary
`pat_to_type_pat` doesn't perform transformation for `SplicePat`, so it is not possible to use TH splices to create a pattern for `forall->`
## Steps to reproduce
```
{-# LANGUAGE TemplateHaskell, RequiredTypeArguments #-}
module T where
g :: forall a -> ()
g $([p| a |]) = () -- Ill-formed type pattern: a_a285
```
## Expected behavior
That should compile.
The fix is straightforward, just a couple lines of code with a new equation in `pat_to_type_pat` function.
```diff
diff --git a/compiler/GHC/Tc/Gen/Pat.hs b/compiler/GHC/Tc/Gen/Pat.hs
index 99ffe6561b..eaf263907d 100644
--- a/compiler/GHC/Tc/Gen/Pat.hs
+++ b/compiler/GHC/Tc/Gen/Pat.hs
@@ -534,6 +534,9 @@ pat_to_type_pat (SigPat _ pat sig_ty)
pat_to_type_pat (ParPat _ pat)
= do { HsTP x t <- pat_to_type_pat (unLoc pat)
; return (HsTP x (noLocA (HsParTy noAnn t))) }
+pat_to_type_pat (SplicePat (HsUntypedSpliceTop mod_finalizers pat) splice) = do
+ { HsTP x t <- pat_to_type_pat pat
+ ; return (HsTP x (noLocA (HsSpliceTy (HsUntypedSpliceTop mod_finalizers t) splice))) }
pat_to_type_pat pat =
-- There are other cases to handle (ConPat, ListPat, TuplePat, etc), but these
-- would always be rejected by the unification in `tcHsTyPat`, so it's fine to
```Andrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24566Default types vs deriving2024-03-22T13:39:10ZSylvain HenryDefault types vs deriving## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ ...## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ @since base-2.01
)
-- ???
-- A non-standalone instance will slurp the interface file for GHC.Num.Integer.
-- During simplifyInstanceContexts, a call to GHC.Tc.Utils.Env.tcGetDefaultTys
-- apparently sees mb_defaults = Nothing and thus tries to bring in the
-- default "default" types, including Integer. This seems wrong.
deriving instance Ord a => Ord (Maybe a) -- ^ @since base-2.01
```
Both standalone and non-standalone instance declarations should "see" the same default types (none here because of the `default ()`).
## Steps to reproduce
Reproduce with:
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module M where
import GHC.Classes
default ()
data Foo a = Nothing | Just a
deriving (Eq, Ord)
-- deriving instance Eq a => Eq (Foo a)
-- deriving instance Ord a => Ord (Foo a)
```
Build with:
```
strace -f -e trace=file ghc M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
```
We use `-fno-code` because the bignum interfaces seem to be loaded during codegen.
Result with standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
```
Result with non-standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
[pid 172062] stat("/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", {st_mode=S_IFREG|0644, st_size=47534, ...}) = 0
[pid 172062] openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 13
```
## Expected behavior
Bignum interfaces shouldn't be loaded with non-standalone deriving.
## Environment
* GHC version used: 9.6, 9.8https://gitlab.haskell.org/ghc/ghc/-/issues/24508Do not emit `-Winaccessible-code` warnings when the pattern-match checker wou...2024-03-14T09:09:32ZSebastian GrafDo not emit `-Winaccessible-code` warnings when the pattern-match checker would warn as wellhttps://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https:/...https://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https://gitlab.haskell.org/ghc/ghc/-/issues/19428 I proposed to deprecate `-Winaccessible-code` for this reason, but @RyanGlScott correctly pointed out that there are inaccessible code warnings that have no equivalent in the pattern-match checker.
So in this ticket, I instead propose not to generate `-Winaccessible-code` warnings inside patterns.https://gitlab.haskell.org/ghc/ghc/-/issues/24494A type equality constraint is necessary despite GHC warning that it's redundant2024-03-05T17:42:19ZMikolaj KonarskiA type equality constraint is necessary despite GHC warning that it's redundant## Summary
The first [type equality](https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f/src/HordeAd/Core/Engine.hs#L308) in this type signature
```hs
cfwd
:: forall r y f vals advals.
( RankedOf f ...## Summary
The first [type equality](https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f/src/HordeAd/Core/Engine.hs#L308) in this type signature
```hs
cfwd
:: forall r y f vals advals.
( RankedOf f ~ Flip OR.Array
, AdaptableHVector (ADVal (Flip OR.Array)) advals
, AdaptableHVector (ADVal (Flip OR.Array)) (ADVal f r y)
, AdaptableHVector (Flip OR.Array) vals
, AdaptableHVector (Flip OR.Array) (f r y)
, DualNumberValue advals, vals ~ DValue advals )
=> (advals -> ADVal f r y) -> vals -> vals -> f r y
```
is reported as redundant by GHC 9.8.1 (with both -O0 and -O1, with GHC 9.6.4 only with -O1) but the typing fails with the equality removed with
```
test/simplified/TestAdaptorSimplified.hs:1629:22: error: [GHC-40404]
• Reduction stack overflow; size = 201
When simplifying the following type:
Show
(HordeAd.Core.Delta.DeltaS
(ShapedOf
@GHC.TypeNats.Nat
(RankedOf
@[GHC.TypeNats.Nat]
(ShapedOf
@GHC.TypeNats.Nat
(RankedOf
@[GHC.TypeNats.Nat]
(ShapedOf
```
etc.
## Steps to reproduce
Checkout https://github.com/Mikolaj/horde-ad/blob/b42aeabc0cb9fdbc8933ddd444143d008a5b986f.
Run with GHC 9.8.1 or later (probably):
```
cabal test simplifiedOnlyTest -ftest_seq --test-options='-p 4Sin' --allow-newer --disable-optimization
```
After a dozen files tt should warn the equality is redundant and after another dozen it should start running the tests (all run fine). Remove the equality, run again, a few files later the error from above should pop up.
## Expected behavior
I have no idea if the type equality is really needed (or maybe a much weaker equality would be enough, e.g., `RankedOf (ShapedOf ranked) ~ ranked`?). I expect GHC to tell what it is so that I don't have to think.
## Environment
* GHC version used: 9.8.1 and 9.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/24460Strange typechecking errors to do with Generics in a module with ANN and a ty...2024-02-27T15:12:18ZTeo CamarasuStrange typechecking errors to do with Generics in a module with ANN and a type error## Summary
This is a reproducer extracted from something we encountered in the wild.
Adding a new field to datatype led to a bunch of strange errors about `Generic`s.
In this minimal reproducer, the generics error is quite small, but i...## Summary
This is a reproducer extracted from something we encountered in the wild.
Adding a new field to datatype led to a bunch of strange errors about `Generic`s.
In this minimal reproducer, the generics error is quite small, but it becomes huge in any non-trivial example.
## Steps to reproduce
Compile the following module:
```
{-# LANGUAGE DeriveAnyClass #-}
module Repro where
import GHC.Generics
data IHaveNoFields = IHaveNoFields { } deriving (Generic)
getField
(IHaveNoFields field1 )
= field1
{-# ANN iHaveAnn ("" :: String) #-}
iHaveAnn = undefined
```
Here is the output:
```
Repro.hs:5:50: error:
• Couldn't match type: Rep IHaveNoFields
with: M1 i0 c0 (M1 i1 c1 U1)
Expected: Rep IHaveNoFields x
Actual: M1 i0 c0 (M1 i1 c1 U1) x
• In the expression: M1 (case x of IHaveNoFields -> M1 U1)
In an equation for ‘from’:
from x = M1 (case x of IHaveNoFields -> M1 U1)
When typechecking the code for ‘from’
in a derived instance for ‘Generic IHaveNoFields’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘Generic IHaveNoFields’
|
5 | data IHaveNoFields = IHaveNoFields { } deriving (Generic)
| ^^^^^^^
Repro.hs:5:50: error:
• Couldn't match type: Rep IHaveNoFields
with: M1 i2 c2 (M1 i3 c3 U1)
Expected: Rep IHaveNoFields x
Actual: M1 i2 c2 (M1 i3 c3 U1) x
• In the pattern: M1 x
In an equation for ‘to’:
to (M1 x) = case x of (M1 U1) -> IHaveNoFields
When typechecking the code for ‘to’
in a derived instance for ‘Generic IHaveNoFields’:
To see the code I am typechecking, use -ddump-deriv
In the instance declaration for ‘Generic IHaveNoFields’
|
5 | data IHaveNoFields = IHaveNoFields { } deriving (Generic)
| ^^^^^^^
Repro.hs:8:4: error:
• The constructor ‘IHaveNoFields’ should have no arguments, but has been given 1
• In the pattern: IHaveNoFields field1
In an equation for ‘getField’:
getField (IHaveNoFields field1) = field1
|
8 | (IHaveNoFields field1 )
|
```
## Expected behavior
This should error but should only output:
And indeed this is what we get if we comment out the `ANN` line.
```
Repro.hs:8:4: error:
• The constructor ‘IHaveNoFields’ should have no arguments, but has been given 1
• In the pattern: IHaveNoFields field1
In an equation for ‘getField’:
getField (IHaveNoFields field1) = field1
|
8 | (IHaveNoFields field1 )
| ^^^^^^^^^^^^^^^^^^^^
```
## Environment
* GHC version used: 9.4.8, 9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/24425PartialTypeSignatures regression in 9.82024-03-11T09:00:53ZMatthías Páll GissurarsonPartialTypeSignatures regression in 9.8## Summary
There seems to be a regression in `-XPartialTypeSignatures`,
with GHC asking me to add a constraint to the context of an *inferred* type,
where as previously this constraint would have been inferred as well.
## Steps to repr...## Summary
There seems to be a regression in `-XPartialTypeSignatures`,
with GHC asking me to add a constraint to the context of an *inferred* type,
where as previously this constraint would have been inferred as well.
## Steps to reproduce
This compiles and runs fine in 9.6.3:
```
{-# LANGUAGE PartialTypeSignatures #-}
module Main where
checkFunc :: _ -> Bool
checkFunc f = f == 3
main :: IO ()
main = print (checkFunc 3)
```
```
$ ghc test.hs && ./test
[1 of 2] Compiling Main ( test.hs, test.o ) [Source file changed]
test.hs:4:14: warning: [GHC-88464] [-Wpartial-type-signatures]
• Found type wildcard ‘_’ standing for ‘Integer’
• In the type signature: checkFunc :: _ -> Bool
|
4 | checkFunc :: _ -> Bool
| ^
[2 of 2] Linking test [Objects changed]
$ ./test
True
```
but when compiled with 9.8.1:
```
$ ghc test.hs && ./test
[1 of 2] Compiling Main ( test.hs, test.o )
test.hs:5:17: error: [GHC-39999]
• No instance for ‘Eq a’ arising from a use of ‘==’
Possible fix:
add (Eq a) to the context of
the inferred type of checkFunc :: a -> Bool
• In the expression: f == 3
In an equation for ‘checkFunc’: checkFunc f = f == 3
|
5 | checkFunc f = f == 3
| ^^
test.hs:5:20: error: [GHC-39999]
• No instance for ‘Num a’ arising from the literal ‘3’
Possible fix:
add (Num a) to the context of
the inferred type of checkFunc :: a -> Bool
• In the second argument of ‘(==)’, namely ‘3’
In the expression: f == 3
In an equation for ‘checkFunc’: checkFunc f = f == 3
|
5 | checkFunc f = f == 3
|
```
## Expected behavior
I would expect it to compile as it did in 9.6.
## Environment
* GHC version used: 9.6.3, 9.8.1
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: WSL2https://gitlab.haskell.org/ghc/ghc/-/issues/24411mdo should use HsExpansion Route2024-02-08T11:43:17ZApoorv Inglemdo should use HsExpansion Route## Summary
mdo (recursive do statements) should follow the same flow of vanilla do statements and not depend on `tcSyntaxOp`
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes, RecursiveDo #-}
type Id = forall a. a -> ...## Summary
mdo (recursive do statements) should follow the same flow of vanilla do statements and not depend on `tcSyntaxOp`
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes, RecursiveDo #-}
type Id = forall a. a -> a
t :: IO (forall a. a -> a)
t = return id
p :: (forall a. a -> a) -> (Bool, Int)
p f = (f True, f 3)
-- This does *not* type check:
foo2 = mdo { x <- t ; return (p x) }
```
Fails with:
```
testsuite/tests/typecheck/should_run/T18324.hs:13:19: error: [GHC-91028]
• Couldn't match type ‘a0’ with ‘Id’
Expected: IO a0
Actual: IO Id
Cannot instantiate unification variable ‘a0’
with a type involving polytypes: Id
• In a stmt of an 'mdo' block: x <- t
In the expression:
mdo x <- t
return (p x)
In an equation for ‘foo2’:
foo2
= mdo x <- t
return (p x)
|
13 | foo2 = mdo { x <- t ; return (p x) }
| ^
testsuite/tests/typecheck/should_run/T18324.hs:13:33: error: [GHC-46956]
• Couldn't match expected type ‘a -> a’ with actual type ‘a0’
because type variable ‘a’ would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context:
Id
at testsuite/tests/typecheck/should_run/T18324.hs:13:33
• In the first argument of ‘p’, namely ‘x’
In the first argument of ‘return’, namely ‘(p x)’
In a stmt of an 'mdo' block: return (p x)
• Relevant bindings include
x :: a0
(bound at testsuite/tests/typecheck/should_run/T18324.hs:13:14)
|
13 | foo2 = mdo { x <- t ; return (p x) }
```
## Expected behavior
Should typecheck and run without errors
## Environment
* GHC version used: 9.6.4Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24405polymorphic instantiation of universally quantified types in type constructor...2024-02-07T12:25:02ZArtin Ghasivandghasivand.artin@gmail.compolymorphic instantiation of universally quantified types in type constructors gets accepted depending on the order of argumentsAssume we have the following definition:
```haskell
{-# LANGUAGE ImpredicativeTypes, GADTSyntax #-}
data T2 a b where
K2 :: a -> T2 a a
-- accepted
h1 :: T2 (forall c. c -> c) b -> (Char, Bool)
h1 (K2 x) = (x 'z', x True)
-- reject...Assume we have the following definition:
```haskell
{-# LANGUAGE ImpredicativeTypes, GADTSyntax #-}
data T2 a b where
K2 :: a -> T2 a a
-- accepted
h1 :: T2 (forall c. c -> c) b -> (Char, Bool)
h1 (K2 x) = (x 'z', x True)
-- rejected
h2 :: T2 b (forall c. c -> c) -> (Char, Bool)
h2 (K2 x) = (x 'z', x True)
```
`h2` gets rejected, while `h1` doesn't; when in fact, both of them should be rejected!
@simonpj @raehttps://gitlab.haskell.org/ghc/ghc/-/issues/24335Several bugs with forall (cv::t1~#t2). ty)2024-02-05T17:53:15ZSimon Peyton JonesSeveral bugs with forall (cv::t1~#t2). ty)In principle, GHC supports *coercion variable* in a forall-type. Thus a type can look like `forall (cv:t1~#t2). body_ty`, where `body_ty` can mention the coercion variable `cv`.
See `Note [Why ForAllTy can quantify over a coercion varia...In principle, GHC supports *coercion variable* in a forall-type. Thus a type can look like `forall (cv:t1~#t2). body_ty`, where `body_ty` can mention the coercion variable `cv`.
See `Note [Why ForAllTy can quantify over a coercion variable]` in GHC.Core.TyCo.Rep.
But I discover that GHC has multiple bugs if you actually have any terms with such a type. Here are the four bugs I have found
* `typeKind ty` simply loops if given a type that quantifies over a coercion variable. (It's a trivial bug, easily fixed, but longstanding.)
* Core Lint (specifically `lintCoArg`) complains if it sees an application `(f co)` where `f` has type `(forall (cv:t1~#t2). blah)`. (More usually `f` has type `(t1~#t2)=>blah`, when `blah` does not mention `cv`.)
* `GHC.Core.Opt.Arity.typeArity`/typeOneShots didn't count coercion arguments
if the type was (forall cv. blah)
* `GHC.Core.Opt.Simplify.Iteration.simpl_lam` (which deals with bete-reduction) crashed
when the function type looks like `(forall cv. blah)` and the application has a coercion argument.
I discovered this when working on !11492 which fixes #3781. When compiling `base:Data/Typeable/Internal.hs` the float-out pass yielded this function:
```
lvl_sjWn
:: forall (r :: RuntimeRep) k1 (co['Many] :: k1 ~# TYPE r)
(b :: k1) (r :: RuntimeRep) k2 k1 (a :: k1 -> k2).
(a ~# (->) (b |> co), (k1 -> k2) ~# (TYPE r -> *)) =>
TypeRep ((->) (b |> co)) -> TypeRep a -> Void
[LclId, Arity=5, Str=<L><L><L><L><L>b, Cpr=b]
lvl_sjWn
= \ (@(r_a2ru :: RuntimeRep))
(@k1_a2qV)
(co_a2rv :: k1_a2qV ~# TYPE r_a2ru)
(@(b_a2qX :: k1_a2qV))
(@(r_a2rJ :: RuntimeRep))
(@k2_a2qQ)
(@k1_a2qP)
(@(a_a2qR :: k1_a2qP -> k2_a2qQ))
(co_a2gm :: a_a2qR ~# (->) (b_a2qX |> co_a2rv))
(co_a2gl :: (k1_a2qP -> k2_a2qQ) ~# (TYPE r_a2rJ -> *))
(a_sjPk :: TypeRep ((->) (b_a2qX |> co_a2rv)))
(rep_a1ka :: TypeRep a_a2qR) ->
raise#
@'Lifted
@LiftedRep
@SomeException
@Void
(noinline
@([Char] -> SomeException)
errorCallException
(augment
@Char
lvl_sjWi
(augment
@Char
(\ (@b_ajEq)
(c_ajEr [OS=OneShot] :: Char -> b_ajEq -> b_ajEq)
(n_ajEs [OS=OneShot] :: b_ajEq) ->
foldr
@Char
@b_ajEq
c_ajEr
n_ajEs
(showTypeable
@(TYPE r_a2rJ -> *)
@((->) (b_a2qX |> co_a2rv))
lvl_sjWj
a_sjPk
([] @Char)))
(augment
@Char
lvl_sjWl
(showTypeable
@(TYPE r_a2rJ -> *)
@((->) (b_a2qX |> co_a2rv))
lvl_sjWm
(rep_a1ka
`cast` ((TypeRep co_a2gl co_a2gm)_R
:: TypeRep a_a2qR ~R# TypeRep ((->) (b_a2qX |> co_a2rv))))
([] @Char))))))
```
Somehow this has never happened before!https://gitlab.haskell.org/ghc/ghc/-/issues/24333Unexpected variable untouchable inside constraint since GHC 9.82024-01-16T15:36:46ZShea Levyshea@shealevy.comUnexpected variable untouchable inside constraint since GHC 9.8## Summary
With GHC 9.2.4 and GHC 9.6.2, this compiles:
```haskell
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE QuantifiedConstraints #-}
module Main where
import Data.Coerce
satisfyConstraint :: (forall x y. Coercible x y => Coercible (m x...## Summary
With GHC 9.2.4 and GHC 9.6.2, this compiles:
```haskell
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE QuantifiedConstraints #-}
module Main where
import Data.Coerce
satisfyConstraint :: (forall x y. Coercible x y => Coercible (m x) (m y)) => ((forall x y. Coercible x y => Coercible (m x) (m y)) => m a) -> m a
satisfyConstraint go = go
main :: IO ()
main = do
satisfyConstraint $ pure ()
pure ()
```
However, with 9.8.1, I get:
```
Test.hs:12:28: error: [GHC-83865]
• Couldn't match expected type ‘a0’ with actual type ‘()’
‘a0’ is untouchable
inside the constraints: forall x y.
Coercible x y =>
Coercible (IO x) (IO y)
bound by a type expected by the context:
(forall x y. Coercible x y => Coercible (IO x) (IO y)) => IO a0
at Test.hs:12:23-29
• In the first argument of ‘pure’, namely ‘()’
In the second argument of ‘($)’, namely ‘pure ()’
In a stmt of a 'do' block: satisfyConstraint $ pure ()
|
12 | satisfyConstraint $ pure ()
| ^^
```
## Environment
* GHC version used: 9.2.4, 9.6.2, 9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/24323Non-standalone deriving clause does not pick up superclass quantified coercib...2024-01-16T15:13:54ZShea Levyshea@shealevy.comNon-standalone deriving clause does not pick up superclass quantified coercible constraint## Summary
I have a case where a standalone deriving via typechecks but the non-standalone equivalent does not due to unknown roles, despite the derived class constraining the roles appropriately:
```haskell
{-# LANGUAGE DerivingVia #-...## Summary
I have a case where a standalone deriving via typechecks but the non-standalone equivalent does not due to unknown roles, despite the derived class constraining the roles appropriately:
```haskell
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE QuantifiedConstraints #-}
module Test where
import Control.Exception
import Data.Coerce
import Control.Monad.Trans.Reader
class (Monad m, forall x y. Coercible x y => Coercible (m x) (m y)) => MonadWith m where
stateThreadingGeneralWith
:: GeneralAllocate m SomeException releaseReturn b a
-> (a -> m b)
-> m (b, releaseReturn)
{-
newtype FooT m a = FooT (ReaderT Int m a) deriving newtype (Functor, Applicative, Monad) deriving MonadWith via ReaderT Int m
Test.hs:46:99: error:
• Couldn't match representation of type: m (GeneralAllocated
(ReaderT Int m) SomeException releaseReturn b a)
with that of: m (GeneralAllocated
(FooT m) SomeException releaseReturn b a)
arising from the coercion of the method ‘stateThreadingGeneralWith’
from type ‘forall releaseReturn b a.
GeneralAllocate (ReaderT Int m) SomeException releaseReturn b a
-> (a -> ReaderT Int m b) -> ReaderT Int m (b, releaseReturn)’
to type ‘forall releaseReturn b a.
GeneralAllocate (FooT m) SomeException releaseReturn b a
-> (a -> FooT m b) -> FooT m (b, releaseReturn)’
NB: We cannot know what roles the parameters to ‘m’ have;
we must assume that the role is nominal
• When deriving the instance for (MonadWith (FooT m))
|
46 | newtype FooT m a = FooT (ReaderT Int m a) deriving newtype (Functor, Applicative, Monad) deriving MonadWith via ReaderT Int m
| ^^^^^^^^^
Same issue with:
newtype FooT m a = FooT (ReaderT Int m a) deriving newtype (Functor, Applicative, Monad, MonadWith)
-}
newtype FooT m a = FooT (ReaderT Int m a) deriving newtype (Functor, Applicative, Monad)
deriving via ReaderT Int m instance (MonadWith m) => MonadWith (FooT m)
newtype GeneralAllocate m e releaseReturn releaseArg a
= GeneralAllocate ((forall x. m x -> m x) -> m (GeneralAllocated m e releaseReturn releaseArg a))
data GeneralAllocated m e releaseReturn releaseArg a = GeneralAllocated
{ allocatedResource :: !a
, releaseAllocated :: !(Either e releaseArg -> m releaseReturn)
}
instance (MonadWith m) => MonadWith (ReaderT r m) where
stateThreadingGeneralWith
:: forall a b releaseReturn
. GeneralAllocate (ReaderT r m) SomeException releaseReturn b a
-> (a -> ReaderT r m b)
-> ReaderT r m (b, releaseReturn)
stateThreadingGeneralWith (GeneralAllocate allocA) go = ReaderT $ \r -> do
let
allocA' :: (forall x. m x -> m x) -> m (GeneralAllocated m SomeException releaseReturn b a)
allocA' restore = do
let
restore' :: forall x. ReaderT r m x -> ReaderT r m x
restore' mx = ReaderT $ restore . runReaderT mx
GeneralAllocated a releaseA <- runReaderT (allocA restore') r
let
releaseA' relTy = runReaderT (releaseA relTy) r
pure $ GeneralAllocated a releaseA'
stateThreadingGeneralWith (GeneralAllocate allocA') (flip runReaderT r . go)
```
## Expected behavior
Both of these should behave the same, and should both work. I think this should also work with `deriving newtype` instead of having to specify the `via` type.
## Environment
* GHC version used: 9.2.4, 9.8.1https://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/24279Make Constraint and Type apart, in Core2024-02-05T17:53:13ZOleg GrenrusMake Constraint and Type apart, in CoreI'm running into issues related to this and https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0032-constraint-vs-type.rst doesn't do it for me fully.
TL;DR My use case is kind of implementing something like `TypeRep`,...I'm running into issues related to this and https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0032-constraint-vs-type.rst doesn't do it for me fully.
TL;DR My use case is kind of implementing something like `TypeRep`, and I need to be able to tell `Type` and `Constraint` apart. I can now, because `CONSTRAINT` and `TYPE` are apart, but could not in GHC-9.4. I consider this to be lucky coincidence, but also wrong. `TYPE` and `CONSTRAINT` are apart, but `TYPE LiftedRep` and `CONSTRAINT LiftedRep` are not.
```
{-# LANGUAGE GHC2021, DataKinds, TypeFamilies #-}
import GHC.Exts
type family Equals a b where
Equals a a = True
Equals a b = False
type Ex1 = Equals TYPE CONSTRAINT
type Ex2 = Equals (TYPE LiftedRep) (CONSTRAINT LiftedRep)
{-
This is not right:
*Main> :kind! Ex1
Ex1 :: Bool
= False
*Main> :kind! Ex2
Ex2 :: Bool
= Equals (*) Constraint
-}
```
---
I think that `Type` and `Constraint` should be nominally distinct in Core, but could have the same representation, i.e. using casts to make types align, but make the abstraction zero cost.https://gitlab.haskell.org/ghc/ghc/-/issues/24260Coercion application broken by newtype constructor2023-12-19T15:18:57ZmniipCoercion application broken by newtype constructor## Summary
In core-spec there's an inference rule for applying a coercion to an argument (Co_AppCo) that amounts to the following haskell type:
```hs
coAppCo :: Coercion f g -> x :~: y -> Coercion (f x) (g y)
```
and indeed the type-c...## Summary
In core-spec there's an inference rule for applying a coercion to an argument (Co_AppCo) that amounts to the following haskell type:
```hs
coAppCo :: Coercion f g -> x :~: y -> Coercion (f x) (g y)
```
and indeed the type-checker is able to use this rule since the following implementation type-checks:
```hs
coAppCo Coercion Refl = Coercion
```
However, if we specialize the type signature by substituting `f` and `g` with uses of a newtype type constructor whose data constructor is not in scope, the implementation fails.
```hs
import Control.Monad.ST (ST)
coAppCo' :: Coercion (ST s) (ST s') -> x :~: y -> Coercion (ST s x) (ST s' y)
coAppCo' Coercion Refl = Coercion
<interactive>:12:26: error: [GHC-18872]
• Couldn't match representation of type: ST s x
with that of: ST s' x
arising from a use of ‘Coercion’
The data constructor ‘GHC.ST.ST’ of newtype ‘ST’ is not in scope
• In the expression: Coercion
In an equation for ‘coAppCo'’: coAppCo' Coercion Refl = Coercion
• Relevant bindings include
coAppCo' :: Coercion (ST s) (ST s')
-> (x :~: y) -> Coercion (ST s x) (ST s' y)
(bound at <interactive>:12:1)
```
Note that an implementation that simply delegates to the more general version (`coAppCo' = coAppCo`) type-checks just fine. Likewise if instead of `ST` I use something that is not a newtype, it also type-checks just fine.
## Steps to reproduce
```hs
import Control.Monad.ST (ST)
import Data.Type.Coercion
import Data.Type.Equality
coAppCo' :: Coercion (ST s) (ST s') -> x :~: y -> Coercion (ST s x) (ST s' y)
coAppCo' Coercion Refl = Coercion
```
## Expected behavior
`coAppCo'` should type-check
## Environment
* GHC version used: 9.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/24257Implicit param allowed, but doesn't work.2023-12-19T15:53:25ZOleg GrenrusImplicit param allowed, but doesn't work.ImplicitParams are awkward, I think it's awkward that they are `Constraint`s.
They are not allowed as superclasses (makes sense, but then not really):
```haskell
Prelude> :set -XConstraintKinds -XUndecidableSuperClasses -XImplicitParam...ImplicitParams are awkward, I think it's awkward that they are `Constraint`s.
They are not allowed as superclasses (makes sense, but then not really):
```haskell
Prelude> :set -XConstraintKinds -XUndecidableSuperClasses -XImplicitParams -XAllowAmbiguousTypes
Prelude> class (?foo :: Int) => Foo a where
<interactive>:22:1: error:
• Illegal implicit parameter ‘?foo::Int’
• In the context: ?foo::Int
While checking the super-classes of class ‘Foo’
In the class declaration for ‘Foo’
```
However, one can "work-around" that, by tricking GHC, making syntactic `?foo` not so obvious to the compiler:
```haskell
Prelude> class c => Id c where
Prelude> class (c, c ~ (?foo :: Int)) => Id c where bar :: Int; bar = ?foo
```
That is accepted.
But (not so obviously) it doesn't work:
```haskell
Prelude> let ?foo = 42 :: Int in bar @(?foo :: Int)
<interactive>:9:25: error: [GHC-39999]
• Could not deduce ‘Id (?foo::Int)’ arising from a use of ‘bar’
from the context: ?foo::Int
bound by the implicit-parameter binding for ?foo
at <interactive>:9:1-42
• In the expression: bar @(?foo :: Int)
In the expression: let ?foo = 42 :: Int in bar @(?foo :: Int)
In an equation for ‘it’:
it = let ?foo = 42 :: Int in bar @(?foo :: Int)
```
I feel that GHC should error earlier. It's the `Id`s class (or rather `bar`) definition which is wrong already.https://gitlab.haskell.org/ghc/ghc/-/issues/24201Tidy up Do Expansion implimentation/Kill `GHC.Types.Basic.Origin`2024-02-15T15:32:43ZApoorv IngleTidy up Do Expansion implimentation/Kill `GHC.Types.Basic.Origin`This ticket tracks various tidying up tasks for HsExpansion
Here are some ideas:
1. Get rid `Origin` to beautify and stream line the `Generated` code vs `FromSource` Code meta-data.
See discussion here: https://gitlab.haskell.org/ghc/gh...This ticket tracks various tidying up tasks for HsExpansion
Here are some ideas:
1. Get rid `Origin` to beautify and stream line the `Generated` code vs `FromSource` Code meta-data.
See discussion here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10140#note_535779
The current design depends on `GHC.Types.Basic.Origin` and also `GHC.Types.SrcLoc.GenLocated` to figure out whether a source code's origin is user written or not.
The objective is that we should only be using one thing to identify the source codes origin. The current `tcExpr` already uses `GHC.Types.SrcLoc.GenLocated` to identify the src origin using `isGeneratedCode :: TcRn Bool` and we would be able to reuse that functionality rather than depending on `GHC.Types.Basic.Origin`.
2. Kill `GenReason` in `GHC.Types.Basic.Origin` and clean up smelly code like this one in [GHC.HstoCore.Match.matchWrapper](https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/HsToCore/Match.hs#L773)
```haskell
= do { dflags <- getDynFlags
; locn <- getSrcSpanDs
; let matches
= if any (is_pat_syn_match origin) matches'
then filter (non_gen_wc origin) matches'
-- filter out the wild pattern fail alternatives
-- which have a do expansion origin
-- They generate spurious overlapping warnings
-- Due to pattern synonyms treated as refutable patterns
-- See Part 1's Wrinkle 1 in Note [Expanding HsDo with XXExprGhcRn] in GHC.Tc.Gen.Do
```Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24176Panic with QuantifiedConstraints + RequiredTypeArguments2023-12-04T16:47:17ZKrzysztof GogolewskiPanic with QuantifiedConstraints + RequiredTypeArgumentsThis code causes a panic in master:
```haskell
{-# LANGUAGE QuantifiedConstraints, RequiredTypeArguments #-}
module T where
f :: (forall a -> Eq a) => a
f = f
```
```
<no location info>: error:
panic! (the 'impossible' happened)
...This code causes a panic in master:
```haskell
{-# LANGUAGE QuantifiedConstraints, RequiredTypeArguments #-}
module T where
f :: (forall a -> Eq a) => a
f = f
```
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.9.20231110:
instDFunTypes
df_aIu
[Just a_aIB[sk:2]]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:186:37 in ghc-9.9-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Tc/Utils/Instantiate.hs:371:16 in ghc-9.9-inplace:GHC.Tc.Utils.Instantiate
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:511:29 in ghc-9.9-inplace:GHC.Utils.Error
```
I think we should enforce that `forall a -> ...` is always used with `TYPE rep`. For `forall a. ...`, the body can also be a constraint; the situation is more complicated and covered by #22063. Finally, we accept `forall {a}. Eq a` which seems to give the same result as `forall a. Eq a`, presumably we should reject it.Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/24069GHCi 9.8 includes solved class contraints when printing `:type`2023-10-12T16:23:37ZZubinGHCi 9.8 includes solved class contraints when printing `:type`
```haskell
-- 9.6
λ> :type show @Int
show @Int :: Int -> String
-- 9.8
λ> :type show @Int
show @Int :: Show Int => Int -> String
```
```haskell
-- 9.6
λ> :type show @Int
show @Int :: Int -> String
-- 9.8
λ> :type show @Int
show @Int :: Show Int => Int -> String
```ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24065panic: Given constraint without given origin2023-10-10T14:18:53ZRodrigo Mesquitapanic: Given constraint without given origin## Summary
During compilation of a backpack heavy library I get the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.2:
Given constraint without given origin
$dApplicative_aafq
...## Summary
During compilation of a backpack heavy library I get the following error:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.2:
Given constraint without given origin
$dApplicative_aafq
arising when attempting to show that
instance [safe] Applicative m => Applicative (CommandM m)
-- Defined in ‘Ghengin.Vulkan.Renderer.Command’
is provided by ‘Ghengin.Vulkan.Renderer.Command’
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/Solver/Canonical.hs:600:31 in ghc:GHC.Tc.Solver.Canonical
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
```
Unfortunately, my reproducer is *far* from minimal.
It's reproducible by cloning at a particular commit a considerably large project...
Nonetheless, I figured I should report it.
## Steps to reproduce
```
git clone https://github.com/alt-romes/ghengin.git && cd ghengin
git checkout 2e007f0c9bf88018db424d11c96b2de9b0b4d14a
cabal build ghengin-core
```
## Environment
* GHC version used: 9.6.2
Optional:
* Operating System: macOS
* System Architecture: M2 / Aarch64https://gitlab.haskell.org/ghc/ghc/-/issues/24064GHC panic with a code with type equality constraints with doubly applied type...2023-10-20T19:29:20ZIan-Woo KimGHC panic with a code with type equality constraints with doubly applied type family## Summary
With the following code which should not pass type checking, GHC panic at PostTc phase when doing `lookupIdSubst`.
The code has type equality of form F1 (F2 x) ~ F3 y, and I think that's where the bug is triggered, but the pa...## Summary
With the following code which should not pass type checking, GHC panic at PostTc phase when doing `lookupIdSubst`.
The code has type equality of form F1 (F2 x) ~ F3 y, and I think that's where the bug is triggered, but the panic happens only when combined with other statements in do-notation. (otherwise, usual type error happened, so this is my best minimization up to now).
## Steps to reproduce
```
{-# LANGUAGE Haskell2010 #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Main where
class C1 b where
type F1 b
class C2 (m :: * -> *) where
type F2 m
class C3 r where
type F3 r
class G t m where
g :: m a -> t m a
data Y
data X e a
data H a
data S a
fun1 :: X e ()
fun1 = undefined
fun2 :: S ()
fun2 = undefined
fun3 :: H ()
fun3 = undefined
fun4 :: (F3 r ~ F1 (F2 m)) => r -> m ()
fun4 = undefined
test :: (C2 m, F2 m ~ Y) => m ()
test = do
fun1
fun2
g fun3
fun4 undefined
main :: IO ()
main = pure ()
```
when running GHC, one will see the following panic error.
```
$ ghc Panic.hs
[1 of 2] Compiling Main ( Panic.hs, Panic.o )
Panic.hs:11:16: warning: [GHC-39567] [-Wstar-is-type]
Using ‘*’ (or its Unicode variant) to mean ‘Data.Kind.Type’
relies on the StarIsType extension, which will become
deprecated in the future.
Suggested fix: Use ‘Type’ from ‘Data.Kind’ instead.
|
11 | class C2 (m :: * -> *) where
| ^
Panic.hs:11:21: warning: [GHC-39567] [-Wstar-is-type]
Using ‘*’ (or its Unicode variant) to mean ‘Data.Kind.Type’
relies on the StarIsType extension, which will become
deprecated in the future.
Suggested fix: Use ‘Type’ from ‘Data.Kind’ instead.
|
11 | class C2 (m :: * -> *) where
| ^
Panic.hs:37:15: warning: [GHC-58520] [-Wtype-equality-requires-operators]
The use of ‘~’ without TypeOperators
will become an error in a future GHC release.
Suggested fix: Perhaps you intended to use TypeOperators
|
37 | fun4 :: (F3 r ~ F1 (F2 m)) => r -> m ()
| ^
Panic.hs:40:21: warning: [GHC-58520] [-Wtype-equality-requires-operators]
The use of ‘~’ without TypeOperators
will become an error in a future GHC release.
Suggested fix: Perhaps you intended to use TypeOperators
|
40 | test :: (C2 m, F2 m ~ Y) => m ()
| ^
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.6.2:
lookupIdSubst
$dMonad_aWA
InScope {$dIP_aUI $dIP_aUN m_aUW $dC2_aUX $d~_aUY $krep_aWW
$krep_aWX $krep_aWY $krep_aWZ $krep_aX0 $krep_aX1 $krep_aX2
$krep_aX3 $krep_aX4 fun1 fun2 fun3 fun4 $tcC1 $tc'C:C1 $tcC2
$tc'C:C2 $tcC3 $tc'C:C3 $tcG $tcY $tcX $tcH $tcS $trModule}
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/Subst.hs:197:17 in ghc:GHC.Core.Subst
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:454:29 in ghc:GHC.Utils.Error
```
## Expected behavior
This should give a type error and stop there, not proceeding to PostTc phase.
## Environment
* GHC version used: ghc 9.6.2
* Operating System: macOS Ventura 13.5.2Krzysztof GogolewskiKrzysztof Gogolewski