Skip to content

GHC 9.2 support #272

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.

Sign up for GitHub

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

Jump to bottom
Open
gelisam wants to merge 5 commits into
base: main
Choose a base branch
from
Open

GHC 9.2 support #272

gelisam wants to merge 5 commits into from

Conversation

@gelisam
Copy link
Owner

@gelisam gelisam commented Mar 31, 2022

No description provided.

gelisam added 3 commits March 30, 2022 22:49
@gelisam
temporarily using ghc-9.2.2
8b183b4 
I don't think it's polite to pin a nightly if an lts will do, so I don't
want to make this change permanent.
@gelisam
support "Monad of no return"
27bb638 
the error message recommends deleting the 'return' definition, so I did.
It is safe to do so because their definition was equivalent to
@return = pure@.
@gelisam
disable poly-kinds
40d875b 
looks like PolyKinds is on by default now. Not sure why it's causing
issues in this module, but these type variables are definitely intended
to have kind *. Maybe it would have been better to use a kind
annotation?
@gelisam gelisam requested a review from juhp March 31, 2022 02:57
@gelisam
Copy link
Owner Author

gelisam commented Mar 31, 2022

According to commercialhaskell/stackage#6486 (comment), haskell-awk has been dropped from nightly because it doesn't compile with ghc-9.2.2, so we need to support that version in order to get back into stackage.

@gelisam
Copy link
Owner Author

gelisam commented Mar 31, 2022

The CI / oldest configuration fails with:

ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.2 for x86_64-unknown-linux):
    Prelude.chr: bad argument: 2583691267

This is presumably https://gitlab.haskell.org/ghc/ghc/-/issues/19452, which in turn means CI is caching files generated from one version of ghc and regenerating them when building with another version of ghc. But that doesn't make sense, because

  1. CI / oldest and CI / stable use a different cache key
  2. it's CI / stable which is using a newer version of ghc, not CI / oldest

Hmm, what else could explain this error message?

@gelisam
temporarily disable CI cache
fbe571c 
CI failed with @Prelude.chr: bad argument@, which usually means that one
version of ghc is trying to load a file compiled with another version of
ghc. CI is compiling the code with multiple versions of ghc... but it's
supposed to be using separate caches!

Let's disable the cache to clarify whether caching is involved or not.
@gelisam
Copy link
Owner Author

gelisam commented Mar 31, 2022

Same error without the CI cache, so it's indeed something else. I can reproduce locally with stack --stack-yaml=oldest-supported-lts.yaml test; I guess we need an older version of stack to build with older versions of ghc?

@gelisam
Copy link
Owner Author

gelisam commented Mar 31, 2022

I get the same result with both the newest (stack-2.7.5) and oldest (stack-2.5.1) versions of stack supported by ghcup. ghcup only started installing stack relatively recently, so maybe I need to pick an even older version; or maybe the problem is not the version of stack at all. Hard to tell, with such an obscure error message!

@juhp
Copy link
Collaborator

juhp commented Apr 1, 2022 •
edited
Loading

Did the version of stack change?

I pretty sure I can build my projects with all ghc-8.x using stack-2.7 though.

@gelisam
Copy link
Owner Author

gelisam commented Apr 1, 2022

Sounds plausible! We do not specify the stack-version parameter, so the haskell/actions/setup@v1 action defaults to whatever the action considers the latest. It's possible that the action changed which version that is during the last 4 months (CI last ran then and failed, but this particular test succeeded).

@juhp
Copy link
Collaborator

juhp commented Apr 2, 2022 •
edited
Loading

Ya, I am not sure what is going on: I see it is using Ubuntu 20.04: unfortunately older CI logs seem to have been already gc'ed...

I have definitely run into problems in the past here with ghc 7.10: ghc-8.0 is already getting a bit old I suppose.
How about bumping oldest to 8.2 for now? Does that work?

@gelisam
Copy link
Owner Author

gelisam commented Apr 2, 2022

Experimenting further, stack --stack-yaml=oldest-supported-lts.yaml test works for me after deleting ~/.stack (and installing happy using stack --stack-yaml=stack.yaml install happy as in the CI script). So I do think caching is involved after all. But how is that possible when I've deleted the actions/cache@v2 block? Could haskell/actions/setup@v1 be doing its own caching behind the scenes?

@gelisam
Copy link
Owner Author

gelisam commented Apr 2, 2022

The haskell/actions/setup@v1 project is currently working on adding their own caching behind the scenes, so I can safely conclude that no, the current version of haskell/actions/setup@v1 is not already doing its own caching :)

What else could it be then?

@gelisam gelisam mentioned this pull request Feb 10, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@juhp juhp Awaiting requested review from juhp

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@gelisam @juhp