Can't find ghc version with HLS 1.7.0.0

[lylek]

Your environment

Which OS do you use: macOS Monterey (M1)

Which LSP client (editor/plugin) do you use: vscode-haskell

Describe your project (alternative: link to the project): hie.yaml, stack.yaml, package.yaml

Steps to reproduce

Open the project in VS Code with the VS Code extension version 2.2.0, which uses HLS 1.7.0.0.

Expected behaviour

It should determine the correct GHC version (8.10.7) from the hie.yaml + stack.yaml, as it did prior to HLS 1.7.0.0.

Actual behaviour

It looks at the hie.yaml and figures out that it's a stack project.
Repeatedly generates an error (see log below).

Include debug information

Found "/Users/lkopnicky/ExaTMS/hie.yaml" for "/Users/lkopnicky/ExaTMS/a"
Run entered for haskell-language-server-wrapper(haskell-language-server-wrapper) Version 1.7.0.0 aarch64 ghc-9.2.2
Current directory: /Users/lkopnicky/ExaTMS
Operating system: darwin
Arguments: ["--lsp","-d"]
Cradle directory: /Users/lkopnicky/ExaTMS
Cradle type: Stack

Tool versions found on the $PATH
cabal:		3.6.2.0
stack:		2.7.5
ghc:		8.10.7


Consulting the cradle to get project GHC version...
Failed to get project GHC version: CradleError {cradleErrorDependencies = [], cradleErrorExitCode = ExitFailure 1, cradleErrorStderr = ["Error when calling stack setup --silent","",""]}

[aryairani]

Me too. 😢

[aryairani]

Though @lylek , when I run haskell-language-server-wrapper-1.7.0.0 --project-ghc-version within the vscode command prompt, I correctly get 8.10.7, although this isn't enough to make the haskell.haskell plugin load up successfully anymore.

[drsooch]

The command that's actually being run stack setup --silent looks like it's failing. What's the output of stack setup?

[lylek]

The command that's actually being run stack setup --silent looks like it's failing. What's the output of stack setup?

Well, stack setup --silent doesn't output anything, because it's silent. But it doesn't return any error code.

And stack setup outputs:

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 have now reproduced this problem with an entirely different project (HID examples) on a different MacBook - same architecture. So it doesn't seem to be an issue specific to my project. That project does not have a hie.yaml, but I used gen-hie to create one.

[lylek]

Note the stack is found in the path at /usr/local/bin/stack whereas haskell-language-server-wrapper-1.7.0.0 is at the path ~/.ghcup/bin/haskell-language-server-wrapper-1.7.0.0. I wonder if that makes a difference, that it's not using the stack installed by ghcup?

[tuanmtran]

Similar to all comments above have spent 3+ hrs trying to figure this out ;-;

[aryairani]

Fwiw, a workaround for me was to ensure that I am using the x86 version of ghcup, and not the arm64 version:

so instead of

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org/ | sh

I did rm -rf ~/.ghcup; brew uninstall ghcup and then

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org/ | arch -x86_64 sh

and then vscode began to work. Does this help?

---

Edit: Or install it with x86 brew, if you want to use brew:

arch -x86_64 /usr/local/bin/brew install ghcup

[hasufell]

Well yes. If you install stack from official channels, you get a x86 binary, not a native M1 binary.

However, ghcup provides a native M1 binary. So purge your existing stack binary and install via ghcup. It's confusing that we do a better job at supporting M1, but that's how it is.

[lylek]

Thanks, @aryairani and @hasufell.

I removed the x86_64 version(s) of stack and let ghcup install the native M1 version of it. Then I tried running vscode again.

I'm still getting the same error about stack setup --silent failing. But looking in the log, I see a different error than before:

% stack setup
The GHC located at /Users/lkopnicky/.stack/programs/aarch64-osx/ghc-8.10.7/bin/ghc-8.10.7 failed to compile a sanity check. Please see:

    http://docs.haskellstack.org/en/stable/install_and_upgrade/

for more information. Exception was:
Received ExitFailure 1 when running
Raw command: /Users/lkopnicky/.stack/programs/aarch64-osx/ghc-8.10.7/bin/ghc-8.10.7 /private/var/folders/fv/q2gn3g9s7t1gf4xn9y4zrlch0000gn/T/stack-sanity-check-647db0c5d557a65e/Main.hs -no-user-package-db
Run from: /private/var/folders/fv/q2gn3g9s7t1gf4xn9y4zrlch0000gn/T/stack-sanity-check-647db0c5d557a65e/
Standard output:

[1 of 1] Compiling Main             ( /private/var/folders/fv/q2gn3g9s7t1gf4xn9y4zrlch0000gn/T/stack-sanity-check-647db0c5d557a65e/Main.hs, /private/var/folders/fv/q2gn3g9s7t1gf4xn9y4zrlch0000gn/T/stack-sanity-check-647db0c5d557a65e/Main.o )
Standard error:


<no location info>: error:
    Warning: Couldn't figure out LLVM version!
             Make sure you have installed LLVM between [9 and 13)
ghc: could not execute: opt

So it's suggesting I install llvm. Well I looked into installing that with brew but it warns me that macOS already ships with llvm and installing another one in parallel could cause problems.

Also, I don't know why it needs llvm. I want to build x86 binaries with the native code generator.

Later when I switch to 9.2, I'll be happy to build M1 binaries, but for now I want to stick with x86_64.

In fact, yeah, I'm in trouble - I can't build our code base even on the command line with stack - it says it needs LLVM. I'm going to have to go back to the x86 stack I think. And HLS will just be broken :(

I have a project I want to build that uses ghc 8.4.4, and I get an error trying to build it:

No setup information found for ghc-8.4.4 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'macosx-aarch64'.
Supported versions: ghc-8.10.5, ghc-8.10.6, ghc-8.10.7, ghc-9.0.2, ghc-9.2.1, ghc-9.2.2

Maybe I need both the aarch64 and x86_64 versions of ghcup installed?

[lylek]

Fwiw, a workaround for me was to ensure that I am using the x86 version of ghcup, and not the arm64 version:

so instead of

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org/ | sh

I did rm -rf ~/.ghcup; brew uninstall ghcup and then

curl --proto '=https' --tlsv1.2 -sSf https://get-ghcup.haskell.org/ | arch -x86_64 sh

and then vscode began to work. Does this help?

Edit: Or install it with x86 brew, if you want to use brew:

arch -x86_64 /usr/local/bin/brew install ghcup

Thanks @aryairani, that works for me.

[hasufell]

Also, I don't know why it needs llvm.

8.10.7 aarch64 needs llvm, because it doesn't have the native code generator. Yes, install it from brew.

I don't understanding why you refuse to follow the instructions from ghcup: https://github.com/haskell/ghcup-metadata/blob/fbf06cc9eed096ba546530230f2facb0ac9815ba/ghcup-0.0.7.yaml#L134

[aryairani]

I don't understanding why you refuse to follow the instructions from ghcup: haskell/ghcup-metadata@fbf06cc/ghcup-0.0.7.yaml#L134

I can't speak for @lylek, but in my case, it's a combination of that I've never seen that before 😬 , not really even sure how you found it, don't know how it fits in with my existing setup which worked fine until vscode-haskell 2.2.0 w/ hls 1.7.0.0, and general distrust of the GHC/Stack toolchain for M1 since it's been way behind the x86_64 builds in both availability and performance for the past couple of years.

[hasufell]

not really even sure how you found it

Found what?

don't know how it fits in with my existing setup which worked fine until vscode-haskell 2.2.0 w/ hls 1.7.0.0, and general distrust of the GHC/Stack toolchain for M1 since it's been way behind the x86_64 builds in both availability and performance for the past couple of years

That's because you've never used the native M1 binaries since stack doesn't install itself as such.

[aryairani]

That's because you've never used the native M1 binaries since stack doesn't install itself as such.

I have; and I tried it again this morning inspired by your comment, using arm64 ghcup to install arm64 stack and arm64 ghc, and I still get a "segmentation fault" when I try do to a build. So that's an example of what I'm talking about. In any case, that's getting far from the topic of this ticket, so I apologize for that and will refrain from digressing further ;-)

[hasufell]

and I still get a "segmentation fault" when I try do to a build

Please provide a bug report then to GHC. Note that ghcup itself is built with cabal and GHC-8.10.7 arm on darwin. So at least something works.

[aryairani]

I don't understanding why you refuse to follow the instructions from ghcup

at least something works.

My point was simply that following the instructions isn't a slam dunk, so it's okay to be nice about suggesting it. :)

[hasufell]

I don't understanding why you refuse to follow the instructions from ghcup

at least something works.

My point was simply that following the instructions isn't a slam dunk, so it's okay to be nice about suggesting it. :)

If following the instructions doesn't work, it's either a problem with configuration (e.g. incorrect llvm version) or it's a GHC bug. If people don't report bugs, we're left with guessing what works.

[lylek]

8.10.7 aarch64 needs llvm, because it doesn't have the native code generator. Yes, install it from brew.

I don't understanding why you refuse to follow the instructions from ghcup: https://github.com/haskell/ghcup-metadata/blob/fbf06cc9eed096ba546530230f2facb0ac9815ba/ghcup-0.0.7.yaml#L134

I'm getting the impression that I can only either install an M1 toolchain, or an x86 toolchain. Right now I have all my code building and working with x86. I have 3rd party libraries installed for x86. I don't want to take a chance on breaking what works.

I would love it if I could set up my toolchain so I could build either M1 or x86 code, or both, for a project. But if I can only have one, I'll stick with x86 for now. When my company switches to GHC 9.2, I may switch to an M1 toolchain at that point.

Some years ago, when I started using stack, I loved it because I was running on Windows and I could build 32-bit and 64-bit executables from the same source tree. I wish I could do the same on my Mac - build both x86 and M1 executables.

Secondly, those instructions for ghcup say to instal llvm using brew, but brew warns you that you shouldn't install it because there's already a system version and they could conflict. So that gave me pause.

[hasufell]

I'm getting the impression that I can only either install an M1 toolchain, or an x86 toolchain

GHCup supports installing of cross compilation toolchains. So you could have an M1 GHC bindist that produces an x86 binary. But I'm not sure if anyone ever attempted that.

If you want two different GHCup's (one M1 aarch64, one x86), you can easily do that too and set a different GHCUP_INSTALL_BASE_PREFIX env var for them and then tell the VSCode extension which one to pick:

  "haskell.serverEnvironment": {
    "GHCUP_INSTALL_BASE_PREFIX": "/home/foo/ghcup-x86",
    "PATH": "/home/foo/ghcup-x86/.ghcup/bin:$PATH"
  }

To install x86 ghcup on darwin M1, you simply get the x86 binary and put it into /home/foo/ghcup-x86/.ghcup/bin/ghcup.

[michaelpj]

This seems like an odd support case that got resolved, closing.