Initial portion of GHC 9.10 and 9.12 support - #3252
Conversation
|
something broke and it doesn't make any sense, will investigate |
|
ok, it was broken by updating Cryptol, bisecting reveals that it was broken by GaloisInc/cryptol#2040 (expose parameters from functor instantiations). I rather fear that the real problem is #3000 and the Cryptol changes have made it easier to trigger. |
|
Further analysis is going in #3254. |
2f1405f to
a655dfc
Compare
|
Not sure what's going on here, might just be cache corruption |
a655dfc to
e641fa9
Compare
|
Note that this can't be merged for the moment because it's pointing at an unmerged Cryptol commit. |
e641fa9 to
9059eab
Compare
|
It is no longer pointing at an unmerged Cryptol commit. However, I have no idea what's going on with the coverage generation. Bumping the cache version did not help, so it probably isn't cache corruption, and it's the same GHC version that we were doing it with before. Best bet is that something about the new Cabal version broke it... |
9059eab to
09ab90e
Compare
|
Meanwhile for some reason the change I pushed to improve the logging behavior of compute-coverage.sh contained an extra unwanted change that reverted the Cryptol version and broke everything. |
09ab90e to
2d76b62
Compare
|
ok, the speculative change worked. I'm quite confused, but we can run with it... |
|
I'm about to force-push this repeatedly to try to (a) figure out what's going on and (b) make sure all the commits in the eventual branch are buildable. I would recommend not trying to follow these and instead just looking at the final diffs. This should probably be reviewed again anyway as I've made material changes since it was last approved. |
2d76b62 to
9e986c8
Compare
|
I do not understand what's going on with It seems the cabal update and the compute-coverage.sh search changes need to get committed together. Which I guess isn't too surprising |
With current Cryptol we should never see a nonempty "ogFromParam" field in any module we can actually import, so if we do, fail instead of adding the parameter name to the module path.
This bumps language-sally and macaw, and also pulls in a new flexdis86 to go with the new macaw.
As requested by a warning in GHC 9.10.
Use explicit progress messages instead of set -x, and explicit error checks instead of set -e. The set -x output spews vast amounts of illegible crud because the paths we're dealing with are in excess of 200 characters each (between the GH runner's work dir being five layers deep, the top level of cabal's output being another five under that, and the top of each hpc tree under that being another six layers...). Meanwhile, it makes sense to print some of this stuff only on error, and that requires handling the failure explicitly rather than using set -e. It's still going to be an ugly mess, but it seems like that can't be helped.
0a22528 to
cb17dea
Compare
This fixes weird solve errors seen with GHC 9.10 and/or 9.12 test Also it seems we need to rearrange the mix file search in compute-coverage.sh again, because something about the Cabal version change changed hpc's search behavior even though the file layout seems to be the same as before.
|
ok, this is now actually working and can be re-reviewed |
3 participants
It looks like 9.12 support in Crucible is going to take a while, and these bits are mergeable, so let's merge them to reduce the maintenance overhead on the branch with the full support.
This part:
foldl'for ghc 9.10+ #3146