Upgrade Fourmolu to 0.13.1.0

[ad-si]

As requested in fourmolu/fourmolu#357.

Must the nix files also be updated in this PR?

[brandonchinn178]

@joyfulmantis should fourmolu be pinned in stack.yaml? Maybe the HLS build should just always get the latest version of fourmolu available?

[michaelpj]

I think this comment is wrong: fourmolu/fourmolu#357 (comment)

The stack build configuration is not used for anything other than testing. We use cabal to build the binaries. So for some reason cabal is picking an older version of fourmolu in that build. Hard to know why without looking at the build plan. If you want to force a newer version then you should change the bounds in the plugin cabal file to force it!

[michaelpj]

TBH this bound looks far too permissive to me: https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-fourmolu-plugin/hls-fourmolu-plugin.cabal#L35

I'm not sure we gain anything from telling cabal we allow all these versions, in fact we probably want to use the newest major version whenever possible. So I'd probably just change that to ^>= 0.13.

[joyfulmantis]

TBH this bound looks far too permissive to me: https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-fourmolu-plugin/hls-fourmolu-plugin.cabal#L35

I'm not sure we gain anything from telling cabal we allow all these versions, in fact we probably want to use the newest major version whenever possible. So I'd probably just change that to ^>= 0.13.

Yes, as long as the latest version works with all of our ghc versions, there is no reason to support older versions. This to be honest should probably also be done with stylish-haskell and the ormolu plugin, as they both have the same OR dependency on their main library.

[brandonchinn178]

Ok, I can change it to just 0.13. @ad-si feel free to close

[michaelpj]

I guess having wider version bounds lets people who are manually building HLS pick an older version of fourmolu or something, but that's somewhat niche.

[brandonchinn178]

@michaelpj oh HLS builds binaries for multiple versions of GHC, right? So we do need to support multiple versions of fourmolu for each version of GHC fourmolu supports. e.g. I see there's a configuration-ghc-90.nix file, and fourmolu 0.13 won't build for GHC 9.0

[michaelpj]

Right, so we need to keep at least enough of a range to support all the GHC versions we support.

Generally this is a bit awkward: it's not clear that there's an obvious way to ensure that we are generally building with "the latest version of tools that are compatible with our GHC version" or something. I guess we could do

if impl(ghc <9.2)
   build-depends: fourmolu ^>= 0.12
else
   build-depends: fourmolu ^>= 0.13

or something, but that's also a bit ugly.

[July541]

For current, ghc8.10 using fourmolu-0.3.0.0, ghc9.0 and ghc9.2 using fourmolu-0.10.1.0, ghc9.4 and ghc9.6 using fourmolu-0.13.0.0. These depend on which ghc-lib-parser the corresponding ghc is using.

[brandonchinn178]

@July541 Thanks. In the original issue, they were using HLS 2.1.0.0 with GHC 9.4.5, but they still got fourmolu 0.12. Any idea how that happened?

[July541]

Not sure about the details, but we dont' have fourmolu-0.13.0.0 until #3744, maybe it's the HLS compiled before #3744?

And #3744 also added a debug level log about fourmolu version and ormolu version.

[brandonchinn178]

New PR: #3764

[brandonchinn178]

Oh ok so I added 0.13 support in June: July541@c126332

But @joyfulmantis removed it, probably a bad rebase: July541@a918c02#diff-657e190925739b6d16d46aa6956dda0e9de823cbe251a3672c5c6e412945ce5c

[joyfulmantis]

Oh ok so I added 0.13 support in June: July541@c126332

But @joyfulmantis removed it, probably a bad rebase: July541@a918c02#diff-657e190925739b6d16d46aa6956dda0e9de823cbe251a3672c5c6e412945ce5c

Yeah, that must have been a bad rebase. Sorry about that!

[brandonchinn178]

I don't think this is necessary anymore. I removed this line in #3764, and the stack snapshot should just be using whatever version of fourmolu is in the snapshot.

And this snapshot is only used for build; cabal is used to build the release artifacts. I think the PR can just be closed

[michaelpj]

Yep, this is obsolete now