Support for GHC-9.0

Question

Support for GHC-9.0

mouse07410 opened this issue 4 years ago · 43 comments

Answer 1 · 2020-11-09T08:12:39.000Z

STATUS

~~It still has not been released~~

upstream packages that should be updated to being buildable with ghc-9.0.4, to build hls-plugin-api alone

//cc @Kleidukos

Answer 2 · 2021-01-18T13:29:54.000Z

The release candidate has been uploaded: https://www.haskell.org/ghc/blog/20201229-ghc-9.0.1-rc1-released.html
So we could start to add support for it 😄

Answer 3 · 2021-02-05T06:18:59.000Z

Now that ghc 9.0.1 has been released, maybe we should bump up the priority?

Answer 4 · 2021-02-05T06:26:40.000Z

Yeah, but i guess it will be a complex change, given we are totally tied to ghc

Answer 5 · 2021-02-05T06:38:02.000Z

As the module structure of the ghc package drastically changed in 9.0.1, it might make sense to provide some compatibility layer in ghcide or its dependency. I once tried ghc-api-compat with GHC 9.0.1-rc1 as a compact layer, but its Hackage version didn't compile at that time.

Answer 6 · 2021-02-05T06:47:34.000Z

We have already a compat module in ghcide but it does not export everything we need and it is misused in some code regions (for example i did not use in hlint puglin until recently)
We can leverage it while we add support for the new ghc version.

https://github.com/haskell/haskell-language-server/blob/master/ghcide/src/Development/IDE/GHC/Compat.hs

Answer 7 · 2021-02-10T10:55:16.000Z

I've started a branch to give a quick try to ghc-9.0.1. I am afraid that only trying to build hls-plugin-api our simpler subpackage with less dependencies i have needed several allow-newer:

packages: .

allow-newer:
  regex-tdfa:base,
  regex-base:base,
  lens:template-haskell,
  parallel:base,
  haskell-lsp:base,
  haskell-lsp-types:base,
  hashable:base,
  time-compat:base,
  these:base,
  assoc:base,
  deepseq:base,
  hslogger:base

With this in a cabal.project in ./hls-plugin-api i still got:

cabal: Could not resolve dependencies:
[__0] trying: hls-plugin-api-0.7.0.0 (user goal)
[__1] trying: lens-4.19.2 (dependency of hls-plugin-api)
[__2] trying: lens:setup.base-4.15.0.0/installed-4.15.0.0 (dependency of lens)
[__3] next goal: lens:setup.Cabal (dependency of lens)
[__3] rejecting: lens:setup.Cabal-3.4.0.0/installed-3.4.0.0,
lens:setup.Cabal-3.4.0.0 (constraint from maximum version of Cabal used by
Setup.hs requires <3.4)

So the build type setup of lens is preventing the build. Not sure how to avoid it in the call site.

So we have to wait or patch upstream packages. If we would try to install ghcide or hls with plugins the list of pending packages will be interminable so let's start with this one.

Answer 8 · 2021-02-10T12:12:29.000Z

As commented in reddit cabal-3.4.0.0 is required to avoid constraint from maximum version of Cabal used by Setup.hs requires <3.4 in addition to allow-newer: mypkg:Cabal
The binaries are available here

Time to regenerate the index cache 😝

Answer 9 · 2021-02-18T18:45:51.000Z

You can try lens-5, which switched to build-type: Simple and bumped several upper bounds.

Answer 10 · 2021-03-30T09:11:52.000Z

I've managed to get hls-plugin-api to compile by adding a bunch of source-repository-packages with references to the various (mostly unmerged) upstream patches for ghc-9.0.1 support in cabal.project. And by adding

allow-newer:
    *:*,

to the same file.

You can check out this branch: https://github.com/anka-213/haskell-language-server/tree/ghc-9.0.1-with-lsp-1.2

It combines #1635 with #1631 in addition to modifying cabal.project.

Answer 11 · 2021-03-30T12:22:37.000Z

@anka-213 In case it could help, i had a WIP branch over hls here: https://github.com/jneira/haskell-language-server/tree/ghc-9.0.1
It has the (now outdated) list of the precise packages that needed allow-newer at the moment

Answer 12 · 2021-03-30T12:48:04.000Z

@jneira is there a downside to allowing _all_the packages "newer"?

Answer 13 · 2021-03-30T14:19:31.000Z

You could get bad versions that might break the build, out of established bounds in .cabal files so it is advisable to restrict them as much as possible
Otoh they are useful to track what dependencies needs to be chased and patched
It would be very nice that cabal could generate the automatically as @anka-213 suggested in other issue, maybe it would worth a feature request?

Answer 14 · 2021-04-01T07:30:43.000Z

I've managed to get ghcide to compile now, but it fails with the error:

Message:  ghcide: Couldn't find a target code interpreter. Try with -fexternal-interpreter

Does anyone know what that could be caused by?

Answer 15 · 2021-04-01T12:11:33.000Z

For some reason, changing this

env <- runGhc (Just libDir) getSession

to this

env <- runGhc (Just libDir) $ do df <- getSessionDynFlags; setSessionDynFlags df; getSession

worked. The function initDynLinker was sad that the interpreter was not set, which apparently is set as a side effect of calling setSessionDynFlags.

But it is still very far from functional and I get new difficult-to debug errors. :/

Answer 16 · 2021-04-01T14:51:52.000Z

I've gotten ghcide working now!
Check out this branch: https://github.com/anka-213/haskell-language-server/tree/ghc-9.0.1-with-lsp-1.2

I haven't tested it properly with older versions yet, so there are probably some major regressions.

Answer 17 · 2021-06-07T01:55:46.000Z

Should we update the status of this issue now that #1649 has been merged?

Has ghc-9.0.1 support

Formatters

hls-floskell-plugin
hls-brittany-plugin - Blocked upstream by brittany:ghc-lib-parser
hls-fourmolu-plugin - Blocked upstream by fourmolu:ghc-lib-parser
hls-ormolu-plugin - ~~Blocked upstream by ormolu:ghc-lib-parser (tweag/ormolu#688)~~ Only needs to be enabled in stack-ghc9.0.1.yaml and cabal-ghc901.project now that the upstream issue is resolved.
hls-stylish-haskell-plugin - Blocked upstream by stylish-haskell:ghc-lib-parser

Build system and CI

stack-9.0.1.yaml - Disables not-yet-working plugins and fetches upstream patches
cabal-ghc901.project - Used for disabling the not yet working plugins and fetching upstream patches
flake.nix - ~~Needs to fetch upstream patches and disable not-yet-working plugins~~ Fixed by berberberman in #1995
.circleci/config.yml
.github/workflows/test.yml - Uses the custom cabal.project and disables tests for non-working plugins. Needs to be updated when more plugins gain ghc-9.0.1 support
.github/workflows/build.yml - The release script is not updated to make a ghc-9.0.1 release yet (PR #1940)
mergify.io We should probably make it manditory for PRs to successfully build/test on ghc-9.0.1 as well

Answer 18 · 2021-06-08T05:45:58.000Z

Now mergify rules are all dropped in favor of the GitHub branch protection rule, so only thing we need to update is the protection rule.

Answer 19 · 2021-07-05T08:11:23.000Z

flake.nix now supports GHC 9.0.1 (#1995): one can use

nix build .#haskell-language-server-901 to create HLS binary (which I think is extremely useful)
nix develop .#haskell-language-server-901-dev to enter the shell for developing HLS itself

And eval plugin now works as well (#1997).

Answer 20 · 2021-08-02T15:11:34.000Z

Re ghc-code-gen: GHC 9 should be working experimentally at https://github.com/AriFordsham/ghc-source-gen/tree/ari-f-ghc-9 (google/ghc-source-gen#84).

Answer 21 · 2021-08-13T09:10:59.000Z

Re ghc-code-gen: GHC 9 should be working experimentally at https://github.com/AriFordsham/ghc-source-gen/tree/ari-f-ghc-9 (google/ghc-source-gen#84).

Now merged and waiting for Hackage release

Answer 22 · 2021-08-22T13:49:48.000Z

I'm a bit confused: The item list for the formatters has a tick mark for floskell, but looking at stack-9.0.1.yaml seems to indicate that there are no supported formatters at all at the moment.

What's still wrong with ormolu? I've just compiled ormolu itself with a Stackage nightly (using GHC 9.0.1), and everything seems to be fine.

Answer 23 · 2021-08-22T14:35:57.000Z

I am afraid that stack.yaml is not up to date with the cabal.project, and maybe both lacks the already available support for ormolu

Answer 24 · 2021-08-22T15:57:34.000Z

Hmmm, this basically means that this issue is rather useless: It contains tick marks for things not yet done and misses tick marks for things which have already been done... 😞 Is there already a planned date for a 1.4.0 release? Otherwise I will try to compile the HEAD from source, when I find some time...

Answer 25 · 2021-08-22T16:28:19.000Z

I compared cabal-ghc901.project and stack-9.0.1.yaml, and there seem to be more things missing in the latter which are already enabled in the former:

./plugins/hls-class-plugin
./plugins/hls-floskell-plugin
./plugins/hls-ormolu-plugin
./plugins/hls-refine-imports-plugin
./shake-bench

Answer 26 · 2021-08-22T16:39:25.000Z

It contains tick marks for things not yet done

hmm what are those things?

it has become a little bit obsolete, thanks to note it, will update it asap

Answer 27 · 2021-08-22T16:40:34.000Z

I compared cabal-ghc901.project and stack-9.0.1.yaml, and there seem to be more things missing in the latter which are already enabled in the former:

./plugins/hls-class-plugin

./plugins/hls-floskell-plugin

./plugins/hls-ormolu-plugin

./plugins/hls-refine-imports-plugin

./shake-bench

nice, thanks to check them, do you wish to open a pr to update stack.yaml?

Answer 28 · 2021-08-22T16:51:16.000Z

To get things in a sane state again, any changes should best be done by someone with the rights to change the .project/.yaml and the tick marks at the beginning of this ticket. I didn't even compare all tick marks, but e.g. floskell has a mark, while it's still commented out in the .yaml.

Somehow the whole process seems to be a bit too manual, keeping 3 places in sync never works in any project I've seen, even only 2 places are enough to get lots of inconsistencies.

Answer 29 · 2021-08-22T17:11:04.000Z

Yeah, but we need both cabal.project and stack.yaml to have support for both build tools, they are the source of truth cause hls built with each one does not include the plugins if they are not enabled in each config file. floskell is enabled in the cabal.project

The issue is only informative. You can't edit the first one but can comment with the new version and some maintainer can use it to update the main one then. And a pr updating the stack.yaml would be a good start ☺️

Answer 30 · 2021-08-23T06:24:29.000Z

I'm a bit confused: The item list for the formatters has a tick mark for floskell, but looking at stack-9.0.1.yaml seems to indicate that there are no supported formatters at all at the moment.

Oh, sorry, I forgot to add that to the stack.yaml in the initial release.

What's still wrong with ormolu? I've just compiled ormolu itself with a Stackage nightly (using GHC 9.0.1), and everything seems to be fine.

Nothing's wrong with ormolu. This issue and the cabal.project and stack.yaml files hasn't been updated since that issue was resolved, that's all.

Answer 31 · 2021-08-26T13:27:09.000Z

packages which should be updated to get ghc-9.0 support without cabal.project source-repository-package or allow-newer, with the issue tracking the support:

blaze-textual: swamp-agr/blaze-textual#14
czipwith: lspitzner/czipwith#2
th-extras: mokus0/th-extras#8
hie-bios: haskell/hie-bios#300 (needs hackage release)
dependent-sum: obsidiansystems/dependent-sum#57 (still a draft 😢 )
ghc-api-compat: we are about to drop the depenency thanks to @fendor
operational (shake-bench dependency): HeinrichApfelmus/operational#26 (needs hackage release)

(moved to the issue description)

Answer 32 · 2021-08-27T13:49:44.000Z

I've opened #2131 to:

updating and cleaning up cabal-ghc901.project
same for stack-9.0.1,yaml, enabling all supported plugins already available for cabal

Answer 33 · 2021-09-27T06:45:53.000Z

Updated description with the state of the support

Answer 34 · 2021-10-04T10:10:16.000Z

Support for fourmolu with #2254

Answer 35 · 2021-10-29T17:06:59.000Z

FWIW, GHC 9.2.1 is now released: https://discourse.haskell.org/t/ghc-9-2-1-released/3527

Answer 36 · 2021-11-05T01:37:39.000Z

Should this issue be closed, as HLS 1.4.0 seems to support GHC-9.0.1?

Answer 37 · 2021-11-05T05:09:48.000Z

@mouse07410 There are still a few plugins that doesn’t support GHC-9.0.1 yet, as can be seen in the checklist.

Answer 38 · 2021-11-20T19:23:38.000Z

czipwith and th-extras already has 9.0.1 support in hackage

Answer 39 · 2021-12-12T13:02:53.000Z

brittany solved mentioned report & release 0.14 with 9.0.2 support got published: https://hackage.haskell.org/package/brittany-0.14.0.0/changelog

Part of the configuration code: #2473, I closed that to be non-blocking to others.

The plugin for brittany process would be open to continuation after #297.

Answer 40 · 2022-03-18T13:51:41.000Z

Seems stylish-haskell-0.14.0.0 supports GHC 9.0 now. Any chance we're going to have it?

Answer 41 · 2022-03-19T10:52:28.000Z

Seems stylish-haskell-0.14.0.0 supports GHC 9.0 now. Any chance we're going to have it?

Unfortunately hlint requires ghc-lib-parser ==9.0 whereas stylish-haskell wants ==9.2, so no way to build HLS with both.

Answer 42 · 2022-03-19T10:54:27.000Z

Unfortunately hlint requires ghc-lib-parser ==9.0 whereas stylish-haskell wants ==9.2, so no way to build HLS with both.

Yes, I noticed that shortly after and filed an issue for stylish-haskell: haskell/stylish-haskell#391

Answer 43 · 2022-05-20T05:16:35.000Z

I think we have fully supported ghc-9.0.

Support for GHC-9.0

State of support

Has ghc-9.0 support

Formatters

Build system and CI

Dependencies which needs updates and hackage release

Dependencies needed to inlcude brittany in hackage for 9.0:

Has ghc-9.0.1 support

Formatters

Build system and CI