-
Notifications
You must be signed in to change notification settings - Fork 123
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
Support building with GHC 9.8 #1665
Conversation
A mysterious failure in the
|
Another error, uncovered when building the
|
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.
A couple of minor suggestions, but looks good.
argo, | ||
aeson >= 1.4.2 && < 2.3, | ||
base64-bytestring >= 1.0, | ||
bytestring >= 0.10.8 && < 0.12, | ||
bytestring >= 0.10.8 && < 0.13, |
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.
I wonder if we could just stop specifying upper (or any) bounds on bytestring and text (and possibly any others listed at https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history) because since they are distributed as boot libraries along with GHC, they are effectively constrained by the base
bounds? This would mean fewer places needing an update when we do these version bumps.
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.
These boot library versions aren't wholly determined by base
, as it's still possible to manually specify different versions of boot libraries than the ones that come included with GHC. (Indeed, some of our users do exactly this, as seen here.) Personally, I'd rather err on the side of caution here, since it is quite possible for major version bumps in boot libraries to break things (see, for instance, the mtl-2.3.*
-related changes in #1572).
This patch: * Tightens up imports in `Cryptol.Eval.FFI.GenHeader` to avoid importing two different versions of `unzip` (note that GHC 9.8 defines `unzip` in `Data.Functor`, which is different from the version defined in `Data.List`). * Bumps the upper version bounds on various dependencies (`base`, `sbv`, etc.) to support versions that are compatible with GHC 9.8. Fixes #1624.
These functions now trigger `-Wx-partial` warnings with GHC 9.8 or later. Where convenient, I rewrote some code to use `NonEmpty` lists, but for more involved pieces of code, I simply made it clearer which parts rely on invariants about lists being non-empty by marking the (hopefully) inaccessible cases with `panic`s.
This patch:
Cryptol.Eval.FFI.GenHeader
to avoid importing two different versions ofunzip
(note that GHC 9.8 definesunzip
inData.Functor
, which is different from the version defined inData.List
).base
,sbv
, etc.) to support versions that are compatible with GHC 9.8.Fixes #1624.