HLS current version incompatability problem

houseofwealth commented 2 years ago

Your environment

Which OS do you use: Windows 10

Which LSP client (editor/plugin) do you use:

VS Code 1.68.1

Describe your project (alternative: link to the project):

haskell project built using Stack. stack.yaml resolver: lts-14.21.

Steps to reproduce

After installing the Haskell Language extension, try to browse for a definition within a file. VS Code reports a Problem with the file as described below

Expected behaviour

Should jump to the definition

Actual behaviour

ghcide compiled against GHC 9.2.2 but currently using 8.6.5 
This is unsupported, ghcide must be compiled with the same GHC version as the project.

The HLS page says that the current version of HLS supports 8.6.5, which does not appear to be the case. It is not clear what version of HLS should be used. This is supposed to work without needed ghcup

Include debug information

fendor commented 2 years ago

It seems a bit lost in the documentation, but you need to compile HLS with the same GHC version you want to use in your project. In this case, if you need GHC 8.6.5, you need to compile HLS with GHC 8.6.5 and this message will vanish.

To do that, the recommended way is to use cabal via cabal install -w ghc-8.6.5 or something similar.

michaelpj commented 2 years ago

Well, it sounds like @houseofwealth is using the vscode extension, so that should have downloaded the appropriate wrapper, right? So something has gone wrong there.

fendor commented 2 years ago

They are deliberately not using ghcup, see this issue: https://github.com/haskell/vscode-haskell/issues/630

michaelpj commented 2 years ago

It seems a bit lost in the documentation

I disagree that it's buried in the docs, it's in the section on installing from source, I'm not sure where else it would be: https://haskell-language-server.readthedocs.io/en/latest/installation.html#installation-from-source

houseofwealth commented 2 years ago

OK thanks for that clarification. I wasn't aware that I needed to compile it from source - I just downloaded the supplied binary. I will try that out and let you know

michaelpj commented 2 years ago

I actually have no idea how you obtained your HLS binaries, you didn't say :)

houseofwealth commented 2 years ago

Its on that same page https://haskell-language-server.readthedocs.io/en/latest/installation.html#pre-built-binaries

houseofwealth commented 2 years ago

So i tried the stack install --stack-yaml stack-<GHCVER>.yaml command but where is the stack-8.6.5.yaml to be found?

houseofwealth commented 2 years ago

I also pulled the source from github, and ran "stack build" but stack seems to think that it needs to build it with ghc 9.x which is definitely not what I want, since that was the source of the original problem, it needs to build it with ghc 8.6.5. . I am not sure if this is the way to go or not, I just thought I'd try it out

drsooch commented 2 years ago

I also pulled the source from github, and ran "stack build" but stack seems to think that it needs to build it with ghc 9.x which is definitely not what I want, since that was the source of the original problem, it needs to build it with ghc 8.6.5.

. I am not sure if this is the way to go or not, I just thought I'd try it out

Looks like our oldest stack.yaml is for 8.8.4. You can try to search the commit history for the 8.6.5 stack.yaml file.

fendor commented 2 years ago

Its on that same page https://haskell-language-server.readthedocs.io/en/latest/installation.html#pre-built-binaries

Easy fix then, download the release binaries for hls 8.6.5, or point the server executable path to the haskell-language-server-wrapper.

I disagree that it's buried in the docs

I am, as usual, completely blind. I don't know why I have such a hard time reading our own docs 😅

lsmor commented 2 years ago

Disclaimer: I've seen some legit complaints like this thread in the last couple of months. This is a summary of what I've seen and what I've tested myself, but since this is very system dependant I am not completely sure about all the claims.

Some behaviours should be properly documented since it seems to be dispersed around multiple pages. I am refering to the following problems:

If you let stack to install ghc on its own, then hls is not happy with it and sends a message of "failing x times in 3 minutes" or something like that. This is somewhat documented in the releases page as: If you get your GHC binaries from a source other than https://downloads.haskell.org/ (or GHCup), then you will need to build HLS from source yourself.
In the very same releases page, there is nothing about haskell-language-server-wrapper. This information is on the pre-built binaries section. I think many people simply don't read the whole paragraph, they jump straight to the release page and download hls but not the wrapper.
It is not clear that hls is actually a collection of binaries. This is specified in hls's home page but not in the releases page nor the pre-built binaries section (so we have a third source of truth). This causes that people downloading hls ask themself how do they get the version compiled with the ghc they are planning to use, because they don't know that hls actually is a collection and you need the wrapper to conviniently select the right one.
The default behaviour of haskell-extension in vscode is to manage hls using PATH instead of ghcup. I understand it is a sensible default, but if you are using an old project built with stack, likely you are using stack's version of ghc which makes hls sad (as stated before). If you change that setting to manage with ghcup, you'll be prompted with ghc-X.X.X needs to be installed, which is confusing because you know stack has downloaded ghc.

In summary:

As far as I know, stack users must prevent it to install its own version of ghc. This can be done by setting it on the stack.yaml file or by setting it globaly with stack config set install-ghc --global false && stack config set system-ghc --global true
Users manualy downloading binaries should be aware that they must download hls and hls-wrapper. Again, if they are stack users, then ghc must be download from ghcup or from https://downloads.haskell.org/ but not via stack.
Users using ghcup should be recommended to change default settings of the vscode haskell extension

I think It would be convinient a page in the documentation like how to set up a develoment enviroment. Ideally this section should be completely straightfoward (a few commands and indications, that's it.). If you are happy with this, I am willing to write such a guide.

haskell / haskell-language-server