Working out the project GHC version seemingly never finishes

[Savelenko]

After automatic update to 1.5.0 VS Code (OSS Code 1.55.2) shows a new status "Working out the project GHC version. This might take a while...". I've read a bit that this used to fail to appear without clear progress indication to the user but in my case it never finishes (I restarted VS Code several times and waited for ~10 minutes). Consequently, HLS never starts and there is no debug output under Haskell.

Just yesterday, before the update my whole set-up worked great, the only change is 1.5.0 of the extension. Here is my HLS environment:

~/.config/Code\ -\ OSS/User/globalStorage/haskell.haskell/haskell-language-server-1.3.0-linux-8.8.4 --probe-tools
haskell-language-server version: 1.3.0.0 (GHC: 8.8.4) (PATH: /home/yos/.config/Code - OSS/User/globalStorage/haskell.haskell/haskell-language-server-1.3.0-linux-8.8.4) (GIT hash: e7c5e90b6df5dff2760d76169eddaea3bdd6a831)
Tool versions found on the $PATH
cabal:		2.4.1.0
stack:		2.5.1
ghc:		Not found

[gboduljak]

I have the same problem.

[gboduljak]

Downgrading to the previous version of the extension solves the problem.

[Savelenko]

What is the version you downgraded to? I was hesitant to do so because 1.3.0 and 1.4.0 seem to exist, but VS Code suggests only 1.2.0 as previous version.

Actually, after upgrading VS Code to 1.58 the "Install another version" option became disabled and there is no way of restoring a working environment.

[Savelenko]

I took a look at what should happen in the source code and running manually the following works:

$ ~/.config/Code\ -\ OSS/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.3.0-linux --project-ghc-version
Found "/home/yos/<...>/hie.yaml" for "/home/yos/<...>/a"
8.8.4

[gboduljak]

1.4.0 is the one I downgraded to after downgrading VS Code :). Thanks for the feedback.

[Savelenko]

Additional observations. When manually running the non-wrapper binary, much more output is produced and in the end an error is reported:

$ ~/.config/Code\ -\ OSS/User/globalStorage/haskell.haskell/haskell-language-server-1.3.0-linux-8.8.4 --project-ghc-version
....
2021-08-04 11:30:49.773631364 [ThreadId 198] INFO hls:	File:     /home/yos/<...>/backend/Setup.hs
Hidden:   no
Range:    1:1-2:1
Source:   cradle
Severity: DsError
Message: 
  Multi Cradle: No prefixes matched
  pwd: /home/yos/<...>/backend
  filepath: /home/yos/<...>/backend/Setup.hs
  prefixes:
  ("./src",Stack {component = Just "ttb:lib", stackYaml = Nothing})
  ("./app",Stack {component = Just "ttb:exe:ttb-exe", stackYaml = Nothing})
  ("./test",Stack {component = Just "ttb:test:ttb-test", stackYaml = Nothing})
2021-08-04 11:30:52.28346358 [ThreadId 197] INFO hls:	finish: User TypeCheck (took 4.84s)
2021-08-04 11:30:52.350956689 [ThreadId 198] INFO hls:	finish: GetHie (took 0.07s)
Files that failed:
 * /home/yos/<...>/backend/Setup.hs

2021-08-04 11:30:52.614362533 [ThreadId 1531] INFO hls:	finish: GenerateCore (took 0.26s)
Completed (72 files worked, 1 file failed)

My hie.yaml file looks like this:

cradle:
  stack:
    - path: "./src"
      component: "ttb:lib"
    - path: "./app"
      component: "ttb:exe:ttb-exe"
    - path: "./test"
      component: "ttb:test:ttb-test"

Given that manually running the wrapper seems to do more than the non-wrapper binary, I tried manually setting the executable path to it (and to the non-wrapper) but VS Code shows an error pop-up with

serverExecutablePath is set to /home/yos/.config/Code\ -\ OSS/User/globalStorage/haskell.haskell/haskell-language-server-wrapper-1.3.0-linux but it doesn't exist and is not on the PATH

In the past I used to change this setting like this and this error is new and surprising to me.

Finally, I tried deleting Setup.hs completely but that did not have any effect.

[jneira]

Hi, sorry for the incoveniences, i'll try to fix the code introduced in #414 and revert the change if it is not possible to do it in a reasonable amount of time.
I've checked that error handling is not working correctly and killing the hls executable while working out the ghc version makes the progress notification hangs.
But i checked locally that it worked when the process ended succesfully, to investigate.

[jneira]

But i checked locally that it worked when the process ended succesfully, to investigate.

Just tried again and works for me in windows

[Savelenko]

Just tried again and works for me in windows

Do I understand correctly that the happy flow works, but error handling (at least under Linux) does not?

[jneira]

Yeah, that is my impression, however, error handling apart, i used a way to spawn the subprocess that uses a shell by default and maybe it could be the cause of your issue (afaiu the process of getting ghc version works for you)

[jneira]

@Savelenko @gboduljak hi, i've made a pr to try to fix the issue, coud you have the chance of trying it locally to see if it really fixes the issue for you? If it makes easier the testing i could upload a .vsix file installable from vscode.

[Savelenko]

I'd gladly test it if you could provide a .vsix file or provide an alternative instruction. I have no experience of hacking around with VS Code like this.