GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-25T19:13:15Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24559Lambda with invisible type pattern fails to splice with TemplateHaskell2024-03-25T19:13:15ZRyan ScottLambda with invisible type pattern fails to splice with TemplateHaskellI am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Here is an example of an expression one can write with this feature:
```hs
{-# LA...I am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Here is an example of an expression one can write with this feature:
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeAbstractions #-}
module Foo where
import Data.Kind
import Data.Proxy
f :: (forall (a :: Type). Proxy a) -> Proxy Bool
f k = k @Bool
g1 :: Proxy Bool
g1 = f (\ @a -> Proxy @a)
```
So far, so good. Now let's introduce a variant of `g1` where the expression is spliced in via `TemplateHaskell`:
```hs
g2 :: Proxy Bool
g2 = f $([| \ @a -> Proxy @a |])
```
I would expect this to typecheck just like `g1` does. And yet, it doesn't:
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:16:9: error: [GHC-14964]
• Invisible type pattern a has no associated forall
• In the first argument of ‘f’, namely ‘(\ @a -> Proxy @a)’
In the expression: f (\ @a -> Proxy @a)
In an equation for ‘g2’: g2 = f (\ @a -> Proxy @a)
|
16 | g2 = f $([| \ @a -> Proxy @a |])
| ^^^^^^^^^^^^^^^^^^^^^^^^
```9.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24557TypeAbstractions doesn't parse with \case, but does parse with \cases2024-03-28T08:53:38ZRyan ScottTypeAbstractions doesn't parse with \case, but does parse with \casesI am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractio...I am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractions` could be combined with `LambdaCase`, e.g.,
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE TypeAbstractions #-}
module Foo where
import Data.Kind
f :: (forall (a :: Type). ()) -> ()
f k = k @Bool
g :: ()
g = f (\cases
@a -> ())
```
Great. What is surprising, however, is that if I change `\cases` to be `\case`:
```hs
g :: ()
g = f (\case
@a -> ())
```
Then GHC fails to parse it:
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:11:8: error: [GHC-06074]
Unexpected \case expression in function application:
\case
Suggested fixes:
• Use parentheses.
• Perhaps you intended to use BlockArguments
|
11 | g = f (\case
| ^
Foo.hs:11:8: error: [GHC-66228]
View pattern in expression context: \case @a -> ()
|
11 | g = f (\case
| ^^^^^...
```
This feels inconsistent, as I would expect that if `\cases` works, then `\case` should also work. Is this intended?https://gitlab.haskell.org/ghc/ghc/-/issues/24213"Unbound RULE binders" conditions too restrictive?2023-11-29T14:00:15ZBen Gamari"Unbound RULE binders" conditions too restrictive?While debugging a client project a colleague encountered Core Lint error after simplification:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: error: [-Werror]
Rule "SC:$j0": unbound [sg_svBxD]
In the ...While debugging a client project a colleague encountered Core Lint error after simplification:
```
*** Core Lint errors : in result of Simplifier ***
<no location info>: error: [-Werror]
Rule "SC:$j0": unbound [sg_svBxD]
In the RHS of $w$ctoSQL_svxsI :: ByteArray#
-> Int#
-> Int#
-> TableName
-> SetExp
-> Maybe FromExp
-> Maybe WhereFrag
-> Maybe RetExp
-> (# ArrayWriter, Int#, Int# #)
In the body of lambda with binder ww_svxsv :: ByteArray#
In the body of lambda with binder ww_svxsw :: Int#
In the body of lambda with binder ww_svxsx :: Int#
In the body of lambda with binder ww_svxsz :: TableName
In the body of lambda with binder ww_svxsB :: SetExp
In the body of lambda with binder ww_svxsC :: Maybe FromExp
In the body of lambda with binder ww_svxsD :: Maybe WhereFrag
In the body of lambda with binder ww_svxsE :: Maybe RetExp
In a case alternative: (TextBuilder ww_av2BQ :: ArrayWriter,
ww1_av2BR :: Int#,
ww2_av2BS :: Int#)
In a case alternative: ((#,,#) ww5_iv2AG :: ArrayWriter,
ww6_iv2AH :: Int#,
ww7_iv2AI :: Int#)
In a case alternative: ((#,,#) ww_svy6c :: ArrayWriter,
ww_svy6d :: Int#,
ww_svy6e :: Int#)
In the body of lambda with binder sc_svBxy :: Int#
In the body of lambda with binder sc_svBxx :: Int#
In the body of lambda with binder sg_svBxw :: (forall {s}.
MArray s
-> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter
In the body of letrec with binders $s$j_svBxQ :: Int#
-> Int#
-> ((forall {s}.
MArray s
-> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter) =>
(# ArrayWriter, Int#, Int# #)
In the body of lambda with binder ww_XoV :: ArrayWriter
In the body of lambda with binder ww1_XoW :: Int#
In the body of lambda with binder ww2_XoX :: Int#
In the body of letrec with binders $s$j_svBxJ :: Int#
-> Int#
-> ((forall {s}.
MArray s
-> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter) =>
(# ArrayWriter, Int#, Int# #)
In a rule attached to $j_sv2DD :: ArrayWriter
-> Int# -> Int# -> (# ArrayWriter, Int#, Int# #)
Substitution: <InScope = {sg_svBxw sg_svBxD}
IdSubst = []
TvSubst = []
CvSubst = [svBxw :-> sg_svBxw, svBxD :-> sg_svBxD]
```
As seen in the relevant Core (see below), the problem is the occurrence of an coercion variable in the RHS of a spec-constr rule which is *not* bound in the rule's LHS. This coercion witnesses the equality of the `ArrayWriter` newtype and its representation:
```haskell
newtype ArrayWriter
= ArrayWriter (forall s. TextArray.MArray s -> Int -> ST s Int)
```
The coercion variable appears to have arisen from the `(N:ArrayWriter[0] :: ArrayWriter ~R# (forall s. MArray s -> Int -> ST s Int))` coercion appearing in the unspecialised binding's RHS (perhaps introduced by SpecConstr itself? we are currently checking this). If SpecConstr is indeed the source of the coercion variable then this seems like a bug; afterall, there should be no need to abstract over closed coercions.
However, this also seems quite similar to the issue observed in `Note [Unbound RULE binders]`. Specifically, that Note specifies that we allow certain (namely, reflexive) coercion variables to occur in a rule's RHS despite being not bound by the LHS. The Note says that, while such occurrences are a bit strange, they are hard to avoid as the result of simplification.
The Core Lint offense suggests to me that the reflexivity restriction of `Note [Unbound RULE binders]` may be too strict: Newtype coercions seem just as benign as reflexive coercions. Sadly, I don't have a minimal reproducer to demonstrate the issue.
<details><summary>Binding and questionable rule</summary>
```haskell
...
join {
$j_sv2DD
:: ArrayWriter -> Int# -> Int# -> (# ArrayWriter, Int#, Int# #)
[LclId[JoinId(3)(Nothing)],
Arity=3,
Str=<SC(L,C(1,C(1,L)))><L><L>,
Unf=Unf{Src=<vanilla>, TopLvl=False,
Value=True, ConLike=True, WorkFree=True, Expandable=True,
Guidance=IF_ARGS [20 0 0] 432 10},
RULES: "SC:$j0"
forall (sc_svBxF :: Int#)
(sc_svBxE :: Int#)
(sg_svBxD
:: (forall {s}.
MArray s -> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter).
$j_sv2DD ($fMonoidBuilder3
`cast` (sg_svBxw
:: (forall {s}.
MArray s
-> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter))
sc_svBxE
sc_svBxF
= jump $s$j_svBxJ
sc_svBxF
sc_svBxE
@~(sg_svBxD
:: (forall {s}.
MArray s -> Int -> State# s -> (# State# s, Int #))
~R# ArrayWriter)]
$j_sv2DD (ww3_av2BZ [Dmd=SC(L,C(1,C(1,L))), OS=OneShot]
:: ArrayWriter)
(ww4_av2C0 [OS=OneShot] :: Int#)
(ww5_av2C1 [OS=OneShot] :: Int#)
= case ww3_av2BZ
`cast` (N:ArrayWriter[0]
:: ArrayWriter ~R# (forall s. MArray s -> Int -> ST s Int))
of nt_sv85q [Dmd=LC(S,C(S,C(S,L)))]
...
```
</details>
Full error: https://gitlab.haskell.org/ghc/ghc/-/snippets/5737https://gitlab.haskell.org/ghc/ghc/-/issues/24202DataToTag instances in signature files don't work2023-11-21T23:06:40ZMatthew Cravenclyring@gmail.comDataToTag instances in signature files don't work## Summary
Since !8912 landed, signature files are allowed to contain/request instances for the special `DataToTag` class. But these are not actually usable, and fail with a very unhelpful error message.
In principle there is no reason...## Summary
Since !8912 landed, signature files are allowed to contain/request instances for the special `DataToTag` class. But these are not actually usable, and fail with a very unhelpful error message.
In principle there is no reason it shouldn't be possible to support `DataToTag` instances in signatures, but doing so doesn't appear completely trivial and there seems to be little or no demand for this feature.
See also the test case `T15379-DataToTag`.https://gitlab.haskell.org/ghc/ghc/-/issues/24173`-Wunused-packages` overreports with alternative Preludes2023-12-04T16:33:50ZLeo Zhang`-Wunused-packages` overreports with alternative Preludes## Summary
Using an alternative Prelude (in my case, Relude) through `mixins` will cause `-Wunused-packages` to report that a package is unused when it is actually used. I suspect this might be related to https://gitlab.haskell.org/ghc/...## Summary
Using an alternative Prelude (in my case, Relude) through `mixins` will cause `-Wunused-packages` to report that a package is unused when it is actually used. I suspect this might be related to https://gitlab.haskell.org/ghc/ghc/-/issues/18563, which is also related to `mixins`.
## Steps to reproduce
1. Clone https://github.com/elldritch/cabal-unused-packages-mixin-repro and make sure you're running GHC 9.4.7.
2. Run `cabal build`.
You should see this error message:
```
$ cabal build
Build profile: -w ghc-9.4.7 -O1
In order, the following will be built (use -v for more details):
- cabal-unused-packages-mixin-repro-0.1.0.0 (lib) (file src/Example.hs changed)
Preprocessing library for cabal-unused-packages-mixin-repro-0.1.0.0..
Building library for cabal-unused-packages-mixin-repro-0.1.0.0..
<no location info>: error: [-Wunused-packages, -Werror=unused-packages]
The following packages were specified via -package or -package-id flags,
but were not needed for compilation:
- relude-1.2.1.0 (exposed by flag -package-id relude-1.2.1.0-ea787ea216b250f63edab15a196f92bee0e612410323d35bd7a6caf35e8a006b)
Error: cabal: Failed to build cabal-unused-packages-mixin-repro-0.1.0.0.
```
## Expected behavior
This warning should not be triggered, since Relude is being imported as the implicit Prelude.
## Environment
* GHC version used: 9.4.7
Optional:
* Operating System: Arch Linux
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24099Kind Inference fails when working with TypeFamilies of levity polymorphic kind2023-11-16T12:09:52ZMathias SvenKind Inference fails when working with TypeFamilies of levity polymorphic kind## Summary
This [code](https://github.com/goldfirere/video-resources/blob/main/2021-12-28-tuple/TupleSimpler.hs) (usecase) used to typecheck on `GHC 8.10.7`, but it no longer works on either `GHC 9.4.6` or `GHC 9.7.20230527`, here is a ...## Summary
This [code](https://github.com/goldfirere/video-resources/blob/main/2021-12-28-tuple/TupleSimpler.hs) (usecase) used to typecheck on `GHC 8.10.7`, but it no longer works on either `GHC 9.4.6` or `GHC 9.7.20230527`, here is a minimal example of the issue:
```hs
{-# LANGUAGE MagicHash, TypeFamilyDependencies, DataKinds #-}
module Test where
import Data.Kind (Type)
import GHC.Exts ( Int#, TYPE, RuntimeRep )
type FooKind :: RuntimeRep -> Type
type family FooKind rep = r | r -> rep where
FooKind rep = TYPE rep
type Foo :: forall (rep :: RuntimeRep). FooKind rep
type family Foo where
Foo = Int#
t :: () -> Foo
t _ = 42#
```
```
• Couldn't match a lifted type with an unlifted type
When matching types
Foo :: FooKind LiftedRep
Int# :: TYPE 'IntRep
• In the expression: 42#
In an equation for ‘t’: t _ = 42#typecheck(-Wdeferred-type-errors)
```
It seems that `rep` is too eager to resolve to `LiftedRep`, strangely, enabling `PartialTypeSignatures` and simply giving a wildcard type annotation to `Foo` in `t` fixes the inference problem.
```hs
t :: () -> (Foo :: _)
t _ = 42#
```
Now this typechecks correctly.Krzysztof GogolewskiKrzysztof Gogolewskihttps://gitlab.haskell.org/ghc/ghc/-/issues/24095Parse error when annotating type-class instance functions.2023-10-24T14:44:06Zsyd@cs-syd.euParse error when annotating type-class instance functions.## Summary
Please read the guidance in [https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug] and write a brief description of the issue.
## Steps to reproduce
Code:
```
instance Show Foo where
{-# ANN show "hi" #-}
show _ = "F...## Summary
Please read the guidance in [https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug] and write a brief description of the issue.
## Steps to reproduce
Code:
```
instance Show Foo where
{-# ANN show "hi" #-}
show _ = "Foo"
```
Parse error:
```
ann.hs:2:3: error: parse error on input ‘{-# ANN’
|
2 | {-# ANN show "hi" #-}
| ^^^^^^^
```
## Expected behavior
Succesful parse
## Environment
* GHC version used: `9.2.8` and `9.7.20230505`
Optional:
* Operating System: NixOS
* System Architecture: x86_64-linuxhttps://gitlab.haskell.org/ghc/ghc/-/issues/24037GHC 9.8 regression: Fixity declaration for prefix type family in class no lon...2023-10-10T12:51:59ZRyan ScottGHC 9.8 regression: Fixity declaration for prefix type family in class no longer acceptedGHC 9.8 and HEAD reject the following program (minimized from the [`singletons-base`](https://hackage.haskell.org/package/singletons-base) test suite), which GHC 9.6 and earlier accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug whe...GHC 9.8 and HEAD reject the following program (minimized from the [`singletons-base`](https://hackage.haskell.org/package/singletons-base) test suite), which GHC 9.6 and earlier accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug where
class POrd a where
type Geq a b
infixr 6 `Geq`
```
```
$ ghc-9.6.2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
$ ghc-9.8.0.20230929 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:6:12: error: [GHC-54721]
‘Geq’ is not a (visible) method of class ‘POrd’
|
6 | infixr 6 `Geq`
| ^^^^^
```
This is likely related to #23664, except that that bug can only be triggered if the type family name consists of symbolic characters. This bug, on the other hand, occurs when the name has alphanumeric characters.9.8.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23884Unexpected representation-polymorphism error when using default signatures2024-01-11T21:24:47Zsheafsam.derbyshire@gmail.comUnexpected representation-polymorphism error when using default signaturesI would expect the following program from @adamgundry to work, but it doesn't:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FunctionalDependencies #-}
module T23884 where
import Data....I would expect the following program from @adamgundry to work, but it doesn't:
```haskell
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE FunctionalDependencies #-}
module T23884 where
import Data.Kind
import GHC.Exts
type SetField :: forall {k} {r_rep} {a_rep} . k -> TYPE r_rep -> TYPE a_rep -> Constraint
class SetField x r a | x r -> a where
modifyField :: (a -> a) -> r -> r
setField :: a -> r -> r
default setField :: (a_rep ~ LiftedRep) => a -> r -> r
setField x = modifyField (\ _ -> x)
```
```
T23884.hs:16:3: error: [GHC-55287]
The first pattern in the equation for `setField'
does not have a fixed runtime representation.
Its type is:
a :: TYPE a_rep
|
16 | setField x = modifyField (\ _ -> x)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
T23884.hs:16:36: error: [GHC-55287]
* The binder of the lambda expression
does not have a fixed runtime representation.
Its type is:
a0 :: TYPE a_rep0
Cannot unify `a_rep' with the type variable `a_rep0'
because the former is not a concrete `RuntimeRep'.
* In the expression: x
In the first argument of `modifyField', namely `(\ _ -> x)'
In the expression: modifyField (\ _ -> x)
```https://gitlab.haskell.org/ghc/ghc/-/issues/23796TemplateHaskell typechecking regression in HEAD2023-08-08T13:08:41ZRyan ScottTemplateHaskell typechecking regression in HEAD_(Originally observed in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1632860).)_
The `what4-1.4` Hackage library currently fails to build with GHC HEAD + `head.hackage`. Here is a minimized example ..._(Originally observed in a `head.hackage` CI job [here](https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1632860).)_
The `what4-1.4` Hackage library currently fails to build with GHC HEAD + `head.hackage`. Here is a minimized example of the issue:
```hs
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
good :: (forall a. a -> a) -> b -> b
good = \g x -> g x
bad :: (forall a. a -> a) -> b -> b
bad = $([| \g x -> g x |])
```
This compiles with GHC 9.8 and earlier, but fails to typecheck with GHC HEAD at commit b938950d98945f437f1e28b15a0a3629bfe336c2:
```
$ ghc-head Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:8: error: [GHC-83865]
• Couldn't match type: b -> b
with: forall a. a -> a
Expected: (forall a. a -> a) -> b -> b
Actual: (b -> b) -> b -> b
• In the expression: \ g_a24j x_a24k -> g_a24j x_a24k
In an equation for ‘bad’: bad = (\ g_a24j x_a24k -> g_a24j x_a24k)
• Relevant bindings include
bad :: (forall a. a -> a) -> b -> b (bound at Bug.hs:9:1)
|
9 | bad = $([| \g x -> g x |])
| ^^^^^^^^^^^^^^^^^^^
```
I think both of these should be accepted, as the only difference between `good` and `bad` is the presence of a Template Haskell splice.
While I haven't had time to bisect the issue just yet, my first hunch is to suspect commit !10911 (`Look through TH splices in splitHsApps`).9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/23763`Nat` (in)equality transitivity or congruence regression in GHC 9.8.1-alpha1:...2023-09-11T13:21:22ZMikolaj Konarski`Nat` (in)equality transitivity or congruence regression in GHC 9.8.1-alpha1: Cannot satisfy: OS.Rank sh2 <= 1 + OS.Rank sh1Repro with GHC 9.8.1-alpha1 and head.hackage (http://ghc.gitlab.haskell.org/head.hackage/):
* clone https://github.com/Mikolaj/horde-ad/commit/e76ff6c2f2b1fc53a00c6b78f74cb1ab8b94790d
* `cabal build`
* you get
```
src/HordeAd/Core/As...Repro with GHC 9.8.1-alpha1 and head.hackage (http://ghc.gitlab.haskell.org/head.hackage/):
* clone https://github.com/Mikolaj/horde-ad/commit/e76ff6c2f2b1fc53a00c6b78f74cb1ab8b94790d
* `cabal build`
* you get
```
src/HordeAd/Core/AstSimplify.hs:1192:9: error: [GHC-64725]
• Cannot satisfy: OS.Rank sh2 <= 1 + OS.Rank sh1
• In the first argument of ‘($)’, namely ‘astTransposeS @zsuccPerm’
In the second argument of ‘($)’, namely
‘astTransposeS @zsuccPerm $ astReplicateS @n v’
In the second argument of ‘($)’, namely
‘trustMeThisIsAPermutation @zsuccPerm
$ astTransposeS @zsuccPerm $ astReplicateS @n v’
|
1192 | $ astTransposeS @zsuccPerm $ astReplicateS @n v
```
It works fine with GHC <= 9.6 and also after patching it in the following way:
https://github.com/Mikolaj/horde-ad/commit/0417f413051f1739fe32cfaf7869755276171449
My guess is that previously GHC could deduce:
OS.Rank zsuccPerm <= 1 + OS.Rank sh1
from (note that `sh2` that GHC invents here in just `zsuccPerm` -- this obfuscation in error messages is already reported in one of my older tickets)
OS.Rank zsuccPerm :~: 1 + OS.Rank perm
and
OS.Rank perm <= OS.Rank sh1
but now it can't.
The issue may be in GHC itself or in how plugin `GHC.TypeLits.Normalise` has been updated to 9.8.1-alpha1, but I doubt the latter, because it's been updated on head.hackage by people that know what they are doing.
I haven't tried with HEAD of the github repo of `GHC.TypeLits.Normalise` and GHC 9.6, but I don't think `GHC.TypeLits.Normalise` has been modified vs the version on Hackage (`GHC.TypeLits.KnownNat.Solver` has been, but it seem unrelated).
CC: @christiaanbhttps://gitlab.haskell.org/ghc/ghc/-/issues/23692ApplicativeDo breaks typechecking2023-07-25T14:22:12ZSergey VinokurovApplicativeDo breaks typechecking## Summary
When enabling the `ApplicativeDo` extension the provided program ceases to typecheck. It does work in 9.4.5 and does work if I move `putStrLn` around or remove it entirely, which is surprising. Removing `ApplicativeDo` extens...## Summary
When enabling the `ApplicativeDo` extension the provided program ceases to typecheck. It does work in 9.4.5 and does work if I move `putStrLn` around or remove it entirely, which is surprising. Removing `ApplicativeDo` extension also helps but I'd like to get its effects in `parseCommandLine` function (omitted here for brevity).
## Steps to reproduce
Compile the following program.
Original program:
```haskell
{-# LANGUAGE ApplicativeDo #-}
module Main (main) where
import Control.Monad
data Command
= PolyCmd
| VanillaCmd
data CommonConfig = CommonConfig
{ ccVerbose :: Bool
}
parseCommandline :: IO (CommonConfig, Command)
parseCommandline = undefined
locateHelper :: FilePath -> IO (Maybe FilePath)
locateHelper = undefined
complexWrapper :: IO a -> IO a
complexWrapper = undefined
vanillaRun :: IO ()
vanillaRun = pure ()
polyRun :: (forall a. IO a -> IO a) -> IO ()
polyRun f = f $ pure ()
main :: IO ()
main = do
(config, cmd) <- parseCommandline
when (ccVerbose config) $
putStrLn "OK"
let wrapper :: IO a -> IO a
wrapper act = do
complexWrapper act
case cmd of
VanillaCmd -> wrapper vanillaRun
PolyCmd -> polyRun wrapper
```
```
$ ghc -c Main.hs
Main.hs:42:27: error: [GHC-25897]
• Couldn't match type ‘a’ with ‘()’
Expected: IO a -> IO a
Actual: IO () -> IO ()
‘a’ is a rigid type variable bound by
a type expected by the context:
forall a. IO a -> IO a
at Main.hs:42:27-33
• In the first argument of ‘polyRun’, namely ‘wrapper’
In the expression: polyRun wrapper
In a case alternative: PolyCmd -> polyRun wrapper
|
42 | PolyCmd -> polyRun wrapper
| ^^^^^^^
```
However this one does typecheck
```haskell
{-# LANGUAGE ApplicativeDo #-}
module Main (main) where
import Control.Monad
data Command
= PolyCmd
| VanillaCmd
data CommonConfig = CommonConfig
{ ccVerbose :: Bool
}
parseCommandline :: IO (CommonConfig, Command)
parseCommandline = undefined
locateHelper :: FilePath -> IO (Maybe FilePath)
locateHelper = undefined
complexWrapper :: IO a -> IO a
complexWrapper = undefined
vanillaRun :: IO ()
vanillaRun = pure ()
polyRun :: (forall a. IO a -> IO a) -> IO ()
polyRun f = f $ pure ()
main :: IO ()
main = do
(config, cmd) <- parseCommandline
let wrapper :: IO a -> IO a
wrapper act = do
when (ccVerbose config) $
putStrLn "OK"
complexWrapper act
case cmd of
VanillaCmd -> wrapper vanillaRun
PolyCmd -> polyRun wrapper
```
Commenting out `ApplicativeDo` also makes the original program typecheck.
## Expected behavior
Original program typechecks successfully with `ApplicativeDo` extension enabled.
## Environment
* GHC version used: 9.6.2
Optional:
* Operating System: Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/23664HEAD regression: GHC no longer accepts fixity declaration in class2023-10-05T20:22:43ZRyan ScottHEAD regression: GHC no longer accepts fixity declaration in class_(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) rejects the following program, which earlier versions of GHC accept..._(Originally observed in a `head.hackage` issue: https://gitlab.haskell.org/ghc/head.hackage/-/issues/88)_
GHC HEAD (at commit eb1a6ab1df473c7ec0e1cbb20fc7124706326ce1) rejects the following program, which earlier versions of GHC accept:
```hs
{-# LANGUAGE TypeFamilies #-}
module Bug where
class POrd a where
type a >= b
infix 4 >=
```
```
$ ghc-9.6.2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
$ ghc-9.9.20230716 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:6:11: error: [GHC-54721]
‘>=’ is not a (visible) method of class ‘POrd’
|
6 | infix 4 >=
| ^^
```
Note that:
* It is important that `>=` also be the name of another identifier already in scope. If I rename `>=` to, say, `>==`, then the error disappears.
* It is also important that `>=` be an associated type family. If I change `>=` to an ordinary class method, then the error disappears.9.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/23322Backpack: Import standalone modules from indefinite packages in instancing mo...2023-07-02T23:06:56ZRodrigo MesquitaBackpack: Import standalone modules from indefinite packages in instancing modules failsSay I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module...Say I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module B.Instance where
import A
someUsefulFun :: SomeUsefulThing -> ()
someUsefulFun SomeUsefulThing = ()
```
Note that in B's signature and instance, `someUsefulFun` share the same type `SomeUsefulThing` imported from `A`.
```haskell
import A
import B
main = pure (someUsefulFun SomeUsefulThing)
```
```cabal
cabal-version: 3.4
name: ex2
version: 0.1.0.0
build-type: Simple
library pa
build-depends: base
exposed-modules: A
signatures: B
hs-source-dirs: pa
library pb
build-depends: base, ex2:pa
exposed-modules: B.Instance
hs-source-dirs: pb
library
exposed-modules: Main
build-depends: base, ex2:pa, ex2:pb
mixins: ex2:pa requires (B as B.Instance),
hs-source-dirs: main
```
When compiling this project, it fails with
```
<no location info>: error:
• Identifier ‘someUsefulFun’ has conflicting definitions in the module
and its hsig file
Main module: someUsefulFun ::
ex2-0.1.0.0:pa[B=<B>]:A.SomeUsefulThing -> ()
Hsig file: someUsefulFun :: A.SomeUsefulThing -> ()
The two types are different
• while checking that B.Instance implements signature B in ex2-0.1.0.0:pa[B=B.Instance]
```
The cause is `SomeUsefulThing`, in the context of `pa` is imported from `A`, but in the context of `pb`, is imported from `ex2:pa[B=<B>]:A`.
I think it should be possible to use the shared definition of `SomeUsefulThing`, since `A` is a completely standalone module (doesn't depend on any indefinite signatures). Even if it did, it is reasonable to think it should also work.
Is this a fundamental limitation or something we can overcome?
Many thanks.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23228Cmm lint error in GHC.Bits when compiled without optimisation2023-07-30T17:31:59ZMatthew PickeringCmm lint error in GHC.Bits when compiled without optimisation
Repro, add the `OPTIONS_GHC` pragma to the top of `GHC.Bits`
```
{-# OPTIONS_GHC -O0 -}
```
```
./hadrian/build --flavour=validate -o_validate -j4 _validate/stage1/libraries/base/build/GHC/Bits.o
```
Gives the following Cmm lint e...
Repro, add the `OPTIONS_GHC` pragma to the top of `GHC.Bits`
```
{-# OPTIONS_GHC -O0 -}
```
```
./hadrian/build --flavour=validate -o_validate -j4 _validate/stage1/libraries/base/build/GHC/Bits.o
```
Gives the following Cmm lint error:
```
Cmm lint error:
in basic block c2E2
Shift operation MO_U_Shr W64 has out-of-range offset 64. This will result in undefined behavior
Program was:
{offset
c2CU: // global
_s1YF::P64 = R3; // CmmAssign
_s1YE::P64 = R2; // CmmAssign
if ((old + 0) - <highSp> < SpLim) (likely: False) goto c2CY; else goto c2CZ; // CmmCondBranch
c2CY: // global
R3 = _s1YF::P64; // CmmAssign
R2 = _s1YE::P64; // CmmAssign
R1 = $crotate2_r1Hc_closure; // CmmAssign
call (stg_gc_fun)(R3, R2, R1) args: 8, res: 0, upd: 8; // CmmCall
c2CZ: // global
I64[(young<c2CR> + 8)] = c2CR; // CmmStore
R1 = _s1YE::P64; // CmmAssign
if (R1 & 7 != 0) goto c2CR; else goto c2CS; // CmmCondBranch
c2CS: // global
call (I64[R1])(R1) returns to c2CR, args: 8, res: 8, upd: 8; // CmmCall
c2CR: // global
_s1YG::P64 = R1; // CmmAssign
_s1YH::I64 = I64[_s1YG::P64 + 7]; // CmmAssign
I64[(young<c2CX> + 8)] = c2CX; // CmmStore
R1 = _s1YF::P64; // CmmAssign
if (R1 & 7 != 0) goto c2CX; else goto c2D1; // CmmCondBranch
c2D1: // global
call (I64[R1])(R1) returns to c2CX, args: 8, res: 8, upd: 8; // CmmCall
c2CX: // global
_s1YI::P64 = R1; // CmmAssign
_s1YJ::I64 = I64[_s1YI::P64 + 7]; // CmmAssign
_c2D6::I64 = _s1YJ::I64 & 63; // CmmAssign
_s1YK::I64 = _c2D6::I64; // CmmAssign
switch [-9223372036854775808 .. 9223372036854775807] _s1YK::I64 {
case 0 : goto c2DK;
default: {goto c2Db;}
} // CmmSwitch
c2DK: // global
// slowCall
I64[(young<c2DO> + 8)] = c2DO; // CmmStore
R2 = 1; // CmmAssign
R1 = isTrue#_closure; // CmmAssign
call stg_ap_n_fast(R2,
R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2DO: // global
_s1YQ::P64 = R1; // CmmAssign
// slow_call for isTrue#_closure with pat stg_ap_n
_c2Ec::P64 = _s1YQ::P64 & 7; // CmmAssign
switch [1 .. 2] _c2Ec::P64 {
case 1 : goto c2E0;
case 2 : goto c2E7;
} // CmmSwitch
c2E7: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2Ea; else goto c2E9; // CmmCondBranch
c2Ea: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YQ::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2E9: // global
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YH::I64; // CmmStore
_c2E6::P64 = Hp - 7; // CmmAssign
R1 = _c2E6::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2E0: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2E3; else goto c2E2; // CmmCondBranch
c2E3: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YQ::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2DO, args: 8, res: 8, upd: 8; // CmmCall
c2E2: // global
_c2DS::I64 = _s1YH::I64 >> 64; // CmmAssign
_s1YR::I64 = _c2DS::I64; // CmmAssign
_c2DV::I64 = _s1YH::I64 | _s1YR::I64; // CmmAssign
_s1YS::I64 = _c2DV::I64; // CmmAssign
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YS::I64; // CmmStore
_c2DY::P64 = Hp - 7; // CmmAssign
R1 = _c2DY::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2Db: // global
// slowCall
I64[(young<c2Df> + 8)] = c2Df; // CmmStore
R2 = 0; // CmmAssign
R1 = isTrue#_closure; // CmmAssign
call stg_ap_n_fast(R2,
R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2Df: // global
_s1YL::P64 = R1; // CmmAssign
// slow_call for isTrue#_closure with pat stg_ap_n
_c2Eb::P64 = _s1YL::P64 & 7; // CmmAssign
switch [1 .. 2] _c2Eb::P64 {
case 1 : goto c2Dx;
case 2 : goto c2DE;
} // CmmSwitch
c2DE: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2DH; else goto c2DG; // CmmCondBranch
c2DH: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YL::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2DG: // global
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YH::I64; // CmmStore
_c2DD::P64 = Hp - 7; // CmmAssign
R1 = _c2DD::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
c2Dx: // global
Hp = Hp + 16; // CmmAssign
if (Hp > HpLim) (likely: False) goto c2DA; else goto c2Dz; // CmmCondBranch
c2DA: // global
HpAlloc = 16; // CmmAssign
R1 = _s1YL::P64; // CmmAssign
call stg_gc_unpt_r1(R1) returns to c2Df, args: 8, res: 8, upd: 8; // CmmCall
c2Dz: // global
_c2Dj::I64 = 64 - _s1YK::I64; // CmmAssign
_s1YN::I64 = _c2Dj::I64; // CmmAssign
_c2Dm::I64 = _s1YH::I64 >> _s1YN::I64; // CmmAssign
_s1YO::I64 = _c2Dm::I64; // CmmAssign
_c2Dp::I64 = _s1YH::I64 << _s1YK::I64; // CmmAssign
_s1YM::I64 = _c2Dp::I64; // CmmAssign
_c2Ds::I64 = _s1YM::I64 | _s1YO::I64; // CmmAssign
_s1YP::I64 = _c2Ds::I64; // CmmAssign
// allocHeapClosure
I64[Hp - 8] = W#_con_info; // CmmStore
I64[Hp] = _s1YP::I64; // CmmStore
_c2Dv::P64 = Hp - 7; // CmmAssign
R1 = _c2Dv::P64; // CmmAssign
call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; // CmmCall
}
<no location info>: error:
Compilation had errors
Command failed
Build failed.
```https://gitlab.haskell.org/ghc/ghc/-/issues/23040`OverloadedRecordDot` and `COLUMN`-pragmas don't play nice together2023-02-28T15:27:27ZSimon Hengelsol@typeful.net`OverloadedRecordDot` and `COLUMN`-pragmas don't play nice together## Summary
`foo.foo` is accepted while `foo{-# COLUMN 23 #-}.foo` results in a parse error.
This is surprising from a users perspective and can break `OverloadedRecordDot` with source-to-source transformations / pre-processors (as it d...## Summary
`foo.foo` is accepted while `foo{-# COLUMN 23 #-}.foo` results in a parse error.
This is surprising from a users perspective and can break `OverloadedRecordDot` with source-to-source transformations / pre-processors (as it does for me).
## Steps to reproduce
```
{-# LANGUAGE NoFieldSelectors #-}
{-# LANGUAGE OverloadedRecordDot #-}
data Foo = Foo { foo :: String }
foo :: Foo
foo = Foo "foo"
main :: IO ()
main = do
putStrLn foo.foo -- works
putStrLn foo{-# COLUMN 23 #-}.foo -- parse error
```
## Expected behavior
Both `foo.foo` and `foo{-# COLUMN 23 #-}.foo` should be accepted.
## Investigation
`foo.foo` is tokenized to:
[ITvarid "foo", ITproj False, ITvarid "bar"]
However, `foo{-# COLUMN 23 #-}.foo` is tokenized to:
[ITvarid "foo", ITproj True, ITvarid "bar"]
So from what I understand, even though this manifests as a parse error, the bug is actually in the lexer.
## Environment
* GHC version used: 9.6.0.20230111
Optional:
* Operating System: Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/22762eqType, tcEqType, and foralls2024-01-23T18:13:25ZRyan ScotteqType, tcEqType, and forallsSee also
* https://gitlab.haskell.org/ghc/ghc/-/wikis/DH-Current-Status, and
* [GHC proposal issue #558](https://github.com/ghc-proposals/ghc-proposals/issues/558) "Apartness of visible and invisible forall".
The following program pas...See also
* https://gitlab.haskell.org/ghc/ghc/-/wikis/DH-Current-Status, and
* [GHC proposal issue #558](https://github.com/ghc-proposals/ghc-proposals/issues/558) "Apartness of visible and invisible forall".
The following program passes Core Lint on GHC 9.4 and earlier:
```hs
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module Bug where
import Data.Kind
type Const :: a -> b -> a
type family Const x y where
Const x _ = x
type F :: (forall (b :: Bool) -> Const Type b) -> Type
data F f
type G :: forall (b :: Bool) -> Type
data G b
type H :: Type
type family H where
H = F G
```
But fails on GHC 9.6.1-alpha1:
```
$ ghc-9.6.0.20230111 Bug.hs -dcore-lint -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
*** Core Lint errors : in result of TcGblEnv axioms ***
Bug.hs:20:13: warning:
From-kind of Cast differs from kind of enclosed type
From-kind: forall (b :: Bool) -> *
Kind of enclosed type: forall {b :: Bool}. *
Actual enclosed type: G
Coercion used in cast: forall (b :: <Bool>_N).
Sym (D:R:Const[0] <*>_N <Bool>_N <b>_N <*>_N)
In the coercion axiom
axiom D:R:H
{H = F (G |> forall (b :: <Bool>_N).
Sym (D:R:Const[0] <*>_N <Bool>_N <b>_N <*>_N))
-- Defined at Bug.hs:21:3}
Substitution: <InScope = {}
IdSubst = []
TvSubst = []
CvSubst = []>
*** Offending Program ***
axiom D:R:Const
{forall {a} {b} {x :: a}.
Const x _ = x_ahb -- Defined at Bug.hs:11:3}
axiom D:R:H
{H = F (G |> forall (b :: <Bool>_N).
Sym (D:R:Const[0] <*>_N <Bool>_N <b>_N <*>_N))
-- Defined at Bug.hs:21:3}
*** End of Offense ***
<no location info>: error:
Compilation had errors
<no location info>: error: ExitFailure 1
```9.10.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/22717Instance not transitively forwarded2023-04-18T18:14:53ZLemmingInstance not transitively forwarded## Summary
When compiling the tests of synthesizer-llvm/HEAD I get:
~~~~
testsuite/Test/Synthesizer/LLVM/Utility.hs:77:30: error:
• Couldn't match type ‘CausalClass.SignalOf
(CausalClass.ProcessOf Sig.T...## Summary
When compiling the tests of synthesizer-llvm/HEAD I get:
~~~~
testsuite/Test/Synthesizer/LLVM/Utility.hs:77:30: error:
• Couldn't match type ‘CausalClass.SignalOf
(CausalClass.ProcessOf Sig.T)’
with ‘Sig.T’
Expected: Sig.T (al, bl)
-> CausalClass.ProcessOf Sig.T () (MultiValue.T a, MultiValue.T b)
Actual: CausalClass.SignalOf
(CausalClass.ProcessOf Sig.T) (MultiValue.T a, MultiValue.T b)
-> CausalClass.ProcessOf Sig.T () (MultiValue.T a, MultiValue.T b)
• In the first argument of ‘(.)’, namely ‘CausalClass.fromSignal’
In the first argument of ‘CausalRender.run’, namely
‘(CausalClass.fromSignal . sig)’
In a stmt of a 'do' block:
proc <- CausalRender.run (CausalClass.fromSignal . sig)
~~~~
If I add `import qualified Synthesizer.LLVM.Causal.Process ()` then the error goes away. However, the import should not be necessary, because the module imports `Synthesizer.LLVM.Generator.Signal` and this in turn imports `Synthesizer.LLVM.Causal.Private` which contains the required instance. This instance is not even orphan.
## Steps to reproduce
You need some unreleased versions of dependent packages for reproduction:
* https://hackage.haskell.org/package/llvm-tf-12.1/candidate
* https://hackage.haskell.org/package/llvm-extra-0.11/candidate
* https://hackage.haskell.org/package/llvm-dsl-0.1/candidate
* https://hackage.haskell.org/package/synthesizer-core-0.8.3/candidate
* https://hackage.haskell.org/package/synthesizer-llvm-1.0/candidate
You should also respect the building hints of
https://hackage.haskell.org/package/llvm-ffi
e.g. manually provide the paths to libLLVM.so and the LLVM C-header files.
Then you can compile with
~~~~
synthesizer-llvm$ PATH=/usr/local/ghc/9.4.4/bin:$PATH cabal-3.8 build all --enable-tests --disable-optimization --disable-documentation
~~~~
## Environment
* GHC version used: 9.4
In GHC before 9.4 this works.9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/22519head.hackage: package "what4" no longer compiles2023-02-15T22:36:28ZBryan Rbryan@haskell.foundationhead.hackage: package "what4" no longer compilesSee also #22663
Triggers error GHC-18872
First occurrence on 27 November: https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1245011
```
src/What4/Interface.hs:2593:3: error: [GHC-18872]
• Couldn't match representation of type: IO (S...See also #22663
Triggers error GHC-18872
First occurrence on 27 November: https://gitlab.haskell.org/ghc/head.hackage/-/jobs/1245011
```
src/What4/Interface.hs:2593:3: error: [GHC-18872]
• Couldn't match representation of type: IO (SymBV' sym (n * w))
with that of: IO (SymExpr sym (BaseBVType (n * w)))
arising from a use of ‘coerce’
The data constructor ‘GHC.Types.IO’ of newtype ‘IO’ is not in scope
src/What4/Interface.hs:2611:3: error: [GHC-18872]
• Couldn't match representation of type: IO (Vector.Vector n (SymBV' sym w))
with that of: IO (Vector.Vector n (SymExpr sym (BaseBVType w)))
arising from a use of ‘coerce’
The data constructor ‘GHC.Types.IO’ of newtype ‘IO’ is not in scope
```9.6.1