lspitzner / brittany

haskell source code formatter
GNU Affero General Public License v3.0
692 stars 72 forks source link

Build with ghc-9.2.1 #366

Open mxxun opened 2 years ago

mxxun commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

That sounds reasonable to me.

pepeiborra commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Relevant ghc-exactprint issue:

The consensus seems to be that ghc-exactprint would need to be split up more before migrating to ghc-lib; see: https://github.com/alanz/ghc-exactprint/issues/93#issuecomment-867167997