HLS fails to run on test-suite

[BlueFlame-SM]

Your environment

Which OS do you use?
Ubuntu 22.04
Which version of GHC do you use and how did you install it?
9.4.8 from GHCup
How is your project built (alternative: link to the project)?
Using cabal, a single library and a test-suite.

Which LSP client (editor/plugin) do you use?
VS Code+vscode-haskell
Which version of HLS do you use and how did you install it?
2.5.0.0 from GHCup
Have you configured HLS in any way (especially: a hie.yaml file)?
Yes and no (neither work)

What's wrong?

Code analysis works fine on my library, but not in my test-suite.

I found some "workarounds" such as:

• Building HLS from source according to: https://haskell-language-server.readthedocs.io/en/latest/troubleshooting.html#static-binaries-and-template-haskell-support;
• Fully reinstalling the haskell toolchain;
• Removing .stack, .cabal and .ghc caches;
• Generally messing around with different versions of GHC (and changing required base version), cabal and HLS;
• Use a hie.yaml file.

None of the above seem to solve the error in the debug information part, or result in different issues such as being unable to resolve a build-scheme.

Given what I read in other issues and how long they have been open there won't be a solution soon, so preferably I'd like to know if there is something I haven't tried yet. If not, I'd like to know if it is possible to disable HLS for specific files in my project so I don't get bothered by the error message all the time.

Debug information

Failed to run ["cabal","v2-repl","monads-and-applicatives:test:monads-and-applicatives-test"] in directory "/home/timo/Documents/UU/AFP/Weekly/monads-and-applicatives". Consult the logs for full command and error.
Failed command: cabal --builddir=/home/timo/.cache/hie-bios/dist-monads-and-applicatives-3d485c38466d4eb1204f0f6844ca30a0 v2-repl --with-compiler /home/timo/.cache/hie-bios/wrapper-b54f81dea4c0e6d1626911c526bc4e36 --with-hc-pkg /home/timo/.cache/hie-bios/ghc-pkg-8544494cfbb2b2d94b74ba47851bfadd monads-and-applicatives:test:monads-and-applicatives-test
Build profile: -w ghc-9.4.8 -O1
In order, the following will be built (use -v for more details):
 - monads-and-applicatives-0.1.0.0 (lib) (first run)
 - monads-and-applicatives-0.1.0.0 (test:monads-and-applicatives-test) (first run)
Preprocessing library for monads-and-applicatives-0.1.0.0..
Building library for monads-and-applicatives-0.1.0.0..


<no location info>: error:
    Warning: Couldn't figure out linker information!
             Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc.
collect2: fatal error: cannot find ‘ld’
compilation terminated.
`gcc' failed in phase `Linker'. (Exit code: 1)
Error: cabal: Failed to build monads-and-applicatives-0.1.0.0 (which is
required by test:monads-and-applicatives-test from
monads-and-applicatives-0.1.0.0).

[fendor]

Hi, thank you for your bug report!

This vaguely looks like an issue with your system... Can you try invoking cabal v2-repl monads-and-applicatives:test:monads-and-applicatives-test and report whether it is the same output? If yes, not much HLS can do, perhaps we need to raise this with the cabal people.

[BlueFlame-SM]

Hi, thank you for your bug report!

This vaguely looks like an issue with your system... Can you try invoking cabal v2-repl monads-and-applicatives:test:monads-and-applicatives-test and report whether it is the same output? If yes, not much HLS can do, perhaps we need to raise this with the cabal people.

Running cabal v2-repl monads-and-applicatives:test:test works fine (changed the name of my test suite to just test).

Accoring to the error the command that fails is:

cabal --builddir=/home/timo/.cache/hie-bios/dist-monads-and-applicatives-3d485c38466d4eb1204f0f6844ca30a0 v2-repl --with-compiler /home/timo/.cache/hie-bios/wrapper-b54f81dea4c0e6d1626911c526bc4e36 --with-hc-pkg /home/timo/.cache/hie-bios/ghc-pkg-8544494cfbb2b2d94b74ba47851bfadd /home/timo/Documents/UU/AFP/Weekly/monads-and-applicatives/tests/Main.hs

This command produces the exact error (minus the extra HLS info) as above.
If I then remove the --with-compiler argument it works fine again:

cabal --builddir=/home/timo/.cache/hie-bios/dist-monads-and-applicatives-3d485c38466d4eb1204f0f6844ca30a0 v2-repl --with-hc-pkg /home/timo/.cache/hie-bios/ghc-pkg-8544494cfbb2b2d94b74ba47851bfadd /home/timo/Documents/UU/AFP/Weekly/monads-and-applicatives/tests/Main.hs

Thus I suspect the issue lies with the hie-bios, and from my shoddy research thus far that is related to HLS (?).

[fendor]

Yeah hie-bios is related to HLS. Do you perhaps have a test project where we can try to reproduce the issue?

[BlueFlame-SM]

Here you have an example that doesn't work for me. Its literally just what you get when you run cabal init and ask it for a test suite. As such I doubt it'll reproduce my issue with this alone.
hls-bug.zip

I'll also provide some further context:
I've been having similar issues for some time now. It did occur in different setting though, for example currently it only occurs on test-suites, but it used to occur on libraries and executables as well. The only commonality between the times I encounter it I've spotted thus far is that it's always when I have multiple build-targets in my cabal.
It also used to be the case that starting VSCode through command line solved the issue, but this is no longer the case.
Before that it used to be the case that just building the project solved my issues.

[BlueFlame-SM]

Hmm, personally I think somewhere in the chain my $PATH environment variable is getting lost, but I'd have no idea why, how and where, nor how to solve it.

[fendor]

Interesting! You can check that by copying the contents of your $PATH into .vscode/settings.json in your project root:

{ 
  "haskell.serverEnvironment": { "PATH": "path1:path2" } 
}

https://github.com/haskell/vscode-haskell?tab=readme-ov-file#set-additional-environment-variables-for-the-server

[BlueFlame-SM]

I had tried that right after my last comment as I happened upon that option. I tried putting /usr/bin/ld explicitly before the path but it didn't seem to be the solution. I'll try it by copying my entire path tomorrow.

[BlueFlame-SM]

I added my entire path to "haskell.serverEnvironment" but nothing changed.

As part of my university course I have to grade other peoples projects. I'm not too well versed in the whole haskell toolchain but the process of installing some1 elses cabal project seems too convoluted and has me suspecting my entire toolchain is broken.

Basically, I download their package and open the project in vscode. I get a notification that the required HLS version is 1.8.0.0 and that I don't have it installed. I tell the plugin to install this version and after some time it fails at the following step:

Consulting the cradle to get project GHC version...
Failed to find the GHC version of this Cabal project.
Error when calling cabal exec -v0 -- ghc --print-libdir

Error: cabal: Could not resolve dependencies:
[__0] trying: package-name-0.1.0.0 (user goal)
[__1] next goal: base (dependency of package-name)
[__1] rejecting: base-4.13.0.0/installed-4.13.0.0 (conflict:
package-name => base^>=4.14.3.0)
[__1] skipping: base-4.19.0.0, base-4.18.2.0, base-4.18.1.0, base-4.18.0.0,
base-4.17.2.1, base-4.17.2.0, base-4.17.1.0, base-4.17.0.0, base-4.16.4.0,
base-4.16.3.0, base-4.16.2.0, base-4.16.1.0, base-4.16.0.0, base-4.15.1.0,
base-4.15.0.0 (has the same characteristics that caused the previous version
to fail: excluded by constraint '^>=4.14.3.0' from
'package-name')
[__1] rejecting: base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0,
base-4.13.0.0, base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0,
base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0,
base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1,
base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0,
base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0,
base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from
non-upgradeable package requires installed instance)
[__1] fail (backjumping, conflict set: base, package-name)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, package-name

Runninghcup tui reveals that vscode haskell has installed HLS 1.8.0.0 and base-4.13.0.0. Which is weird because the project clearly states it requires base-4.14.3.0 or up, excluding newer api-breaking releases.

If I manually run the command it my terminal it fails in the same way because I always have the newest recommended ghc version set active. I always presumed cabal was meant to figure this stuff out for you and use the appropriate version anyways? Not that it matters much as I can just manually set the correct version, but because the haskell plugin uses its own active versions of the toolchain it won't help me there.

I've had similar problems when doing stuff with stack, although if used it far less so I'm not sure to what degree the issues are actually the same. What tool is most likely the cause? or is it literally just my system being somehow incapable of running haskell normally?

[BlueFlame-SM]

Regardless of what I do vscode haskell now tries to use base-4.13.0.0. Any way to reset this behavior?

[fendor]

So what you are encountering is the fact that the version of base is coupled with the version of ghc you are using to compile your project with.
When you run ghcup list, an excerpt of the output is:

✓  ghc   9.2.8      base-4.16.4.0             hls-powered           
✗  ghc   9.4.1      base-4.17.0.0                                   
✗  ghc   9.4.2      base-4.17.0.0                                   
✗  ghc   9.4.3      base-4.17.0.0                                   
✗  ghc   9.4.4      base-4.17.0.0                                   
✗  ghc   9.4.5      base-4.17.1.0                                   
✗  ghc   9.4.6      base-4.17.2.0                                   
✗  ghc   9.4.7      base-4.17.2.0                                   
✓  ghc   9.4.8      recommended,base-4.17.2.1 hls-powered           
✗  ghc   9.6.1      base-4.18.0.0                                   
✗  ghc   9.6.2      base-4.18.0.0                                   
✗  ghc   9.6.3      base-4.18.1.0                                   
✔✔ ghc   9.6.4      base-4.18.2.0             hls-powered           
✗  ghc   9.8.1      base-4.19.0.0             hls-powered,2023-10-09
✓  ghc   9.8.2      latest,base-4.19.1.0      2024-02-23     

Where the third column tells you what version of base comes with that ghc version.

So, if you have a conflict with the base version, you either need to switch ghc version, or remove the bounds on the base version.
cabal init tends to add a very strict boundary on the supported base version. If you remove that bound, or relax it, then cabal may be able to build the project of your colleague. Or, you need to make sure, you build it with the same ghc version your colleague has. You can change the version bound in the respective .cabal file that your colleague hopefully provided. Or, if there is a cabal.project file, there might be an entry with-compiler, specifying a compiler version for building the project.

However, these last issues are not related to HLS but rather basics and shenanigans of cabal and ghc.

[BlueFlame-SM]

Yes, thats also what I figured.
I now have an even worse issue with HLS where, for whatever dumb reason, since installing my colleagues project, HLS is trying to use ghc-8.8.4 (base-4.13.0.0) to compile my own package (obviously failing due to mine requiring a newer base).
Basically, I'm now stuck with only being able to use HLS on projects that allow base-4.13.0.0, which I definitely don't want.
The plugin is completely ignoring my systems HLS and GHC versions and using whatever version it installed when it detected I didn't have the correct version for my colleagues project.
Is there some place where the plugin stores a symlink to whatever version its using?