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

chore: Upgrade to GHC 9.2 #244

Merged
merged 2 commits into from
Jun 2, 2022
Merged

chore: Upgrade to GHC 9.2 #244

merged 2 commits into from
Jun 2, 2022

Conversation

dhess
Copy link
Member

@dhess dhess commented Feb 7, 2022

There are quite a few workarounds needed in this PR, but we can now build everything with GHC 9.2.

The HLS workaround included here is to build it from source until the next official release.

@dhess
Copy link
Member Author

dhess commented Feb 7, 2022

Note: I don't expect this to work just yet, but we should get closer now that we've removed Selda, and also because more time has passed since my last attempt.

@dhess dhess added the WIP A work in progress, not ready for merging label Feb 7, 2022
@georgefst
Copy link
Contributor

WIP. Includes several community fixes for packages that aren't ready for GHC 9.2.

Current status:

* stuck on `servant`:

FWIW, if we're happy using community patches, then I'm not sure we're any more stuck on Servant than on e.g. memory. I've actually been using the branch in that PR for a while on one of my personal projects.

@georgefst
Copy link
Contributor

But, given that we're in no particular rush to do this, and, unlike memory, visible progress is being made upstream in Servant, then maybe it isn't worth the time to set up the overrides.

@dhess
Copy link
Member Author

dhess commented Feb 7, 2022

FWIW, if we're happy using community patches, then I'm not sure we're any more stuck on Servant than on e.g. memory. I've actually been using the branch in that PR for a while on one of my personal projects.

I wouldn't say "happy." I definitely don't want to make a habit of this and I'm hopeful the community will address these 2 particular cases soon enough, one way or the other.

@dhess dhess added the blocked/upstream ❌ Blocked by upstream issue label Feb 7, 2022
@dhess dhess force-pushed the dhess/ghc9 branch 2 times, most recently from a5e6820 to 2a5cfa1 Compare March 5, 2022 14:09
@georgefst
Copy link
Contributor

Servant has just added support, via a different PR to the one linked here: haskell-servant/servant#1555

@dhess
Copy link
Member Author

dhess commented Mar 21, 2022

Cool, thanks for the update. The Servant fix should be in the next haskell.nix update so I'll try to rebuild this again in a few days.

@dhess
Copy link
Member Author

dhess commented Mar 28, 2022

FYI: currently broken on Protolude, for starters. I was able to work around this with a Cabal project pin.

@dhess dhess force-pushed the dhess/ghc9 branch 2 times, most recently from 62af671 to c308966 Compare March 28, 2022 22:53
@dhess
Copy link
Member Author

dhess commented Mar 28, 2022

Well, this is progress:

https://buildkite.com/hackworthltd/primer/builds/350#f7bb3e88-5857-461b-ae92-0a674aab7f42

@brprice Could you take a look at that when you need a break from your modules work? It's not high priority, but I just want to get to the bottom of why this is showing up in tasty-hedgehog-1.2.0, which I've upgraded to in this PR.

@brprice
Copy link
Contributor

brprice commented Mar 29, 2022

The tasty-hedgehog issue is because of qfpl/tasty-hedgehog#42
Seems like an easy fix

@dhess
Copy link
Member Author

dhess commented Mar 29, 2022

OK, I'll take care of this.

@brprice
Copy link
Contributor

brprice commented Mar 29, 2022

The tasty-hedgehog issue is because of qfpl/tasty-hedgehog#42 Seems like an easy fix

Urrgh, this has annoying interactions. It is easy to keep the status quo at least: GaloisInc/what4#195 (comment)

I think we can do a little better, see #349

@dhess
Copy link
Member Author

dhess commented Apr 9, 2022

FYI, I'm guessing here, but it looks like GHC 9.2.2 doesn't like one of the recent changes to naming:

https://buildkite.com/hackworthltd/primer/builds/396#f1b76d29-053c-46aa-ac49-59c02ecfded8/17-7363

@georgefst
Copy link
Contributor

FYI, I'm guessing here, but it looks like GHC 9.2.2 doesn't like one of the recent changes to naming:

https://buildkite.com/hackworthltd/primer/builds/396#f1b76d29-053c-46aa-ac49-59c02ecfded8/17-7363

From the release notes:

In addition, GHC now enforces the rule that the types in deriving clauses and via types (for instances derived with DerivingVia) cannot contain nested foralls or contexts.

I haven't looked in to why that is.

Anyway, one solution is to list out each constructor instead:

deriving via Name instance (ToSchema (GlobalName 'ATyCon))
deriving via Name instance (ToSchema (GlobalName 'AValCon))
deriving via Name instance (ToSchema (GlobalName 'ADefName))

@dhess
Copy link
Member Author

dhess commented Apr 11, 2022

Regarding 9648a86 — uhh... huh. I did not expect that to be the fix.

@brprice
Copy link
Contributor

brprice commented Apr 11, 2022

FYI, I'm guessing here, but it looks like GHC 9.2.2 doesn't like one of the recent changes to naming:

https://buildkite.com/hackworthltd/primer/builds/396#f1b76d29-053c-46aa-ac49-59c02ecfded8/17-7363

As @georgefst points out, this is indeed a change in GHC 9.0.1. Writing them out explicitly is indeed a solution. However, we can do better. I have pushed a commit to this branch showing how. (Just to get CI working, I'll open a pr on main shortly)

I am not sure why I wrote the instance in the way I did, with parentheses, but I am now convinced it was a mistake! I want a context that k is typeable, rather than deriving an instance for the class Typeable k => ToSchema (GlobalName k), which is nonsense!

@brprice
Copy link
Contributor

brprice commented Apr 11, 2022

There is now a PR on main: #370

@dhess
Copy link
Member Author

dhess commented May 22, 2022

See the OP for an update. The good news is that only HLS is blocking us now, but the bad news is that it looks a long way off: haskell/haskell-language-server#2179

@georgefst
Copy link
Contributor

See the OP for an update. The good news is that only HLS is blocking us now, but the bad news is that it looks a long way off: haskell/haskell-language-server#2179

The haskell-language-server issue looks like it's a long way from working due to several of its plugins lacking support for GHC 9.2.

In case it isn't clear from the OP on haskell/haskell-language-server#2179, there has now been at least one release of HLS with 9.2 support, with those plugins disabled.

@dhess
Copy link
Member Author

dhess commented May 23, 2022

Do you mean 1.7.0.0? Because that doesn't currently build (with haskell.nix anyway) due to a problem with what appears to be several plugins:

https://buildkite.com/hackworthltd/primer/builds/759#cc9401af-eed0-48e3-9e95-185e44e3121d/17-1150
https://buildkite.com/hackworthltd/primer/builds/759#cc9401af-eed0-48e3-9e95-185e44e3121d/17-1186

Is there a way to disable those plugins from a Cabal project file or something?

@dhess
Copy link
Member Author

dhess commented May 23, 2022

(Also, in yesterday's build, I bumped Weeder to 2.3.1, which allegedly supports 9.2, but that also failed. I'm not sure what's going on there.)

@dhess dhess closed this May 23, 2022
@dhess dhess reopened this May 23, 2022
@georgefst
Copy link
Contributor

Do you mean 1.7.0.0?

Yes, it seems 1.7 is the first with support for GHC 9.2.2.

Is there a way to disable those plugins from a Cabal project file or something?

Yes. e.g:

constraints:
    +ignore-plugins-ghc-bounds
    -brittany
    -haddockComments
    -retrie

The simplest way is probably to find HLS's cabal-ghc92.project file from the time of release. Note that this was very recently removed: haskell/haskell-language-server#2866.

@dhess
Copy link
Member Author

dhess commented May 23, 2022

As discussed in chat, what @georgefst suggests in parent would require overriding HLS's Cabal project file, which is (as far as I understand it) only possible by effectively duplicating it verbatim, plus the changes we want, and then feeding that to our haskell.nix config as an override. While we could do that, I'd really prefer not to. Fixes for plugins with 9.2 are coming in 1.8.0, and we can wait another week or two before switching to GHC 9.2, so let's give them a bit more time before we resort to the override.

@dhess dhess force-pushed the dhess/ghc9 branch 10 times, most recently from 8c088d4 to 8f03eea Compare June 2, 2022 12:10
@dhess dhess enabled auto-merge June 2, 2022 13:31
@dhess dhess disabled auto-merge June 2, 2022 13:31
@dhess dhess force-pushed the dhess/ghc9 branch 2 times, most recently from 867327f to 981708e Compare June 2, 2022 15:25
dhess added 2 commits June 2, 2022 16:32
We must also bump Weeder to 2.4.0, as it tracks GHC closely.

Note that this commit includes workarounds for packages that are not
yet ready for GHC 9.2:

* protolude: ignore bounds.
* cabal-fmt & cabal-edit: build using GHC 8.10.7.

HLS is broken in by this commit. We can work around it, but it
requires some fairly major changes to the flake that are hopefully
only temporary until the next release, so I'll do that in a subsequent
commit, to make it easier to revert those changes in the future.

Somewhat unrelated, in this commit we also pin fourmolu to 0.6.0, as
the latest version (0.7.0) makes some pretty arbitrary formatting
changes *again*, and I'm tired of fixing the pre-commit checks every
time this happens.
@dhess dhess added this pull request to the merge queue Jun 2, 2022
@dhess dhess merged commit b146f66 into main Jun 2, 2022
@dhess dhess deleted the dhess/ghc9 branch June 2, 2022 16:09
@dhess dhess mentioned this pull request Jun 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked/upstream ❌ Blocked by upstream issue WIP A work in progress, not ready for merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants