Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Applying hlint hint on Windows fails with "could not detect mingw toolchain" #615

Closed
OwenGraves opened this issue Nov 23, 2020 · 14 comments · Fixed by #1225
Closed

Applying hlint hint on Windows fails with "could not detect mingw toolchain" #615

OwenGraves opened this issue Nov 23, 2020 · 14 comments · Fixed by #1225
Assignees
Labels
can-workaround component: hls-hlint-plugin os: windows type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..

Comments

@OwenGraves
Copy link

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

image

@jneira jneira added component: hls-hlint-plugin os: windows type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc.. labels Nov 23, 2020
@jneira
Copy link
Member

jneira commented Nov 23, 2020

@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
Copy link
Author

OwenGraves commented Nov 23, 2020

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
Copy link
Member

jneira commented Nov 23, 2020

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
Copy link
Member

jneira commented Nov 23, 2020

@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
Copy link
Author

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
Copy link
Member

jneira commented Nov 24, 2020

🤦‍♂️ 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
Copy link
Member

jneira commented Nov 24, 2020

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

@jneira jneira added can-workaround status: needs info Not actionable, because there's missing information labels Nov 24, 2020
@ndmitchell
Copy link
Collaborator

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

@jneira
Copy link
Member

jneira commented Nov 24, 2020

@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
Copy link
Author

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
Copy link
Member

jneira commented Nov 24, 2020

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

@OwenGraves
Copy link
Author

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

@jneira
Copy link
Member

jneira commented Nov 25, 2020

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
Copy link
Member

jneira commented Nov 29, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
can-workaround component: hls-hlint-plugin os: windows type: bug Something isn't right: doesn't work as intended, documentation is missing/outdated, etc..
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants