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 😟
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:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.10.2\bin\ghc.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]

🤦‍♂️ 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 (Attach windows binaries for ghc 8.8.4 #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: Enable ghc-8.10.2 for windows #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 😟

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 😞

@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)