Duplicate hints, popups, and processes opening project + standalone files

[robrix]

I’ve got a weird issue where hints, popups, etc. get duplicated. See for example this screenshot, where I have not one, but two lovely hovers showing the type of the symbol I’ve moused over, as well as duplicated suggestions above the imports to list their imported symbols explicitly:

This was pretty baffling to me until I noticed that I’ve got not one, but two lovely haskell-language-server-wrapper & haskell-language-server-8.10.2 processes running 😄

I’ve only got the one workspace open (and nothing else using hls), and the process group indicates that they were indeed launched by VS Code:

If I kill one of them, it gets relaunched, but relaunching VS Code generally gets it back down to one. I’ve had mixed results with this, however, and with reloading the window; when I first noticed this, it was spawning double processes on reload/relaunch too, and eventually I had to close all the panes in one editor group, close the editor group, and relaunch VS Code before it resolved and I could open the editor group and keep going with only a single set of processes. But eventually it happened again; unfortunately, I don’t know why.

I am using ghc 8.10.2 and the following HLS version, both installed via ghcup:

❱ haskell-language-server-8.10.2 --version
haskell-language-server version: 0.4.0.0 (GHC: 8.10.2) (PATH: /Users/rob/.ghcup/bin/haskell-language-server-8.10.2~0.4.0) (GIT hash: 0a18edde24923251a148cbbc0ae993a6aac83b9c)

I have v1.1.0 of this VS Code extension, v3.3.0 of the Haskell syntax extension, and have been using Version: 1.49.2 of VS Code itself, although it tells me there is an update so I will install it presently.

[lukel97]

I've noticed this as well, it happens to me when two or more standalone files are opened, and HLS actually provides code lenses etc. for all the documents. Was this happening when you were opening a folder though?

[robrix]

I've noticed this as well, it happens to me when two or more standalone files are opened,

I don’t know what you mean by standalone.

and HLS actually provides code lenses etc. for all the documents. Was this happening when you were opening a folder though?

I don’t know what you mean by opening a folder. I was working on files all in the same workspace, scoped under the same hie.yaml file. Might’ve had some unsaved scratch documents in Haskell mode, too, but not routinely.

[robrix]

I think I’ve isolated the cause: when you copy some code from one file, make a new empty buffer, and immediately paste that code in, VS Code changes the new (unsaved) buffer’s language mode to the language of the code you copied in. So if you copy some Haskell code into an empty buffer temporarily, you have an (unsaved) Haskell file, which the extension then tries to work with; but (presumably because it doesn’t actually exist as a file within the project) it doesn’t use the existing hls process but rather spins up a new one.

I don’t know why that causes the Haskell files which are actually in the project to ask for & disply results from both hls processes—it really does seem like the new process loads the whole project and not just the one file cos its memory usage is disproportionate for just a single buffer—but since I’ve started being careful about my empty buffers, I’ve stopped having duplicate processes & results, which was otherwise a daily occurrence.

[robrix]

(I suspect this is what @bubba meant by standalone, above.)

[viluon]

I can reproduce what @robrix said. Having two unnamed buffers open alongside a regular Haskell project produces 3x the code lenses, 3x the quick actions, 3 hovers for each identifier, etc:

Closing one of the unnamed Haskell buffers and reloading the window gets it down to 2:

Switching the other to plain text and reloading again gets it down to one:

[jneira]

With vscode i get other behaviour: if i open a cabal based project and then 2 standalone files, they are not loaded cause the hls instance for the file uses the cradle of the project. As the file dont match any of the cradle paths, they show errors:

Multi Cradle: No prefixes matched
pwd: d:\dev\ws\haskell\cabal-test
filepath: D:\dev\ws\haskell\issues\lts\Module.hs
prefixes:
("src",Cabal {component = Just "lib:cabal-test"})
("win-src",Cabal {component = Just "lib:cabal-test"})
("nix-src",Cabal {component = Just "lib:cabal-test"})
("app/Main.hs",Cabal {component = Just "cabal-test:exe:cabal-test"})
("app/MyExe/MyModule.hs",Cabal {component = Just "cabal-test:exe:cabal-test"})
("app/MyExe/MyPrefix/MyModule2.hs",Cabal {component = Just "cabal-test:exe:cabal-test"})
("test",Cabal {component = Just "cabal-test:test:cabal-test-test"})
cradle

[janvogt]

Hitting this as well with a unsafed scratch buffer. Closing it and reloading the window get's rid of the second hls process (the one with the cradle located at '/')

[dnikolovv]

Is there any workaround for this?

One additional bug with it is that (probably due to the the many different haskell-language-server processes) changes in one module don't get reflected in the other ones without restarting the LSP (and waiting a few minutes).

[dnikolovv]

I found a solution for me.

The problem was that I was working in a folder that was in another partition and was accessing it via a symlink.

VSCode would sometimes receive the path as /path/via/symlink/File.hs and sometimes as /shared-parition/f91969c9-a44d-4b09-a728-6ee828f5c217/folder/File.hs causing it to start multiple instances of hls because it thought that I was working in multiple workspaces.

This problem is fixed when I directly open the folder on the shared partition via VSCode.

[niekvandepas]

Is there any update on this issue? I'm having the same issue as @viluon, and my current workaround is to quit VS Code and relaunch, but that's obviously not really desirable.

Thanks!

[abmclin]

I recently came across this bug while trying out Visual Code for editing Haskell. I found a workaround that appears to be successful so posting it here for future reference.

In the left pane where the workspace folder file tree is displayed, hovering over the top-level folder name will pop up a menu. One of the available menu items is the New File icon, clicking on that to add a new file - instead of opening a new tab and saving as a new file - appears to avoid spawning duplicate extension processes.

I've used this method a few times and I haven't gotten duplicated hints so far so hopefully this is actually a viable workaround.

Obviously this won't help if you just want to have a temporary scratch buffer. You could instead create a scratch file and then deleting it later when no longer needed.