Closed ConnorBaker closed 10 months ago
Fixes the following compilation error I had seen on GHC 9.8 when building with
-XApplicativeDo
Could you possibly elaborate and provide instructions how to reproduce the error please? cabal build all -w ghc-9.8
seems to succeed without a hitch.
I assume this has something to do with https://gitlab.haskell.org/ghc/ghc/-/issues/20630, but I don't know why to enable -XApplicativeDo
in tasty
.
Could you possibly elaborate and provide instructions how to reproduce the error please?
cabal build all -w ghc-9.8
seems to succeed without a hitch.
I ran cabal build lib:tasty --ghc-option="-XApplicativeDo"
from the root of the repository.
I assume this has something to do with https://gitlab.haskell.org/ghc/ghc/-/issues/20630, but I don't know why to enable
-XApplicativeDo
intasty
.
You're right, it does seem to be an instance of that issue!
As for the why of doing this -- I don't really have one. I'm building a project locally which I've split into many packages and I've taken the simple approach of using a cabal.project
to enable aggressive optimizations for all of them with the following:
Per 6.2.4.2. Things to watch out for
Your code should just work as before when
ApplicativeDo
is enabled, provided you use conventionalApplicative
instances.
I thought it was reasonable to do so for all packages, not just my local packages because it shouldn't break anything.
I submitted this PR because I thought tasty shouldn't fail to compile when ApplicativeDo
is enabled.
You're right that this looks like a bug in GHC itself. As such, I'll close this PR.
Unrelated, but any idea if it would be appropriate to amend https://gitlab.haskell.org/ghc/ghc/-/blob/master/docs/users_guide/exts/applicative_do.rst to mention https://gitlab.haskell.org/ghc/ghc/-/issues/20630?
Unrelated, but any idea if it would be appropriate to amend https://gitlab.haskell.org/ghc/ghc/-/blob/master/docs/users_guide/exts/applicative_do.rst to mention https://gitlab.haskell.org/ghc/ghc/-/issues/20630?
I think it's a good idea, yes.
FWIW I seriously doubt that enabling -XApplicativeDo
has any measurable effect on performance for libraries, which were not specifically designed to use {-# LANGUAGE ApplicativeDo #-}
.
Fixes the following compilation error I had seen on GHC 9.8 when building with
-XApplicativeDo
: