Cleanup CPPs, remove support for GHC 9.4

[dschrempf]

Closes #4529.

Also,

• update flake lock
• some girl scout changes while trying to understand some code

[fendor]

Fyi, in the biweekly HLS meeting, we have discussed to not drop support for 9.4 until the next release 2.11.0.0 which will happen once GHC 9.10.2 is released.

Afterwards, we will drop 9.4 support.

[dschrempf]

Thanks for the information! I leave this PR in draft mode for now, but feel free to close it, and I can reopen in due time!

[michaelpj]

btw you might find this useful: https://www.michaelpj.com/blog/2023/11/20/cpp-partial-evaluation.html

[fendor]

@dschrempf since we released HLS 2.11, we are ready to drop support for GHC 9.4 :)

[dschrempf]

@fendor I have removed #if MIN_VERSION_ghc(9,4,0) statements, but there are a lot of #if MIN_VERSION_ghc(9,5,0) statement left. Also, this is a bit of a nightmare because stylish-haskell fails to parse some of the amended files having many CPP statements. I had to rearrange two already.

Also, the Nix CI fails for MacOS for a reasons I don't understand. I have to investigate. I do not have more time now, maybe I get to it tomorrow. If you take over, please let me know!

Cheers!

EDIT: Ad Nix failure for MacOS. I am not sure if we should test this in CI.

[dschrempf]

I tackled all MIN_VERSION_ghc(9,5,...) macros, as well as GLASGOW_HASKELL macros related to GHC 9.4. I also removed GHC 9.4 from the tests.

There is one question left in the tests. At a point we expect "ghc94.expected" (I didn't undertand this, maybe it was wrong in the first place?). I will highlight the code change with a comment.

Also there is a lot more macros a'la MIN_VERSION_ghc(9,6,...) which we also can remove by now, but I don't have any energy left ^^. This PR is HUGE already.

Depending on how the CI will go: I think we should merge this soon, conflicts will be really ugly.

[dschrempf]

NOTE: I remove macOS from the Nix CI.

[dschrempf]

I just realized this is PR 4567.

[dschrempf]

Some notes:

• I think stylish-haskell and CPPs do not play well togehter. stylish-haskell seems to ignore conditional CPPs entirely and fails in many cases. How did you deal with this in the past? I had to copy some code into both branches of the conditionals for stylish-haskell to parse the files.

• It is difficult to know which warnings lead to CI errors, and which warnings don't. Do you think it is possible to use the same warning/error configuration for local builds and the CI?

• In general, I think somebody has to clean build HLS and fix warnings. I think some warnings are induced by changes between GHC and base libraries, but even those should be fixed with CPP statements, shouldn't we?

[fendor]

Amazing work, I didn't anticipate this would be so much work! Thank you for taking care of this, it is much appreciated!

[fendor]

I think stylish-haskell and CPPs do not play well togehter.

formatters don't work with CPP in general, we usually just ignore these kinds of errors in the pre-commit job, it is not blocking 🙊 Sorry for not telling you sooner, but I think you improved the overall code base considerably!

It is difficult to know which warnings lead to CI errors

Good point, I think ci runs with -fpedantic, but maybe we should borrow some lingo from javscript and have a flag such as -fci and document that in the user docs?

In general, I think somebody has to clean build HLS and fix warnings.

Making ghcide compile without warnings is a big amount of work with little payoff... Not sure anyone wants to tackle that.