Support for GHC-9.0

[mouse07410]

State of support

• The core functionality of haskell-language-server is supported.
• Only some plugins and formatters needs to be updated to make it work with ghc-9.0.1 so they are not included until then.
• So you should consider use other ghc version only if you are specially interested in those plugins o formatters

Has ghc-9.0 support

• ghcide
• haskell-language-server
• hls-haddock-comments-plugin
• hls-hlint-plugin
• hls-importlens-plugin
• hls-pragmas-plugin
• hls-retrie-plugin
• hls-eval-plugin Eval plugin: support ghc 9.0.1 #1997
• hls-module-name-plugin - Actually builds just fine. Was accidentally disabled
• hls-class-plugin - Class plugin bump up #2475
• hls-refine-imports-plugin - All deps build
• hls-splice-plugin - All deps build
• hls-tactic-plugin
  • Blocked upstream by ghc-source-gen (Support GHC 9 google/ghc-source-gen#77 / Add GHC 9 support google/ghc-source-gen#84)
  • Disabled some tests in GHC9 because they expect Wingman to build. See Disable hole fit suggestions when running Wingman #1873 and the expectFailIfGhc9 function
  • Pull request in progress: WIP: GHC-9.0 support for hls-tactics-plugin #2202
  • Finally added with Post ghc-9.2.1 config cleanup #2582, follow up of the previous one

Formatters

• hls-floskell-plugin
• hls-ormolu-plugin - Support added with Switch to ghc-lib-parser-9.0.1.xxx tweag/ormolu#688
• hls-brittany-plugin - Blocked upstream by brittany:ghc-lib-parser (Support for ghc-9.0.1 lspitzner/brittany#352)
• hls-fourmolu-plugin - Bump Fourmolu to 0.4 #2254
• hls-stylish-haskell-plugin blocked upstream by
  • stylish-haskell:ghc-lib-parser (Support for ghc-9.0.1 stylish-haskell#378)
  • Add support for aeson >= 2.0 stylish-haskell#387

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 (nix: add support for ghc 9.0.1 #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 Add ghc-9.0.1 to the build release script #1940)
• mergify.io We should probably make it manditory for PRs to successfully build/test on ghc-9.0.1 as well

Dependencies which needs updates and hackage release

• blaze-textual: Allow build for GHC 9.0 swamp-agr/blaze-textual#14. Released in hackage.
• czipwith: Fix GHC 9 compatibility lspitzner/czipwith#2.
• th-extras: Add support for ghc-9.0.1 mokus0/th-extras#8. Needs hackage release: Upload to Hackage mokus0/th-extras#10
• hie-bios: Add compatibility for GHC 9.0 and 9.2 hie-bios#300 (needs hackage release)
• dependent-sum: Add support for GHC-9.0.1 obsidiansystems/dependent-sum#57. Needs hackage release, see New release with ghc 9 compat obsidiansystems/dependent-sum#65
• ghc-api-compat: Drop ghc-api-compat from dependency closure #2128
• operational (shake-bench dependency): Fix build for GHC 9.0.1 HeinrichApfelmus/operational#26 (needs hackage release Hackage release with 9.0.1 support HeinrichApfelmus/operational#29)
  • Support added with Remove custom version of operational #2249

Dependencies needed to inlcude brittany in hackage for 9.0:

• multistate: Allow base 4.15 lspitzner/multistate#8, finally added with Fix build with GHC 9.2.1 lspitzner/multistate#11
• data-tree-print: Allow base < 4.17 and ghc <= 9.2.1 lspitzner/data-tree-print#3
• butcher: Support for base-4.15 and ghc-9.0.* lspitzner/butcher#8

[jneira]

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

• regex-tdfa:base,
• regex-base:base,
• lens:template-haskell,
• lens:setup
• parallel:base,
• haskell-lsp:base, (we are about to change it as the new package lsp that has the upper bound on 4.15 too)
• haskell-lsp-types:base, (same as haskell-lsp)
• hashable:base,
• time-compat:base,
• these:base,
• assoc:base,
• deepseq:base,
• hslogger:base

//cc @Kleidukos

[jneira]

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 😄

[poscat0x04]

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

[jneira]

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

[konn]

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.

[jneira]

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

[jneira]

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.

[jneira]

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 😝

[Bodigrim]

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

[anka-213]

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.

[jneira]

@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

[mouse07410]

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

[jneira]

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?

[anka-213]

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?

[anka-213]

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. :/

[jneira]

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

[jneira]

• Updated description with the state of the support

[jneira]

Support for fourmolu with #2254

[Ailrun]

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

[mouse07410]

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

[anka-213]

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

[jneira]

czipwith and th-extras already has 9.0.1 support in hackage

[Anton-Latukha]

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.

[re-xyr]

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

[pepeiborra]

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.

[re-xyr]

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

[July541]

I think we have fully supported ghc-9.0.