Upgrade to ghc 9.10

[jhrcek]

Trying to make things work with GHC 9.10, for the purpose of including stylish-haskell in haskell language server (haskell/haskell-language-server#4233)

[jhrcek]

Status update: this is functionally complete, but waiting for ghc 9.10 to become available in stackage snapshot so I can upgrade stack ci config

[jhrcek]

Hello @jaspervdj
could you please check this PR?
The only thing missing I think is updating stack CI config to use ghc 9.10 based resolver.
But in in stackage I see stylish-haskell has been disabled because it doesn't support ghc 9.10 (see commercialhaskell/stackage#7414), so it seems like a bit of a chicken-egg problem.
Would it make sense to you to 1) disable stack ci temporarily and then 2) release new version of stylish-haskell with 9.10 support to hackage so we could enable it with ghc 9.10 in hls?

[jaspervdj]

Thanks!

[jaspervdj]

I am addressing the broken CI here: #484

IMO we should not switch the stack CI over to use the newest GHC version (yet), as long as it's covered by cabal we're good. This avoids the chicken-and-egg problem.

[jhrcek]

Sounds great. Feel free to merge your PR and I'll rebase this PR on top, removing CI changes from this one.

[jhrcek]

FYI removing 9.4 from CI, because its associated base 4.17 is out of bounds for ghc-lib-parser, which requires base >= 4.18.

[michaelpj]

Can we make progress on this now?

[jhrcek]

@michaelpj The current state is that ~10/278 tests are still failing with ghc 9.10.
I remembered we were trying to fix them with Alan Z during zurihac but we gave up, because Alan realized something fundamental is missing in EP annotations within ghc said he'd try to get this fixed for the next 9.10 patch release.

[Miezhiko]

please do 9.12

[Mikolaj]

get this fixed for the next 9.10 patch release

Is it fixed so that we can start badgering GHC HQ for GHC 9.10.2? Or is it fixed in 9.12.1 maybe or will GHC 9.12.2 have it?

Pretty please. :)

[jhrcek]

Hey folks, sorry I completely forgot about this PR.
I rebased it on main, but there are still 10 failing tests which I'm not sure whether they're fixable using 9.10. ghc apis.
All of the failures look like haddock comments disappearing from certain places in the AST.

I will take a stab at trying to migrate to ghc 9.12, but it might take some time for me to get to it.

Is it fixed so that we can start badgering GHC HQ for GHC 9.10.2?

I'm not sure about that. Probably Alan Zimmerman would know whether he managed to get in his fixes to exactprint in 9.10 branch. But at this point it might make more sense to switch to 9.12.

[Miezhiko]

on 9.12 getting this, any tips on how to patch?

[ 4 of 26] Compiling Language.Haskell.Stylish.GHC ( lib/Language/Haskell/Stylish/GHC.hs, dist/build/Language/Haskell/Stylish/GHC.o, dist/build/Language/Haskel
l/Stylish/GHC.dyn_o )
lib/Language/Haskell/Stylish/GHC.hs:83:15: error: [GHC-76037]
    Not in scope: data constructor ‘GHC.EpAnnNotUsed’
    Note: Neither ‘GHC.Driver.Ppr’, ‘GHC.Driver.Session’, ‘GHC.Hs’,
                  ‘GHC.Types.SrcLoc’ nor ‘GHC.Utils.Outputable’ export ‘EpAnnNotUsed’.
   |
83 | epAnnComments GHC.EpAnnNotUsed = []
   |               ^^^^^^^^^^^^^^^^

lib/Language/Haskell/Stylish/GHC.hs:90:29: error: [GHC-76037]
    Not in scope: ‘GHC.anchor’
    Note: Neither ‘GHC.Driver.Ppr’, ‘GHC.Driver.Session’, ‘GHC.Hs’,
                  ‘GHC.Types.SrcLoc’ nor ‘GHC.Utils.Outputable’ export ‘anchor’.
    Suggested fix:
      Perhaps use one of these:
        ‘GHC.char’ (imported from GHC.Utils.Outputable),
        record field of AnnList ‘GHC.al_anchor’ (imported from GHC.Hs)
   |
90 | priorAndFollowing = sortOn (GHC.anchor . GHC.getLoc) . \case
   |                             ^^^^^^^^^^

[jhrcek]

I'm afraid there won't be any easy way, because I expect there to be quite a few changes in GHC Annotation apis from 9.10 to 9.12.

How I would go about it:

• pull up the list of commits authored by Alan Zimmerman in GHC repo (to find which things were removed/replaced and why) - Alan is the main person pushing forward the development of exactprint machinery in GHC.
• with https://hackage.haskell.org/package/ghc-9.10.1 and https://hackage.haskell.org/package/ghc-9.12.1 documentation open side by side:

1. fix all the compiler errors (remove pattern matches for no longer existing constructors, etc)
2. make all the tests pass (I know, easier said than done 😅 )

For example: the anchor function was removed here: https://gitlab.haskell.org/ghc/ghc/-/commit/0bc94360908011167284ee4c283c343350cbba78#b1092d2df4ded3655524830252278016d6aa5afd_26_26, presumably because you can now use epaLocationRealSrcSpan :: EpaLocation' a -> RealSrcSpan to get the same info etc.

[Miezhiko]

well, that's sad

[GuillaumedeVolpiano]

@jhrcek : this commit fixes the disappearing comments issue. There is still one test failing, though.

[jhrcek]

@GuillaumedeVolpiano Nice that you were able to find a workaround!
Regarding the test failure (I see | being printed in front of the first constructor instead of =)
It seems it could have something to do with this line under your workaround:

stylish-haskell/lib/Language/Haskell/Stylish/Step/Data.hs

Line 183 in 29e933d

putText $ if firstGroup && firstItem then "=" else "|"

Could you please check the logic surrounding this piece to understand where this behavior is coming from?

[GuillaumedeVolpiano]

Yes I think the issue is that the first constructor is somehow not registered as the first if there is a comment before.

Looking into it

[GuillaumedeVolpiano]

@jhrcek So, to get into the nitty gritty: for some reason, we were capturing the haddock comment before the data declaration as it's own comment group, which interfered with the logic of the printing part. Filtering it out when building the DataDecl rather than when printing it did the trick. Add my commit to your commit and you're good to go. At least on my side, it passes all tests.

[jhrcek]

Awesome, thanks! I think we can go with your PR as well. Otherwise I will update my PR by copying the approach from your PR tomorrow.

[GuillaumedeVolpiano]

Awesome, thanks! I think we can go with your PR as well. Otherwise I will update my PR by copying the approach from your PR tomorrow.

Basically it depends on which version of ghc_lib_parser you want to depend on.

If you're interested I have a branch relying on the CPP Pragma which seems to work with ghc-lib-parser-9.8+ (the gentoo branch in my fork)

[jhrcek]

I agree it would make sense to make the project compilable with both ghc 9.10 and 9.12.
I borrowed the workaround from your PR (simplified it a bit) which made the test pass.
Not sure what the next steps should be.

Maybe we could merge this PR, release 9.10 compatible version of the lib to hackage,
then merge your PR and release another version compatible with 9.12?

[GuillaumedeVolpiano]

Your repo, your choice, but indeed, making two releases would be my advice, for what it’s worth. Once you’ve merged this, I’ll rebase my last commit over the new source and we should be good to merge and make a second release.

Edit: the code is cleaner indeed ;)

[jhrcek]

This is not my repo, I only contributed few compatibility fixes for previous ghc versions 😄
The main person behind this repo is @jaspervdj who originally implemented the tool I think.
Jasper, could you please comment on what you think is the best approach (release 2 versions with ghc 9.10 / 9.12 compatibility or just go with the latest ghc)?
Also this PR should be ready for review.