-
Notifications
You must be signed in to change notification settings - Fork 722
CI: add ghc 9.14-alpha1 #11174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
CI: add ghc 9.14-alpha1 #11174
Conversation
I don't understand the current failure in CI |
Bootstrap, at least, is using the latest Hackage release of Cabal instead of either the one with ghc or the one it just built from the repo, for some reason. I would suspect the latter is what's actually intended, since you're supposed to bootstrap from the repo. This implies to me that something's wrong with |
Same thing reported differently for validate:
again implying it's using the wrong |
beee078
to
dc4a6f6
Compare
haddock-project:dependencies (from integration-tests2) is failng for unclear reason.
|
So, this cabal-install integration test calls the The question is then: why moving to GHC 9.14-alpha1 made solver pick an acient |
the answer seems to be: that was the last version of async that didn't have an upper bound on base. I think we should switch to a boot package, for which we have a much lower chance of running in something like this. |
all right, it's gotten to the meat of it, cli-suite, and a bunch of tests fail. Raw log: https://github.com/haskell/cabal/commit/6e603722b4e702b5a75e8cf180a4830b483215f4/checks/48593991452/logs (it can't display them because something is printing "quick brown fox jumps..." a zillion times: we should reconsider that test!) |
232 tests, it looks. I don't remember such a fallout...
|
I don't see any of these locally... |
Trying it here. I don't make any promises, in particular I may not be around when it finishes because I need to do laundry this afternoon. |
I found multiple tests which are apparently forcing hashable-1.4.2.0 in CI, whereas ghc-latest.config is forcing hashable-1.4.3.0. |
Okay, validate passes here (using the 9.14 prerelease) as well, so it's something about our CI. |
The Windows failures are peculiar: it looks like the test suites pass, then afterward we get that annoying ghci error exit twice followed by "process exited with code 1". |
ping @jasagredo re Windows CI failures? |
I wonder if it's the (GHA) cache... |
I'm seeing a bunch of
in the raw logs I referenced above. |
That's been going on for a while now. |
#11023 may be related, since validate now uses |
I'm sorry but I am quite busy at least until the end of September, so I'm afraid I won't be able to spend time on this more than just give it a very brief look. Also in the past I fixed numerous things in the package tests, but not in the integration tests and just skimming over the CI logs it seems the error is in the latter. Like 2630 on the GHC 9.8.4 on Windows job shows:
|
Umh, I just touched this test, and the update version passes on Linux... |
6e60372
to
6971ed8
Compare
So, maybe some Hackage revision issue prevented the original CI run from working, but it got fixed before we tried it locally? But I didn't And we still have the Windows failures… but only on the older versions. Now I'm curious as to whether the job Mergify is currently running will pass. |
Looks like it succeeded, so something in here is causing it. But only for older Windows. ❓ |
This gets stranger all the time: now we got a bunch of those double-config warnings, but only on 9.14-alpha1. |
And my hack didn't fix it anyway. |
So I'm still getting 3 local fails, none of which are the ones in CI; all three are 502s from |
7efb3c2
to
83980e9
Compare
And I still see nothing in the diffs that would introduce a build error only with old ghcs on Windows. |
I think the Windows failures might have to do with how boot libraries were cooked for Windows during that age (GHC 9.{4,6,8}, our current failures). Compare a successful Ubuntu run to a failed WIndows one: 1,2c1
< haddock-project
< dependencies: Build profile: -w ghc-9.14.0.20250819 -O1
---
> dependencies: Build profile: -w ghc-9.4.8 -O1
8c7
< [1 of 1] Compiling MyLib ( src/MyLib.hs, dist-newstyle/build/x86_64-linux/ghc-9.14.0.20250819/a-0.1.0.0/build/MyLib.o, dist-newstyle/build/x86_64-linux/ghc-9.14.0.20250819/a-0.1.0.0/build/MyLib.dyn_o )
---
> [1 of 1] Compiling MyLib ( src\MyLib.hs, dist-newstyle\build\x86_64-windows\ghc-9.4.8\a-0.1.0.0\build\MyLib.o )
11c10,14
< Haddock coverage:
---
> Warning: The following packages have no Haddock documentation installed. No
> links will be generated to these packages: array-0.5.4.0, base-4.17.2.1,
> binary-0.8.9.1, bytestring-0.11.5.3, containers-0.6.7, deepseq-1.4.8.0,
> ghc-bignum-1.3, ghc-boot-th-9.4.8, ghc-prim-0.9.1, pretty-1.1.3.6,
> template-haskell-2.19.0.0, text-2.0.2
15c18,21
< someFunc
---
> someFunc (src\MyLib.hs:5)
> Warning: MyLib: could not find link destinations for:
>
> - GHC.Types.IO
17,19c23
< /home/runner/work/cabal/cabal/cabal-install/tests/IntegrationTests2/haddock-project/dependencies/./dist-newstyle/build/x86_64-linux/ghc-9.14.0.20250819/a-0.1.0.0/doc/html/a
< [1 of 1] Compiling MyLib ( src/MyLib.hs, nothing ) [HIE file is missing]
< Haddock coverage:
---
> D:\a\cabal\cabal\cabal-install\tests\IntegrationTests2\haddock-project\dependencies\.\dist-newstyle\build\x86_64-windows\ghc-9.4.8\a-0.1.0.0\doc\html\a
23,24c27,34
< someFunc (src/MyLib.hs:6)
< OK (9.56s)
---
> someFunc (src\MyLib.hs:5)
> Warning: MyLib: could not find link destinations for:
>
> - GHC.Types.IO
> FAIL (7.21s)
> tests\IntegrationTests2.hs:2816:
> File `haddocks\text\text.haddock` does not exist.
> Use -p '/dependencies/' to rerun this test only. My thought is that we should skip this test on these older Windows configurations. |
Well, I think you just saved me trying to set up a (headless since vbox doesn't seem to like me) Windows VM and bisect what commit caused it, at least. Maybe we can try something other than |
@geekosaur yes, trying something other than The proper way to fix it (I think) would be to move the test to convert it to a proper |
|
I meant:
trying |
So did I; |
Same result. I suspected the warning message is just being lazy and doesn't mention all boot libraries, but it seems like the issue will arise with any of those. We're back to the question: should we
@geekosaur do you think you could spare some energy on (2)? I truly think it's the only proper fix but I'm running out of cabal time budget... |
I'm finally looking at this, and I think we might have a problem: there are tests that fail with |
Come to think of it, I'm not sure adding documentation for anything in the private store is safe, since I would expect its existence to mean Hackage installs also go there. (That being said, In any case, it may be better to just concede that older ghc versions need to be skipped on Windows. |
3031235
to
05a8050
Compare
Works for me, thank you for working on this! We're ready for review now! 🎉 |
05a8050
to
3c3a3fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
the test was using async from hackage as an exmaple global package. Currently, async has a too restrictive upper bound on base. It'll be more robust to rely on a boot package instead. Ideally we'd not rely on anything from Hackage in tests, but that's an issue for another day. Also, disable haddock-project on older Windows It fails for an unknown reason; possibly the output is in the wrong place compared to where the test looks, but tooling gets it right.
- Update ghc-latest.config: 9.12 -> 9.14 - ghc-latest.config: allow-newer: - binary - containers - ghc-bignum
3c3a3fa
to
29b79f1
Compare
It seems like alpha2 is around the corner, so I'll wait for it a bit. haskell/ghcup-metadata#329 |
@geekosaur help is welcome
Template B: This PR does not modify behaviour or interface
E.g. the PR only touches documentation or tests, does refactorings, etc.
Include the following checklist in your PR: