Closed mouse07410 closed 2 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
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:
Now that ghc 9.0.1 has been released, maybe we should bump up the priority?
Yeah, but i guess it will be a complex change, given we are totally tied to ghc
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.
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.
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.
You can try lens-5
, which switched to build-type: Simple
and bumped several upper bounds.
I've managed to get hls-plugin-api
to compile by adding a bunch of source-repository-package
s 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
.
@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
@jneira is there a downside to allowing _all_the packages "newer"?
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?
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?
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. :/
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.
Should we update the status of this issue now that #1649 has been merged?
ghcide
haskell-language-server
hls-haddock-comments-plugin
hls-hlint-plugin
hls-importlens-plugin
hls-pragmas-plugin
hls-retrie-plugin
hls-module-name-plugin
- Actually builds just fine. Was accidentally disabledhls-eval-plugin
- hls-class-plugin
- #2475hls-refine-imports-plugin
- All deps build (needs ghc-api-compat)hls-splice-plugin
- All deps build (needs ghc-api-compat)hls-tactic-plugin
- hls-floskell-plugin
hls-brittany-plugin
- Blocked upstream by brittany:ghc-lib-parserhls-fourmolu-plugin
- Blocked upstream by fourmolu:ghc-lib-parserhls-ormolu-plugin
- 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-parserstack-9.0.1.yaml
- Disables not-yet-working plugins and fetches upstream patchescabal-ghc901.project
- Used for disabling the not yet working plugins and fetching upstream patchesflake.nix
- .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 wellNow mergify rules are all dropped in favor of the GitHub branch protection rule, so only thing we need to update is the protection rule.
flake.nix
now supports GHC 9.0.1 (https://github.com/haskell/haskell-language-server/pull/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 itselfAnd eval plugin now works as well (https://github.com/haskell/haskell-language-server/pull/1997).
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).
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
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.
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
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...
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
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
I compared
cabal-ghc901.project
andstack-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?
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.
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 ☺️
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.
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)
I've opened #2131 to:
Support for fourmolu with #2254
FWIW, GHC 9.2.1 is now released: https://discourse.haskell.org/t/ghc-9-2-1-released/3527
Should this issue be closed, as HLS 1.4.0 seems to support GHC-9.0.1?
@mouse07410 There are still a few plugins that doesn’t support GHC-9.0.1 yet, as can be seen in the checklist.
czipwith
and th-extras
already has 9.0.1 support in hackage
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.
Seems stylish-haskell-0.14.0.0
supports GHC 9.0 now. Any chance we're going to have it?
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.
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
I think we have fully supported ghc-9.0.
State of support
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
#1997hls-module-name-plugin
- Actually builds just fine. Was accidentally disabledhls-class-plugin
- #2475hls-refine-imports-plugin
- All deps buildhls-splice-plugin
- All deps buildhls-tactic-plugin
expectFailIfGhc9
functionFormatters
hls-floskell-plugin
hls-ormolu-plugin
- Support added with https://github.com/tweag/ormolu/issues/688hls-brittany-plugin
- Blocked upstream by brittany:ghc-lib-parser (https://github.com/lspitzner/brittany/issues/352)hls-fourmolu-plugin
- #2254hls-stylish-haskell-plugin
blocked upstream byBuild system and CI
stack-9.0.1.yaml
- Disables not-yet-working plugins and fetches upstream patchescabal-ghc901.project
- Used for disabling the not yet working plugins and fetching upstream patchesflake.nix
- Needs to fetch upstream patches and disable not-yet-working plugins (#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 wellDependencies which needs updates and hackage release
Dependencies needed to inlcude brittany in hackage for 9.0: