search

haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.
Apache License 2.0
2.71k stars 368 forks source link

Support for GHC-9.0 #297

Closed mouse07410 closed 2 years ago

mouse07410 commented 4 years ago

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:

jneira commented 3 years ago

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

jneira commented 3 years ago

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 :smile:

poscat0x04 commented 3 years ago

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

jneira commented 3 years ago

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

konn commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 :stuck_out_tongue_closed_eyes:

Bodigrim commented 3 years ago

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

anka-213 commented 3 years ago

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 https://github.com/haskell/haskell-language-server/pull/1635 with #1631 in addition to modifying cabal.project.

jneira commented 3 years ago

@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 commented 3 years ago

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

jneira commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

anka-213 commented 3 years ago

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.

anka-213 commented 3 years ago

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

Has ghc-9.0.1 support

Formatters

Build system and CI

Ailrun commented 3 years ago

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.

berberman commented 3 years ago

flake.nix now supports GHC 9.0.1 (https://github.com/haskell/haskell-language-server/pull/1995): one can use

And eval plugin now works as well (https://github.com/haskell/haskell-language-server/pull/1997).

AriFordsham commented 3 years ago

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

AriFordsham commented 3 years ago

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

svenpanne commented 3 years ago

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.

jneira commented 3 years ago

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

svenpanne commented 3 years ago

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

svenpanne commented 3 years ago

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:

jneira commented 3 years ago

 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

jneira commented 3 years ago

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?

svenpanne commented 3 years ago

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.

jneira commented 3 years ago

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 ☺️

anka-213 commented 3 years ago

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.

jneira commented 3 years ago

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:

(moved to the issue description)

jneira commented 3 years ago

I've opened #2131 to:

jneira commented 3 years ago
jneira commented 3 years ago

Support for fourmolu with #2254

Ailrun commented 2 years ago

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

mouse07410 commented 2 years ago

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

anka-213 commented 2 years ago

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

jneira commented 2 years ago

czipwith and th-extras already has 9.0.1 support in hackage

Anton-Latukha commented 2 years ago

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: https://github.com/haskell/haskell-language-server/pull/2473, I closed that to be non-blocking to others.

The plugin for brittany process would be open to continuation after https://github.com/haskell/haskell-language-server/issues/297.

re-xyr commented 2 years ago

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

pepeiborra commented 2 years ago

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 commented 2 years ago

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: https://github.com/haskell/stylish-haskell/issues/391

July541 commented 2 years ago

I think we have fully supported ghc-9.0.