Open hasufell opened 2 years ago
I get exactly that error and it prevents me from using the VSCode Haskell extension.
Is there a workaround until this issue is properly fixed? What is the "ghc in question"? I seem to have the GHC version for my project installed already.
@klauso
Please provide more info:
ghcup list
?haskell-language-server-wrapper --numeric-version
and haskell-language-server-wrapper --project-ghc-version
(run it in your project)hie.yaml
? Are you using cabal or stack?ghcup list
yields:
Tool Version Tags Notes
✗ ghc 7.10.3 base-4.8.2.0 no-bindist
✗ ghc 8.0.2 base-4.9.1.0 no-bindist
✗ ghc 8.2.2 base-4.10.1.0 no-bindist
✗ ghc 8.4.1 base-4.11.0.0 no-bindist
✗ ghc 8.4.2 base-4.11.1.0 no-bindist
✗ ghc 8.4.3 base-4.11.1.0 no-bindist
✗ ghc 8.4.4 base-4.11.1.0 no-bindist
✗ ghc 8.6.1 base-4.12.0.0 no-bindist
✗ ghc 8.6.2 base-4.12.0.0 no-bindist
✗ ghc 8.6.3 base-4.12.0.0 no-bindist
✗ ghc 8.6.4 base-4.12.0.0 no-bindist
✗ ghc 8.6.5 base-4.12.0.0 no-bindist
✗ ghc 8.8.1 base-4.13.0.0 no-bindist
✗ ghc 8.8.2 base-4.13.0.0 no-bindist
✗ ghc 8.8.3 base-4.13.0.0 no-bindist
✗ ghc 8.8.4 base-4.13.0.0 no-bindist
✗ ghc 8.10.1 base-4.14.0.0 no-bindist
✗ ghc 8.10.2 base-4.14.1.0 no-bindist
✗ ghc 8.10.3 base-4.14.1.0 no-bindist
✗ ghc 8.10.4 base-4.14.1.0 no-bindist
✗ ghc 8.10.5 base-4.14.2.0
✗ ghc 8.10.6 base-4.14.3.0
✓ ghc 8.10.7 recommended,base-4.14.3.0
✗ ghc 9.0.1 base-4.15.0.0 no-bindist
✗ ghc 9.0.2 base-4.15.1.0
✗ ghc 9.2.1 base-4.16.0.0
✔✔ ghc 9.2.2 latest,base-4.16.1.0
✗ cabal 2.4.1.0 no-bindist
✗ cabal 3.0.0.0 no-bindist
✗ cabal 3.2.0.0 no-bindist
✗ cabal 3.4.0.0
✗ cabal 3.4.1.0
✗ cabal 3.6.0.0
✔✔ cabal 3.6.2.0 latest,recommended
✗ hls 1.1.0 no-bindist
✗ hls 1.2.0 no-bindist
✗ hls 1.3.0 no-bindist
✗ hls 1.4.0
✗ hls 1.5.0
✗ hls 1.5.1
✗ hls 1.6.0.0
✗ hls 1.6.1.0
✓ hls 1.7.0.0 latest,recommended
✗ stack 2.5.1 no-bindist
✗ stack 2.7.1 no-bindist
✗ stack 2.7.3
✔✔ stack 2.7.5 latest,recommended
✔✔ ghcup 0.1.17.7 latest,recommended
I have no haskell-language-server-wrapper
executable/link but only a haskell-language-server-wrapper-1.7.0.0
executable (could that be part of the reason?). It reports 1.7.0.0
for --numeric-version
. For --project-ghc-version
I get
Found "/Users/klaus/git/dualsub/hie.yaml" for "/Users/klaus/git/dualsub/a"
Failed to get project GHC version: CradleError {cradleErrorDependencies = [], cradleErrorExitCode = ExitFailure 1, cradleErrorStderr = ["Error when calling stack setup --silent","",""]}
The hie.yaml
looks like this:
cradle:
stack:
I'm using Stack.
Do you mean the settings.json
? It looks like this:
{
"security.workspace.trust.untrustedFiles": "open",
"coqtop.binPath": "/Users/klaus/.opam/default/bin/ ",
"haskell.trace.client": "debug",
"editor.minimap.enabled": false,
"window.zoomLevel": 1,
"files.watcherExclude": {
"**/.bloop": true,
"**/.metals": true,
"**/.ammonite": true
},
"haskell.manageHLS": "GHCup",
"haskell.trace.server": "messages",
"haskell.toolchain": {
}
}
I didn't change anything in the configuration options except enabling debug messages (to investigate this error).
What happens when you call stack setup
in your project?
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
I just managed to resolve the issue by
stack config set system-ghc --global true
I suspect this issue is somehow due to stack's GHC installation on M1. Afaik, stack should provide native M1 GHC binaries, but there may be some unknown caveats. GHCup has full M1 support.
The question is: can you build your project with stack via command line and with system-ghc: false
?
Yes, I can, but miraculously the haskell-language-server-wrapper --project-ghc-version
stuff works again, too, despite me (to the best of my knowledge) not changing anything else. It's a flaky bug. Sorry for not being particularly helpful in narrowing down the cause.
Invoking
haskell-language-server-wrapper --project-ghc-version
may fail with:when the ghc in question is not installed. That means the extension is currently unable to set up a project GHC, unless it is already installed somewhere.
This is cabal specific, but rather unergonomic.