HLS not working within GHC (meta improve troubleshooting)

[goldfirere]

Your environment

Output of haskell-language-server --probe-tools or haskell-language-server-wrapper --probe-tools:
I don't know. Neither of these executables is on my PATH, and I don't know where they are. HLS was installed by VS Code. I'm pretty sure I saw a notification recently that HLS was being upgraded to 1.5.0. Happy to give you more information if told how to retrieve the information.

Which OS do you use: MacOS
Which lsp-client do you use: VS Code
Describe your project (alternative: link to the project): GHC

Steps to reproduce

Open an editor to a GHC source file, and see that nothing from HLS works.

Expected behaviour

HLS should do stuff, like allow me to jump to a definition, or give me the type of something by pointing at it.

Actual behaviour

Nothing. It's like HLS is off. When I looked at the Problems pane, I briefly saw a message saying (I think) that ghcide was compiled against GHC 8.10.7 while GHC 8.10.5 is the one installed. I can't tell you the error message exactly because it disappeared while I was looking at it. I don't know how to get it back. I have nothing called ghcide in my PATH.

Include debug information

Execute in the root of your project the command haskell-language-server --debug . and paste the logs here:
I don't have haskell-language-server in my PATH, and I don't know where it is, so I can't do this. :(

Paste the logs from the lsp-client, e.g. for VS Code:
I don't know how to do this. That link did not contain any instructions for how to produce logs for lsp-client.

Other background info

In other work, I did change the GHC in my path several times today, including GHC 8.10.7 for a little while. With GHC 8.10.7, I installed the newest cabal-install. (I would have used GHC 8.10.5, my main version of GHC these days, but I was caught by haskell/network#518, which required using a higher GHC.) But I did nothing with anything called ghcide.

HLS appears to work on non-GHC projects. The GHC tree I'm working in was built bootstrapping from GHC 8.10.5.

I suppose I could just upgrade to GHC 8.10.7. But I have a bunch of trees bootstrapped from GHC 8.10.5, and so doing this would require quite a bit of rebuilding.

Any advice about how to get myself unstuck -- or, even better, how I can learn more about what's going on -- is appreciated. Thanks!

[michaelpj]

I'm going to be annoying and not help with the object-level problem (no idea, sorry!) but just list a number of issue-reporting problems that Richard's helpful stream-of-consciousness report made me notice:

• The issue template should link to the Troubleshooting doc page and ask people to read it before opening an issue.
• The Troubleshooting doc page doesn't list the "HLS compiled with the wrong version of GHC" issue, although I suspect it's a common one.
• The issue template should tell users of the vscode extension to consult the docs for the extension to find out where their binaries are installed to. If the extension docs don't say where to find them, we should add that.
• The issue template should link to how to get client logs. This could go via the Troubleshooting section on troubleshooting the client (which does tell you how to get the vscode logs!).
• Do setup issues like mismatched GHC versions get reported well in all the clients we know of, especially vscode? Can we improve it if not?
• The troubleshooting section in the vscode extension docs could be extended a lot, and should probably also link to the HLS troubleshooting page.

[jneira]

Hi, thanks for the detailed report. Some notes about the problem itself

Nothing. It's like HLS is off. When I looked at the Problems pane, I briefly saw a message saying (I think) that ghcide was compiled against GHC 8.10.7 while GHC 8.10.5 is the one installed. I can't tell you the error message exactly because it disappeared while I was looking at it. I don't know how to get it back. I have nothing called ghcide in my PATH.

To load standalone ghc files hls uses the ghc in PATH, from the report i guess it is ghc-8.10.5 when hls stops to work.
Otoh hls-1.5.0 has dropped support for ghc-8.10.5. It seems it picked at some point the hls version suited for 8.10.7 which produces the mismatch and the error message. But i would expect the hls executable cant even start.

ghcide is the ide core library which talks with ghc and the error is produced in that library. As theoretically ghcide could be used for other lsp servers executables (and it has a executable named ghcide!) it mentions itself instead hls. Maybe we should replace it with something generic as lsp server, ide or something alike.

There is an issue about how to handle ghc deprecation in the vscode repo: haskell/vscode-haskell#504. There you can find some workarounds to continue using ghc-8.10.5 while we add support in the extension for ghc versions not supported by the last hls version. Issue here: haskell/vscode-haskell#454 and a pr trying to implement it here: haskell/vscode-haskell#506

[goldfirere]

Thanks for this info @jneira. I'm surprised to see that hls-1.5.0 dropped support for ghc-8.10.5, because my understanding of https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html is that ghc-8.10.5 is still supported by hls-1.5.0 -- although deprecated. I would expect, say, a warning at startup saying that dropped support is imminent, but my reading of that table is that ghc-8.10.5 should still work.

haskell/vscode-haskell#504 is about ghc-8.10.4, which I read as unsupported by hls-1.5.0, and so I didn't think it was relevant to my situation.

Maybe I've just misunderstood the table?

And, thanks @michaelpj for extracting out some other meta-items from my post. I did look at the Troubleshooting page (https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html) before filing, but I couldn't find an item on that page that felt actionable. The "Troubleshooting the server" section looks promising, but the different items all talk about executing haskell-language-server, which I don't know how to locate or execute. Even if I did locate it and execute it manually, would VS Code know to talk to the one I launched instead of its own self-launched process? I don't know how to mediate that interaction. There is this sentence "Please consult the documentation for your client to find out where this is (or how to set it)." which suggests to look elsewhere for more info (good: it makes me feel like I'm not expected to know this already), but I don't concretely know where to look. Searching "vscode haskell" gets me to https://marketplace.visualstudio.com/items?itemName=haskell.haskell, but that page does not talk about logfiles. So I have found the Troubleshooting page to be unhelpful.

@michaelpj also says

The issue template should link to how to get client logs. This could go via the Troubleshooting section on troubleshooting the client (which does tell you how to get the vscode logs!).

In Troubleshooting the client, I see some information about getting logs from emacs, but not from VSCode. Am I looking in the wrong place?

Full disclosure: I am intentionally not using my sharpest weapon in these explorations. I could, for example, start looking through the VSCode Haskell extension's source code and HLS's source code, learn more about how they all interact, and likely figure all of this out. But I am not doing so, for two reasons: 1. That takes a lot of time! and 2. I am trying to offer myself up as something of a guinea pig to try to improve documentation, etc., so that others have an easier time after me. I am looking at troubleshooting pages and trying to follow actions that present themselves to me, but I'm trying squarely to keep my "intermediate Haskell user" hat on, not my "GHC type-checker grease monkey" hat on. I very much appreciate all the efforts you all are doing in this space -- I hope you see my comments as contributions in an effort to make your work more usable, not as an obstacle!

[jneira]

Oh yeah, I was wrong about the deprecate ghc version and hls-1.5.0 still supports ghc-8.10.5 (its support will be removed in hls-1.6.0). Sorry for the confusion 🤦‍♂️

[jneira]

Ok we have two edges in the issue. Lets handle the meta one. Thanks both for the analysis and suggestion, agree almost completely

• The issue template should link to the Troubleshooting doc page and ask people to read it before opening an issue.
  • with [skip circleci] Add modern issue templates #2394
• The Troubleshooting doc page doesn't list the "HLS compiled with the wrong version of GHC" issue, although I suspect it's a common one.
• The issue template should tell users of the vscode extension to consult the docs for the extension to find out where their binaries are installed to. If the extension docs don't say where to find them, we should add that.
  • The extension does it: https://github.com/haskell/vscode-haskell#downloaded-binaries
  • But it should be mentioned explicitly you should use them for recollect logs
  • Linked directly in the issue template in [skip circleci] Add modern issue templates #2394
• The issue template should link to how to get client logs. This could go via the Troubleshooting section on troubleshooting the client (which does tell you how to get the vscode logs!).
  • As mentioned by @goldfirere in does not talk abour vscode. But the extension itself does it: https://github.com/haskell/vscode-haskell#investigating-and-reporting-problems. So we should link the issue template and the "trroubleshooting the client" section in hls with the vscode readme
  • EDIT: The issue template already is linking to the vscode troubleshooting section (Paste the logs from the lsp-client, e.g. for [VS Code](https://github.com/haskell/vscode-haskell#troubleshooting))
• Do setup issues like mismatched GHC versions get reported well in all the clients we know of, especially vscode? Can we improve it if not?
  • It is the goal of a new issue: Report error conditions via LSP message dialogs #2390
• The troubleshooting section in the vscode extension docs could be extended a lot, and should probably also link to the HLS troubleshooting page.
  • It already link the issue tracker of hls but it should link the server doc section too

---

Searching "vscode haskell" gets me to https://marketplace.visualstudio.com/items?itemName=haskell.haskell, but that page does not talk about logfiles.

In fact https://marketplace.visualstudio.com/items?itemName=haskell.haskell has the readme embedded and it includes the location of the binaries and the mentioned "reporting errors and troubleshooting" section (at the bottom of the page)
It should be more discoverable and i think @michaelpj suggestions will help with that

Paste the logs from the lsp-client, e.g. for VS Code:
I don't know how to do this. That link did not contain any instructions for how to produce logs for lsp-client.

The link to vscode has some info on how to extract those logs, could be those instructions improved?

EDIT: I've rephrased the issue template to make it clearer

---

More context:

• i opened an issue in the vscode extension which might help a lot with error reporting: Open automatically a new issue on a server or client error vscode-haskell#482
• the issue template was redacted before vscode downloaded auto hls so it assumed users will know its location. There is an issue about Issue template doesn't work (make easier generate bug report info with no executable in path) #621
• and another one with some other improvements: Improve Github Issue Template #388

[jneira]

And now the concrete issue about the hls setup:

Nothing. It's like HLS is off. When I looked at the Problems pane, I briefly saw a message saying (I think) that ghcide was compiled against GHC 8.10.7 while GHC 8.10.5 is the one installed. I can't tell you the error message exactly because it disappeared while I was looking at it. I don't know how to get it back. I have nothing called ghcide in my PATH.

I hope now that we could recollect the logs following the vscode troubleshooting section (without waiting to the meta improvements 😉), we would have enough info to trace the cause.