chore: Upgrade to GHC 9.4.5.

[dhess]

Also, we do the following:

• Upgrade to fourmolu 0.12.0.0 and tell it not to put parens around
  standalone unary constraints, for compatibility with hlint.

• Run a formatting pass to conform to fourmolu's new formatting.

• Build HLS from source. It doesn't currently build as a haskell.nix
  tool with GHC 9.4.5, and we need to build it from git, anyway, in
  order to get support for fourmolu 0.12.0.0.

• Disable weeder, which doesn't currently build as a haskell.nix tool
  with GHC 9.4.5, and also fails to build on aarch64-darwin.

• Remove hie.yaml, as HLS once again seems able to operate without it.

Note: the definition of type (<=) changed in ghc-9.4 such that it
uses its arguments twice each. Thus instance x <= y => C x y where ... is rejected, since the constraint is a type synonym which expands
to something like instance Assert (x <=? y) (LeErrMsg x y) => C x y where and this fails the Paterson Conditions:

https://downloads.haskell.org/ghc/9.4.4/docs/users_guide/exts/instances.html#instance-termination-rules

Using UndecidableInstances lifts these restrictions, satisfying GHC.

[brprice]

I think we are failing to build because of haskell/haskell-language-server#3427 (which was fixed for hls-1.9.0.0 and closed, but then happened again for hls-1.9.1.0, and has had recent activity). Hopefully this can get fixed upstream/with a hackage revision.

I've pushed a commit reverting to hls-1.9.0.0 to see if CI gets further

(This does not bite us with ghc-9.2 since haskell.nix disables the problematic plugin for specific ghc versions: https://github.com/input-output-hk/haskell.nix/blob/cedc461a69179a18f75158fbb3045d21ebbfabc6/modules/hackage-quirks.nix#L66)

[brprice]

Strangely, the fourmolu build seems to be segfaulting when linking on aarch64-darwin

building '/nix/store/fymqbrsz19ba5ll959ax5pycvl4slx30-fourmolu-exe-fourmolu-0.10.1.0.drv' on 'ssh://[email protected]'...
copying 0 paths...
unpacking sources
unpacking source archive /nix/store/7f87vryyanlakbn954xai6bpgnqs3lkz-fourmolu-0.10.1.0-src
source root is fourmolu-0.10.1.0-src
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
Configure flags:
--prefix=/nix/store/kc73a42w6ss5afz36ii5y7scr2lq1mxb-fourmolu-exe-fourmolu-0.10.1.0 exe:fourmolu --package-db=clear --package-db=/nix/store/r82ry8c4jmv6gl0xdgk6p6ws9y88ryzw-fourmolu-exe-fourmolu-0.10.1.0-config/lib/ghc-9.4.4/lib/package.conf.d --flags=-dev --flags=fixity-th --exact-configuration --dependency=containers=containers-0.6.6-5tshGsKbEkxHx9P3RxDZvl --dependency=filepath=filepath-1.4.2.2-2dBPCGMC0STHt0FAZCZosY --dependency=ghc-lib-parser=ghc-lib-parser-9.4.4.20221225-A9vYDF1wF2vBNI1nMvCw3Z --dependency=gitrev=gitrev-1.3.1-AFhxhJKYBi57ODPIug2ZQH --dependency=optparse-applicative=optparse-applicative-0.17.0.0-7amx3mRua4vI59PxtIvaPP --dependency=text=text-2.0.1-GtxZK3YcoaA7wPoCv96bk6 --dependency=directory=directory-1.3.7.1-CsNI1TMvg1E6R3GFaeiEFz --dependency=yaml=yaml-0.11.11.0-FOjerCwINW8BNRDxrQFML2 --dependency=fourmolu=fourmolu-0.10.1.0-DEhVQ7YyJm1A7dYVHB9cva --dependency=array=array-0.5.4.0 --dependency=base=base-4.17.0.0 --dependency=deepseq=deepseq-1.4.8.0 --dependency=ghc-bignum=ghc-bignum-1.3 --dependency=ghc-boot-th=ghc-boot-th-9.4.4 --dependency=ghc-prim=ghc-prim-0.9.0 --dependency=integer-gmp=integer-gmp-1.1 --dependency=pretty=pretty-1.1.3.6 --dependency=rts=rts-1.0.2 --dependency=system-cxx-std-lib=system-cxx-std-lib-1.0 --dependency=template-haskell=template-haskell-2.19.0.0 --with-ghc=ghc --with-ghc-pkg=ghc-pkg --with-hsc2hs=hsc2hs --with-gcc=cc --with-ar=ar --with-strip=strip --disable-executable-stripping --disable-library-stripping --disable-library-profiling --disable-profiling --enable-static --enable-shared --disable-coverage --enable-library-for-ghci --datadir=/nix/store/irvnd9hvd6iw9d0fb20hzj9v0lr3wx0j-fourmolu-exe-fourmolu-0.10.1.0-data/share/ghc-9.4.4 

Configuring executable 'fourmolu' for fourmolu-0.10.1.0..
building
Preprocessing executable 'fourmolu' for fourmolu-0.10.1.0..
Building executable 'fourmolu' for fourmolu-0.10.1.0..
[1 of 2] Compiling Paths_fourmolu   ( dist/build/fourmolu/autogen/Paths_fourmolu.hs, dist/build/fourmolu/fourmolu-tmp/Paths_fourmolu.o, dist/build/fourmolu/fourmolu-tmp/Paths_fourmolu.dyn_o )
[2 of 2] Compiling Main             ( app/Main.hs, dist/build/fourmolu/fourmolu-tmp/Main.o, dist/build/fourmolu/fourmolu-tmp/Main.dyn_o )
[3 of 3] Linking dist/build/fourmolu/fourmolu
/nix/store/vlh4h7796gzks5kwlcvmcgr2ldp1xz7q-clang-wrapper-11.1.0/bin/ld: line 256: 86021 Segmentation fault: 11  /nix/store/amx2qmb58zhcvj5ir882jbbsc5hbmnf3-cctools-binutils-darwin-973.0.1/bin/ld ${extraBefore+"${extraBefore[@]}"} ${params+"${params[@]}"} ${extraAfter+"${extraAfter[@]}"}
clang-11: error: linker command failed with exit code 139 (use -v to see invocation)
ghc-9.4.4: `clang' failed in phase `Linker'. (Exit code: 139)

We have seen segfaults building fourmolu on this platform before: #694 (comment)

[dhess]

The fourmolu thing happens occasionally, at random, and it's usually fixable with just a retry. I have no idea what's causing it. It's been happening across multiple versions of haskell.nix, fourmolu, and (if I recall correctly) ghc.

[brprice]

The fourmolu thing happens occasionally, at random, and it's usually fixable with just a retry.

This time seems more persistent. I have retried multiple times, and the failure is always the same. Perhaps we finally have a reproducer? (Though I notice that it always tries to build on mac-builder-c, so maybe there is something odd with that machine?)

[dhess]

No, it's happening on the other Mac builder, and now on my own Mac, as well.

I think we should just cut our losses and switch to ormolu. We can't afford to spend time trying to root cause or fix this, especially given that it's not affecting any other package or platform, it appears to have nothing to do with Haskell or GHC, and switching won't have a material impact on the code base. It would be purely cosmetic.

[georgefst]

I'd be surprised if Ormolu doesn't exhibit the same issue, since I can't think of anything relevant that Fourmolu changes.

Is this related to NixOS/nixpkgs#196781?

[dhess]

A very similar issue was reported upstream: fourmolu/fourmolu#238

@georgefst You marked this as completed, but it doesn't appear it was ever properly addressed in fourmolu, as that issue was filedin September 2022 and on v0.8.2.0 (we're using v0.10.1.0, the latest). Did you close the issue because it was supposed to have been resolved upstream?

[dhess]

Also, nixpkgs worked around the issue reported above (which may or may not be the same issue we're seeing here) by disabling fixity-th: https://github.com/NixOS/nixpkgs/pull/196781/files

Should we try the same?

[dhess]

I'd be surprised if Ormolu doesn't exhibit the same issue, since I can't think of anything relevant that Fourmolu changes.

Yes, possibly. I didn't realize fourmolu was so closely related. But then if the issue we're encountering here is the same one that was reported earlier, and Ormolu fixed it here: tweag/ormolu#954

why are we still seeing it in the latest release of fourmolu? Has the Ormolu fix not been incorporated into fourmolu yet?

edit: supposed to have been resolved in HLS as well: haskell/haskell-language-server#3400

[georgefst]

A very similar issue was reported upstream: fourmolu/fourmolu#238. @georgefst You marked this as completed, but it doesn't appear it was ever properly addressed in fourmolu, as that issue was filedin September 2022 and on v0.8.2.0 (we're using v0.10.1.0, the latest).

According to the changelogs (Ormolu, Fourmolu), the problematic fixity-th flag was disabled in Ormolu 0.5.2, but Fourmolu's last release, 0.10.1, is based on Ormolu 0.5.1, despite 0.5.2 being merged in to Fourmolu over two months ago. That's pretty poor - we've never lagged this far behind before. Though as it happens, Brandon and I had agreed to make a release this coming weekend. When we do that, I'll also have a chat about how we should in general release with upstream fixes more promptly.

Did you close the issue because it was supposed to have been resolved upstream?

Yes, although maybe I shouldn't have done so until the upstream fix was merged.

Also, nixpkgs worked around the issue reported above (which may or may not be the same issue we're seeing here) by disabling fixity-th: https://github.com/NixOS/nixpkgs/pull/196781/files

Yes, that should fix it, and might be the simplest thing in the short-term.

[dhess]

OK, thanks. We can chill a bit longer and wait for the new fourmolu release.

In the meantime, there's a strange Weeder issue that only appears to affect aarch64-darwin. (Sort of like well-typed/cborg#309, but weirdly that issue was reported for 32-bit platforms.)

[brprice]

In the meantime, there's a strange Weeder issue that only appears to affect aarch64-darwin. (Sort of like well-typed/cborg#309, but weirdly that issue was reported for 32-bit platforms.)

Actually, it is a cborg issue, I believe well-typed/cborg#304 or well-typed/cborg#307 should fix it. I have pushed a commit grabbing the second one of these in cabal.project -- let's see what CI says (I have no access to apple silicon to test locally) EDIT: urgh, that won't work, as cborg is pulled in via weeder, which is via some other flake output and not part of our package.

[dhess]

I think that once fourmolu is ready, I will move ahead with the GHC 9.4.4 upgrade and just drop Weeder until those issues are resolved. It's not a critical part of our test suite.

[brprice]

I think that once fourmolu is ready, I will move ahead with the GHC 9.4.4 upgrade and just drop Weeder until those issues are resolved. It's not a critical part of our test suite.

Sounds good to me. One possible refinement would be to gate the weeder check on x86_64. Having said that, we could even do this for fourmolu as well (though since a new release should be imminent, it's probably better to wait)

[brprice]

I think we are failing to build because of haskell/haskell-language-server#3427 (which was fixed for hls-1.9.0.0 and closed, but then happened again for hls-1.9.1.0, and has had recent activity). Hopefully this can get fixed upstream/with a hackage revision.

I've pushed a commit reverting to hls-1.9.0.0 to see if CI gets further

(This does not bite us with ghc-9.2 since haskell.nix disables the problematic plugin for specific ghc versions: https://github.com/input-output-hk/haskell.nix/blob/cedc461a69179a18f75158fbb3045d21ebbfabc6/modules/hackage-quirks.nix#L66)

haskell/haskell-language-server#3427 (comment) implies that hls-1.9.1.0 should now work (at least, after haskell.nix picks up the new revision from hackage), so I expect we can just drop that commit.

[brprice]

I think we are failing to build because of haskell/haskell-language-server#3427 (which was fixed for hls-1.9.0.0 and closed, but then happened again for hls-1.9.1.0, and has had recent activity). Hopefully this can get fixed upstream/with a hackage revision.

This seems to have been fixed as of hls hackages revision 1.

I've pushed a commit reverting to hls-1.9.0.0 to see if CI gets further

I suspect we can drop this commit when we bump haskell.nix

[dhess]

This appears to be ready to go, finally. We have to build HLS from git, and we lose weeder support, at least for now. HLS seems to work for me in Emacs, but note that I did need to blow away my ~/.cache/hie-bios as HLS seemed to be using the cache that was built with ghc-9.2.7, for some reason.

[dhess]

I'll wait for the saturated constructor PRs, then merge this. Then I'll move on to GHC 9.6.1.