CI: add GHC 9.10

[ulysses4ever]

Please read Github PR Conventions and then fill in one of these two templates.

---

Template Β: This PR does not modify cabal behaviour (documentation, tests, refactoring, etc.)

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[ulysses4ever]

Made this mistake again: opened PR against upstream whereas it was meant to be a local experiment. Oh well, will be spamming you guys...

[ulysses4ever]

Strange test failure with mismatching hashes... https://github.com/haskell/cabal/actions/runs/8777261860/job/24081967765?pr=9914#step:18:1433 dealt with in #9915

[ulysses4ever]

Looks like the first actual issue with 9.10: https://github.com/haskell/cabal/actions/runs/8786524687/job/24109614580?pr=9914#step:17:293 Something around how the CPP symbols get passed.

[geekosaur]

@bgamari, @mpickering, @alt-romes: this looks to me like something has changed in ghc, since the ghc invocation looks correct to me?

[geekosaur]

@ulysses4ever, can you arrange for ghc to be run at a high enough verbosity that it tells us what gcc command line it's using? (I don't know how hard this will be in the test suite.)

[geekosaur]

I'm trying to build this locally so I can try bisecting ghc, and getting an error:

hilfy «cabal:ci-ghc-9.10¤@1ad7e5b58» Z$ cabal build all -w ~/Sources/ghc/_build/stage1/bin/ghc
Warning: this is a debug build of cabal-install with assertions enabled.
Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.13.0.0 supports
'ghc' version < 9.10): /home/allbery/Sources/ghc/_build/stage1/bin/ghc is
version 9.11.20240422
Resolving dependencies...
Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: cabal-testsuite-3 (user goal)
[__1] next goal: cabal-testsuite:setup.Cabal (dependency of cabal-testsuite)
[__1] rejecting: cabal-testsuite:setup.Cabal; 3.11.0.0, 3.10.3.0, 3.10.2.1, 3.10.2.0, 3.10.1.0, 3.8.1.0, 3.6.3.0, 3.6.2.0, 3.6.1.0, 3.6.0.0, 3.4.1.0, 3.4.0.0, 3.2.1.0, 3.2.0.0, 3.0.2.0, 3.0.1.0, 3.0.0.0, 2.4.1.0, 2.4.0.1, 2.4.0.0, 2.2.0.1, 2.2.0.0, 2.0.1.1, 2.0.1.0, 2.0.0.2, 1.24.2.0, 1.24.0.0, 1.22.8.0, 1.22.7.0, 1.22.6.0, 1.22.5.0, 1.22.4.0, 1.22.3.0, 1.22.2.0, 1.22.1.1, 1.22.1.0, 1.22.0.0, 1.20.0.4, 1.20.0.3, 1.20.0.2, 1.20.0.1, 1.20.0.0, 1.18.1.7, 1.18.1.6, 1.18.1.5, 1.18.1.4, 1.18.1.3, 1.18.1.2, 1.18.1.1, 1.18.1, 1.18.0, 1.16.0.3, 1.16.0.2, 1.16.0.1, 1.16.0, 1.14.0, 1.12.0, 1.10.2.0, 1.10.1.0, 1.10.0.0, 1.8.0.6, 1.8.0.4, 1.8.0.2, 1.6.0.3, 1.6.0.2, 1.6.0.1, 1.4.0.2, 1.4.0.1, 1.4.0.0, 1.2.4.0, 1.2.3.0, 1.2.2.0, 1.2.1, 1.1.6, 1.24.1.0 (constraint from minimum version of Cabal used by Setup.hs requires >=3.12)
[__1] fail (backjumping, conflict set: cabal-testsuite, cabal-testsuite:setup.Cabal)
After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: cabal-testsuite:setup.Cabal, cabal-testsuite

zsh: exit 1     cabal build all -w ~/Sources/ghc/_build/stage1/bin/ghc

As far as I can tell, this is pretty much what CI is doing, but there it doesn't complain about the Cabal version used by Setup.hs. Am I missing something?

ETA: it appears I have to use a released cabal-install to build it. Have to figure out how that affects the bisect.

[ulysses4ever]

@geekosaur could you try a released version of GHC? Actually, exactly the alpha3 of GHC 9.10. Custom setups are known to be sensitive to this sort of thing.

[ulysses4ever]

Oh, yeah, you're probably hitting #8133

[geekosaur]

This is exactly ghc-9.10-alpha3, but I'll need it to work for random commits in order to try to bisect it.

[geekosaur]

Okay, I have confirmed that the test fails on ghc master and ghc-9.10 branches locally, and will bisect from c18658545ce45254a4679c13de5dcc56a4c8373f after verifying that that commit (base of ghc-9.8 branch) succeeds (that is, that my bisect script is fully working). Probably have to leave it running overnight.

[geekosaur]

commit 8ff3134ed4aa323b0199ad683f72165e51a59ab6
Author: Matthew Pickering <[email protected]>
Date:   Tue Sep 15 07:42:18 2020 +0100

    Revert "Pass preprocessor options to C compiler when building foreign C files (#16737)"
    
    This reverts commit 1c18d3b41f897f34a93669edaebe6069f319f9e2.
    
    `-optP` should pass options to the preprocessor, that might be a very
    different program to the C compiler, so passing the options to the C
    compiler is likely to result in `-optP` being useless.
    
    Fixes #17185 and #21291

I think this means our test is testing incorrect behavior? Or possibly the fix above is overly extensive.

[ulysses4ever]

@geekosaur amazing work, thank you! I think the test should be fixed.

[ulysses4ever]

@sergv a test you added in #7900 is failing with GHC 9.10 because they changed how CPP options meant for the C compiler propagate (you can't pass them via -optP anymore, only -optc works), according to the GHC commit.

I'm not sure why -D is affected as well, but judging by the output of the failing test, it is. The current documentation of -D looks like it's meant for preprocessor running on Haskell files, so it makes sense that it fails for C sources.

The GHC change was done in response to a GHC issue from @andreasabel so maybe he or you want to suggest how to fix the text: should we remove all the failing symbols (NOERROR1,3,4) or some of them can be adjusted to reflect the changes in 9.10.

[ulysses4ever]

Hooray: the first time CI is green! 🎉

[Mikolaj]

Thank you.

[ulysses4ever]

This has been sitting for a while and hasn't changed much recently. so I'm fast-tracking in the interest of the cabal-install-3.12.1.0 release.

[ulysses4ever]

@Mergifyio backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10058 CI: add GHC 9.10 (backport #9914) has been created for branch 3.12