Any chance this could be fixed in the 9.4 branch? I'm running into what looks like this problem too and won't be able to use 9.4 otherwise.
For what it's worth I've now managed to jump straight to 9.6.1, so I don't personally need a fix backported to 9.4 any more.
9.4.4 came out only a day or so after I requested the backport, and I am fairly sure it didn't make it in there. So I guess it'll depend on 9.4.5 happening (and for it to be judged worthy of inclusion).
BTW just from reading descriptions, Allow let
just before pure/return in ApplicativeDo might be more likely to be the responsible commit? (EDIT but now I've read the diffs I'm really not sure!)
Are you one of those "eager users"?
I'm not sure :-) I was experimenting with using it to instrument some code, but my latest attempts at that instrumentation were taking a slightly different approach so it was on mainly because I hadn't got round to turning it off. But I do find the concept attractive and might come back to using it in anger again.
Thanks for pointing out -ddump-rn
btw. I hadn't managed to find a tracing option that would help me see the desugaring prior to type-checking.
There's a compilation regression between GHC 9.4.3 and GHC 9.6.1-alpha2 which seems to be some interaction between ApplicativeDo
and polymorphic arguments.
Cut down example below, which compiles in GHC 9.4.3 but fails in 9.6. It compiles fine in GHC 9.6 if I do any of:
ApplicativeDo
do
pure ()
go
.It may be related to the ApplicativeDo
desugaring itself as I've tried and failed to reproduce the regression with manually desugaring. I also later ran into another example of a regression in an applicative do block, this time with implicit parameters, that was also fixed by reorganising the code; I can also turn that into a test case if wanted.
Now that I understand the triggers I can probably work around it fairly easily in my real code, but I thought it may still be worth investigating as I can't spot any mention in the migration guide or other issues.
{-# LANGUAGE ApplicativeDo #-}
module X where
x :: Maybe ()
x = do
pure ()
let go = Nothing
f go
f :: (forall p . Maybe p) -> Maybe ()
f _ = Nothing
With GHC 9.4.3 this compiles fine.
With GHC 9.6.0-alpha2 I get:
X.hs:8:5: error: [GHC-46956]
• Couldn't match type ‘a0’ with ‘p’
Expected: Maybe p
Actual: Maybe a0
because type variable ‘p’ would escape its scope
This (rigid, skolem) type variable is bound by
a type expected by the context:
forall p. Maybe p
at X.hs:8:5-6
• In the first argument of ‘f’, namely ‘go’
In a stmt of a 'do' block: f go
In the expression:
do pure ()
let go = Nothing
f go
• Relevant bindings include go :: Maybe a0 (bound at X.hs:7:7)
|
8 | f go
| ^^
I'm not sure. Maybe it should work in GHC 9.6? Maybe my code is wrong and I just get lucky with earlier GHCs?
Any chance this could be fixed in the 9.4 branch? I'm running into what looks like this problem too and won't be able to use 9.4 otherwise. For what it's worth I reduced it to this smaller looking test case (works in 9.2, breaks in 9.4), but haven't double-checked it against the fix.
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE UndecidableSuperClasses #-}
module HKD where
class All xs => All xs
class All xs => AllZip xs
test :: forall xs. AllZip xs => ()
test = ()
Thanks! That's got me past that point. (I'm actually building for GHC 9.0.2 which also requires --allow-newer=hashable:ghc-bignum
and who knows what else, but it's at least trying to build it now.)
I don't know whether to leave this open or not given there's an easy workaround but it doesn't work by default, I'll leave it to you :-)
With v0.1.17.4, I get this error:
[__1] trying: base-4.15.0.0/installed-4.15.0.0 (dependency of ghcide)
[__2] trying: hls-brittany-plugin-1.0.1.1 (user goal)
[__3] next goal: brittany (dependency of hls-brittany-plugin)
[__3] rejecting: brittany-0.13.1.2 (conflict:
base==4.15.0.0/installed-4.15.0.0, brittany => base>=4.12 && <4.15)
[__3] skipping: brittany-0.13.1.1, brittany-0.13.1.0, brittany-0.13.0.0,
brittany-0.12.2.0, brittany-0.12.1.1, brittany-0.12.1.0, brittany-0.12.0.0,
brittany-0.11.0.0, brittany-0.10.0.0, brittany-0.9.0.1, brittany-0.9.0.0,
brittany-0.8.0.3, brittany-0.8.0.2 (has the same characteristics that caused
the previous version to fail: excludes 'base' version 4.15.0.0)
[__3] fail (backjumping, conflict set: base, brittany, hls-brittany-plugin)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, brittany, ghcide,
hls-brittany-plugin
Brittany doesn't currently work with GHC 9.0 so the error is expected if we try to build it, but haskell-language-server.cabal
explicitly disables it for GHC >= 9.0.1. I've also tried -- -f-brittany
just in case, but it didn't help.
Having looked at the build tree with --keep=always
, I believe it's because there's a cabal.project
which explicitly lists ./plugins/hls-brittany-plugin
. I haven't yet dug into where that's coming from.