Build with ghc-9.2.1

[mxxun]

Early-stage PR, to check whether this kind of copious CPP is agreeable, and to share partial results if those are useful.

My intention here is to build with 9.0.* and 9.2.* series both, as 9.0.3 might well have breaking changes, and in this case haskell language server's brittany plugin will want a ghc-9.0.3-compatible brittany.

(Possibly brittany should have 0.14.* series dedicated to ghc-9.0.*, and a separate 0.15.* series for ghc-9.2.* support?)

[tfausak]

Wow, awesome work!

I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS. I like your suggestion of maintaining separate versions for different versions of GHC. For instance 0.13.x supports GHC 8.10, 0.14.x supports 9.0, and 0.15.x could support 9.2.

I'm not sure how practical it is for Brittany, but separate conditionally-included modules are more palatable to me than CPP. For example my Splint project has different modules for GHC <= 8.8, 8.10, and >= 9.0: https://github.com/tfausak/splint/blob/f06756e738813f9a8112237a217f57d5bc588eaa/splint.cabal#L48

[mxxun]

Aha; what do you think of putting a ghc-9.0.x branch onto the current master tip, dedicating master onward to ghc-9.2.1, and patching the 9.0.x branch if and when that becomes a problem? This way there'd be no overhead due to CPP or massive duplication, at the possibly-small cost of no updates/backports on the older branch.

[tfausak]

That sounds reasonable to me.

[pepeiborra]

I would prefer to support only one major version of GHC at a time. Honestly that's really all I have the bandwidth to do. It's unfortunate that doing that makes things worse for HLS.

The solution to this conundrum is probaby: migrate to ghc-lib-parser-9.2, which is guaranteed to build with ghc 8.10, 9.0, 9.2 and most probably will carry on to 9.4 and a few more major versions of ghc.

The best part is that you don't need to do much other than replacing the ghc dependency with a ghc-lib-parser dependency.

[sergv]

The solution to this conundrum is probaby: migrate to ghc-lib-parser-9.2

Just a note regarding this migration: brittany heavily relies on ghc-exactprint which doesn't depend on ghc-lib-parser yet. Haven't researched whether there are plans to do so (seems reasonable that it could happen at some point though). If ghc-exactprint migrates then for brittany it would be easy to migrate indeed.

[PiDelport]

Relevant ghc-exactprint issue:

• Migrate to ghc-lib alanz/ghc-exactprint#93

The consensus seems to be that ghc-exactprint would need to be split up more before migrating to ghc-lib; see: alanz/ghc-exactprint#93 (comment)