cabal
cabal copied to clipboard
haskell
CI: add GHC 9.10
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:
- [x] 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).
Made this mistake again: opened PR against upstream whereas it was meant to be a local experiment. Oh well, will be spamming you guys...
~~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
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.
@bgamari, @mpickering, @alt-romes: this looks to me like something has changed in ghc, since the ghc invocation looks correct to me?
@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.)
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.
@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.
Oh, yeah, you're probably hitting https://github.com/haskell/cabal/issues/8133
This is exactly ghc-9.10-alpha3, but I'll need it to work for random commits in order to try to bisect it.
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.
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.
@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.
Integration tests (internal)
Target selectors
problems (common): FAIL
Exception: Error: [Cabal-7107]
Could not resolve dependencies:
[__0] trying: q-0.1 (user goal)
[__1] next goal: filepath (dependency of q)
[__1] rejecting: filepath-1.5.2.0/installed-b0c8 (constraint from unknown source requires source instance)
[__1] trying: filepath-1.5.2.0
[__2] next goal: base (dependency of q)
[__2] rejecting: base-4.20.0.0/installed-0538 (conflict: filepath => base>=4.12.0.0 && <4.20)
What is a "constraint from unknown source"?
Yeah, I thought so much effort was put into making tests independent of Hackage, and yet here we are... :-(
I think I've seen this problem before: this fails even though the project file allow-newer: *:base. I created an issue for filepath:
- https://github.com/haskell/filepath/issues/230
But… shouldn't the filepath installed with the GHC 9.10 prerelease already allow the base shipped along with it? (Although I did wonder if that was why the peculiar rejection message.)
I think the way this particular test works makes it get the latest filepath from Hackage (perhaps, bounded by what the cabal file says, which is <1.6 currently).
@ulysses4ever Regarding the https://github.com/haskell/cabal/commit/1b0fbdc3d97273ccabb804a0c16ef1555edb19da test I think it's ok to remove options that don't work now - NOERROR1 and NOERROR3.
With NOERROR4 which was passed through ghc-options there already was a warning to use cpp-options in the cabal file instead. So perhaps changing it to cpp-options will make it work. Then we'll lose only 2 of the defines still keeping plenty of other ways them. The important part is to exercise the (all) working ways in the test.
UPD: could even go further and flip now-failing defines, NOERROR1 and NOERROR3 by renaming them into ERROR1 and ERROR3 respectively and making C code fail to compile if either of them is defined.
Next failure is here: https://github.com/haskell/cabal/actions/runs/8837820981/job/24339037416?pr=9914#step:18:1396
It looks like we hit https://github.com/haskell/cabal/issues/9940
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.
backport 3.12
✅ Backports have been created
- #10058 CI: add GHC 9.10 (backport #9914) has been created for branch
3.12
![mergify[bot] avatar](https://avatars.githubusercontent.com/in/10562?v=4 "Published by a pub.dev verified publisher"){kind=small}