Allow building with GHC 9.12 - #1828
Conversation
|
There's a rather scary-looking error when compiling This appears to be a GHC bug, and one that is exclusive to GHC 9.12. I've opened https://gitlab.haskell.org/ghc/ghc/-/issues/27261 to track this. Thus far, the only workaround that I've discovered is to ensure that the calls to diff --git a/crucible-mir/src/Mir/Trans.hs b/crucible-mir/src/Mir/Trans.hs
index a0bb1125b..93748cb51 100644
--- a/crucible-mir/src/Mir/Trans.hs
+++ b/crucible-mir/src/Mir/Trans.hs
@@ -1300,8 +1300,8 @@ mkTraitObject :: forall h s ret.
MirExp s ->
MirGenerator h s ret (MirExp s)
mkTraitObject traitName' vtableName e = do
- handles <- Maybe.fromMaybe (error $ "missing vtable handles for " ++ show vtableName) <$>
- use (cs . vtableMap . at vtableName)
+ mbHandles <- use (cs . vtableMap . at vtableName)
+ let handles = Maybe.fromMaybe (error $ "missing vtable handles for " ++ show vtableName) mbHandles
col <- use $ cs . collection
vtable <- case col ^. vtables . at vtableName of
@@ -1323,9 +1323,10 @@ mkTraitObject traitName' vtableName e = do
-- trait. A mismatch would cause runtime errors at calls to trait methods.
trait <- Maybe.fromMaybe (error $ "unknown trait " ++ show traitName') <$>
use (cs . collection . M.traits . at traitName')
- Some vtableTy' <- case traitVtableType col trait of
- Left err -> error ("mkTraitObject: " ++ err)
- Right x -> return x
+ let someVtableTy' = case traitVtableType col trait of
+ Left err -> error ("mkTraitObject: " ++ err)
+ Right x -> x
+ Some vtableTy' <- pure someVtableTy'
case testEquality vtableTy vtableTy' of
Just _ -> return ()
Nothing -> error $ unwords |
| -- there is no ring-buffer that permits GHC 9.12's base version | ||
| -- and boomerang doesn't permit GHC 9.12's template-haskell | ||
| allow-newer: ring-buffer:base | ||
| allow-newer: boomerang:template-haskell |
There was a problem hiding this comment.
I generally like to file issues on the upstream repos and link to them in these comments to make it easier to track whether or not we can remove the allow-newers.
There was a problem hiding this comment.
That is a good idea, I will make sure that gets done if we still need them by the time this gets merged.
|
DetailsAs far as I can tell, this is a regression in GHC's typechecker, which I have reported upstream at https://gitlab.haskell.org/ghc/ghc/-/issues/27262. A workaround is to enable |
1122b19 to
cf21740
Compare
(See #1828 for further information)
(See #1828 for further information)
360d5dd to
d906f6d
Compare
|
ok, so it builds finally. I need to go check whether we still need allow-newer (and if so, file tickets upstream); then there are a couple questions to answer:
|
That sounds reasonable to me.
I also vote yes, if that doesn't turn up any additional complications. |
Complication: the current default build is 9.10. I don't think we really want to roll that back to 9.8, and I don't think we want to roll it forward to 9.12 at the same time we first add 9.12 either. We could drop either 9.6 or 9.8 (the latter doesn't seem entirely desirable, the former seems likely to result in periodically breaking the SAW build) or just build four versions until we are ready to drop 9.6 everywhere. |
|
Ok, looks like 9.10.3 did not create complications. We just need to decide on the builds, and on |
|
I'm a bit confused: wasn't the proposal to use the same versions as in Cryptol's CI (9.6, 9.8, and 9.12 but skip 9.10)? |
|
It was, but currently what we build is:
(some of the builds skip ubuntu 22, some skip windows, dunno how intentional that is) Therefore under that plan we could do:
where the first winds back some of the versions (not necessarily desirable) and the second moves everything to 9.12 right away (also not necessarily desirable, especially right before a release). Therefore I also suggested:
and another possible choice is
Hopefully this is clearer... |
|
Ah, thanks for clarifying. The tension is that the current "default" GHC version in SAW's CI is one that Cryptol's CI doesn't test at all, then? I mainly suggested mirroring what Cryptol's CI does under the assumption that it would be simpler, but if it's not simpler, then we should feel free to deviate a bit. I think option (4) would be my (slight) preference, as that picks three consecutive versions without needing to figure out the churn associated with a new default GHC version for CI. |
|
This is crucible :-) (SAW's CI is currently on 9.4, 9.6, and 9.8, like Cryptol's had been before this round of changes) The only problem with (4) is that there's some risk of accidentally introducing code that doesn't work in 9.6 and breaking the SAW build. I don't think that risk is all that high though. |
Link upstream issues/PRs. Ideally we wouldn't need to do this...
Fixes build problem with recent Data.Text. This is required for the latest GHC 9.10 as well as 9.12.
(See #1828 for further information)
(rename only for git safety; further changes coming next) XXX: fold into the original creation if it works
I've added this to every CHANGELOG because grep suggests we've done a very spotty job of randomly mentioning or not these changes in the past, and there's no central place.
31e6d49 to
fc81dd2
Compare
|
I have rearranged the commits. It is still building 9.12 as well as everything else; will change that as soon as we're sure we've reached a decision. |
3 participants
This isn't working yet