Skip to content
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

Merged
merged 5 commits into from
May 22, 2024
Merged

Support building with GHC 9.8 #1665

merged 5 commits into from
May 22, 2024

Conversation

RyanGlScott
Copy link
Contributor

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.

@RyanGlScott
Copy link
Contributor Author

A mysterious failure in the Cryptol / test (test-lib, ffi, windows-2019, false) job here, which deserves a closer look:

  tests:
    ffi:
      ffi-fallback-rec.icry: [OK]
      ffi-fallback.icry: [OK]
      ffi-header.icry: [OK]
      ffi-no-dup.icry: [OK]
      ffi-no-functor.icry: [OK]
      ffi-reload.icry: [OK]
      ffi-runtime-errors.icry: [OK]
      ffi-type-errors.icry: [OK]
      test-ffi.icry: [Failed]
39,45d38
< (ratio 2 1)
< [(ratio 4 1), (ratio 1 4)]
< ((ratio 37 1), 72)
< 2
< 0
< 1
< 0x48

# If output is OK:
cp D:\a\cryptol\cryptol\output\.\tests\ffi\test-ffi.icry.stdout \
     D:\a\cryptol\cryptol\tests\ffi\test-ffi.icry.stdout.mingw32



         Test Cases  Total 
 Passed  8           8     
 Failed  1           1     
 Total   9           9     
Error: Process completed with exit code 1.

@RyanGlScott
Copy link
Contributor Author

Another error, uncovered when building the cryptol-remote-api Docker image (here):

125.8 make --no-print-directory -f ghc.mk phase=0 phase_0_builds
125.8 ghc.mk:141: *** The make build system requires a boot compiler older than ghc-9.2. Your boot compiler is too new and cannot be used to build ghc-9.4 with make. Either boot with ghc 9.0.2 or build with hadrian. See https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html for advice on transitioning to hadrian..  Stop.
125.8 make: *** [Makefile:124: all] Error 2

@RyanGlScott RyanGlScott marked this pull request as ready for review May 21, 2024 11:26
@RyanGlScott RyanGlScott requested review from kquick and yav May 21, 2024 11:27
Copy link
Member

@kquick kquick left a 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,
Copy link
Member

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.

Copy link
Contributor Author

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).

src/Cryptol/IR/FreeVars.hs Outdated Show resolved Hide resolved
src/Cryptol/ModuleSystem/Names.hs Outdated Show resolved Hide resolved
RyanGlScott and others added 5 commits May 22, 2024 07:25
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.
@RyanGlScott RyanGlScott merged commit 1458866 into master May 22, 2024
46 checks passed
@RyanGlScott RyanGlScott deleted the ghc-9.8 branch May 22, 2024 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support ghc 9.8
2 participants