Haskell Language Server 1.9.0.0 released

Binaries for this release are available at Index of /~hls/haskell-language-server-1.9.0.0/

The prebuilt binaries in this release support the following GHC versions:

  • 8.10.7
  • 9.0.2
  • 9.2.5
  • 9.4.3
  • 9.4.4

These binaries can be installed using GHCup or version 2.0.0 and above of the VSCode extension.

Changelog

  • Binaries for GHC 9.4.3, GHC 9.4.4 and GHC 9.2.5.
  • Dropped support for GHC 8.6 and GHC 8.8.
  • New plugins including:
    • Expanding record wild cards using hls-explicit-record-fields-plugin (#3304).
    • Formatting cabal fields using cabal-fmt via hls-cabal-fmt-plugin (#2047).
    • Warnings and errors for cabal files using hls-cabal-plugin (#2954).
    • Folding ranges using hls-code-range-plugin (#3058).
  • Support for many plugins like the refactor, splice, retrie, gadt, hlint, fourmolu and class plugins.
  • Completion for record dot fields (#3080).
  • Performance and memory usage improvements.
  • And many more bug fixes and improvements!

For the full release notes, see Release 1.9.0.0 · haskell/haskell-language-server · GitHub

20 Likes

Is wingman pluging supported for 9.X? last time I tried I wasn’t

I am afraid it is not… This is mea culpa. I completed the vast majority of the work for this migration and fell behind with various non-OSS obligations these last few weeks.

It’s a real shame and I’m kicking myself, because it actually compiles and mostly works, but I didn’t spend the time fixing the test suite…

Sorry :confused: I’ll try to find some time over Christmas…

3 Likes

Not your fault. Thanks for the awesome work! :slight_smile: I’d like to contribute, but I am afraid I don’t know that much about LSP nor wingman nor GHC.

1 Like

Hi there,

Has it happened to anyone else that neither GHCup nor the vscode-haskell extension can upgrade HLS to the version 1.9.0.0 for X86_64 darwin?

N.

1 Like

There’s a PR adding it to ghcup metadata: Add metadata for HLS 1.9.0.0 by wz1000 · Pull Request #54 · haskell/ghcup-metadata · GitHub

I haven’t merged it yet, because it turns out there is an unadvertized bindist (Fedora 27) that could fix a lot of the glibc issues.

So we’re evaluating whether to change the existing GHC bindist mapping and whether to rebuild HLS binaries.

Release coordination is complicated here. GHCup depends on GHC to provide binaries, HLS depends on GHCup to build binaries and then GHCup depends on HLS to provide binaries. If we get something minor wrong like using a too new glibc as a catch-all fallback for unknown linux distros, then it’s large breakage.

We’ve been trying to improve communication and coordination here. It has improved, but is still not enough.

Please bear with us.

(Also: I think we shouldn’t do releases during Christmas time)

10 Likes

+1

Post must be at least 20 characters

This HLS version is now published in ghcup.

The “glibc too new” issue that may affect ubuntu derivates may still exist. It will be fixed in 9.4.5. Workarounds are complicated.

The next GHCup release will make one of these workarounds easier by allowing to fake a distro: Allow to statically overwrite distro detection, fixes #421 · haskell/ghcup-hs@e924ad8 · GitHub

1 Like

Hi,

first thank you very much for your great work there (and of course to the team).

It’s probably some combination on my machine but I’m experiencing problems with the 1.9.0.0 binary (the 1.8.0.0 locally compiled for 9.2.5 works great).

I’m still trying to figure out what exactly fails/makes problems here but when I open a project/folder with VS code that is a symbolic link to another folder the plugin seems to get confused (you see multi-cradle errors where the actual and linked folders are mentioned) - also there seems to be some kind of loop where I see “project 2/60” over and over again in the status-bar of vs code.
Finally HLS seems to work but when I “goto source” via F12 it does not in this file (when I navigate to the file via Files in VS code it works.)

I’m trying to find a minimal repro of this issue and might file an issue but for now I’ll stick with 1.8.0.0

1 Like

I updated my Fedora Copr repo to 1.9 over the weekend:
https://copr.fedorainfracloud.org/coprs/petersen/haskell-language-server/
with builds for Fedora ghc, ghc9.0, ghc9.2 and ghc9.4.

1 Like