Haskell-language-server: Applying hlint hint on Windows fails with "could not detect mingw toolchain"

[OwenGraves]

On Windows using vscode, I get a failure when applying a hint similar to haskell/vscode-haskell#323 or #591 except the error message is instead

2020-11-22 21:03:13.2992644 [ThreadId 1814] - applyHint:apply=[("C:\\Code\\Test\\Test.hs:4:1-12: Warning: Eta reduce\nFound:\n  foo x = id x\nPerhaps:\n  foo = id\n",[Replace {rtype = Decl, pos = SrcSpan {startLine = 4, startCol = 1, endLine = 4, endCol = 13}, subts = [("body",SrcSpan {startLine = 4, startCol = 9, endLine = 4, endCol = 11})], orig = "foo = body"}])]
2020-11-22 21:03:13.3022636 [ThreadId 1817] - finish: hlint (took 0.00s)
haskell-language-server-0.6.0-win32-8.10.2.exe: could not detect mingw toolchain
[Error - 9:03:13 PM] Request workspace/executeCommand failed.
  Message: ExitFailure 1
  Code: -32603

The suggestion on hover seems to be correct however

[jneira]

@OwenGraves many thanks for the bug report. You are right, it is suspiciously similar to #591.
The workaround of creating symlinks is trickier here, cause the expected path is not printed and not always is easy to create symlinks in windows :worried:
As ghc is being installed by chocolatey in the original env where the executable is linked, i think installing ghc with chocolatey or moving/copying your actual ghc where choco installs it could workaround the issue.

The command (with powershell) used to install ghc with choco in the ci job is:

Choco-Install -PackageName ghc -ArgumentList "--version", "8.10.2", "-m"

In cmd it would be (not tested):

choco install ghc --version=8.10.2 -m

[OwenGraves]

I'm not sure I follow what you're suggesting, but I have ghc installed using choco in the default path C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.10.2\bin\ghc.exe and ghc is found on my path when I type ghc into a powershell terminal.

[jneira]

I have ghc installed using choco in the default path C:ProgramDatachocolateylibghctoolsghc-8.10.2binghc.exe

I was suggesting just install ghc in that location like you already have but it is clear it should be different in the ci environment, will investigate where is

[jneira]

@OwenGraves
It turns out that in github actions ci ghc is being installed in /c/ProgramData/chocolatey/lib/ghc.8.10.1/tools/ghc-8.10.1/bin/ghc
The slightly different location is caused by the -m parameter of the installing i mentioned above. I guess you installed ghc without that parameter.
Son reinstalling it with -m should place the ghc in the same directory of you local machine and it will likely make the workaround.
(You can copy it or create a symlink if you has enabled them)

[OwenGraves]

Thanks for looking into issue. I ran choco install ghc --version=8.10.2 -m and installed ghc in C:\ProgramData\chocolatey\lib\ghc.8.10.2\tools\ghc-8.10.2\bin\ghc but unfortunately I'm still running into the same error when trying to apply a hint.

[jneira]

:man_facepalming: omg, i am afraid that hls is being compiled in two environments:

• For ghc 8.10.1, 8.6.5, 8.6.4: github actions build
  
  
  
  • The path to ghc hlint public need is in: C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1\bin\ghc (replacing ghc version properly)
  
  
• For ghc 8.10.2, 8.8.4 and 8.8.3: my own local windows 10 (#276)
  
  
  
  • The path to ghc is D:\bin\stack\x86_64-windows\ghc-8.10.2 (replacing ghc version with the appropiate one)
  
  
  • I hope the next hls version using ghc-8.10.2 will be the github one: #617
  
  

So as you are using ghc-8.10.2 hlint plugin needs ghc in D:\bin\stack\x86_64-windows\ghc-8.10.2
That is a very very unfortunate state of things :worried:

It is worse for windows cause:

• The error message dont say anything about the path where it is looking for mingw toolchain
• We have two ways of buiding hls in windows
• Mine is an absolute non standard ghc location and users even will not have a D: drive :disappointed:

@OwenGraves i would ask you (last time, i promise) to try move/copy/symlink ghc-8.10.2 to that location (D:\bin\stack\x86_64-windows\ghc-8.10.2) if you can do it easily to confirm definitely this is the same issue as #591 so i can start to fix it upstream asap.

[jneira]

Well a better workaround would be build hls from source, of course.

[ndmitchell]

Would we still have the problem on earlier GHC where we pass a string rather than an AST?

[jneira]

@ndmitchell If this issue is the same as #591 it is (there it was reported for ghc-8.8.4)
It seems ghc-exactprint get dynflags using a custom ghc call using ghc-paths in all cases, but i have to confirm it is the root cause of this (likely trying to fix it)

[OwenGraves]

I tried copying ghc.exe to D:\bin\stack\x86_64-windows\ghc-8.10.2\ and C:\bin\stack\x86_64-windows\ghc-8.10.2\ but still get the same error in vscode when applying a hint.

[jneira]

@OwenGraves jumm, so maybe it is not the same issue. Sorry for so many unsuccesful tries. Will continue investigating

[OwenGraves]

@jneira No worries, best of luck figuring it out! Let me know if you want me to try out any other ideas.

[jneira]

I've reproduced it downloading ghc-8.10.1 from the release assets and using it locally (a version built locally works).
As that version was built in ci and was compiled with a ghc placed in other location than mine, it would be a argument for the initial hypothesis.
So i've copied my ghc-8.10.1 in the place where is in github action ci env: C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1 and hlint has worked again.

Maybe my comment above is confusing:

• C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1\bin\ghc is the path to the executable
• So C:\ProgramData\chocolatey\lib\ghc.8.10.1\tools\ghc-8.10.1 is the install root of ghc. There is where ghc has to be installed

[jneira]

To make diagnose the issue easier for future ghc versions i've opened a pr upstream in ghc: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4517
It was approved so ghc-9.x would have a nicer error message including the paths.