haskell / haskell-language-server

Official haskell ide support via language server (LSP). Successor of ghcide & haskell-ide-engine.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wrong `could not execute: tasty-discover` (revisit after haskell/hie-bios#187)

sir4ur0n opened this issue · comments

When using a preprocessor (tasty-discover) for our tests, we get a wrong error from HLS, while compilation is fine.

See minimal repo to reproduce the issue: https://github.com/Sir4ur0n/hls-bug-preprocessor

  • stack test works fine
  • haskell-language-server returns an error:
File:     /home/sir4ur0n/sandbox/hls-bug-preprocessor/test/Spec.hs
Hidden:   no
Range:    1:0-2:0
Source:   compiler
Severity: DsError
Message:  haskell-language-server: could not execute: tasty-discover
Files that failed:
[INFO] finish: User TypeCheck (took 0.57s) * /home/sir4ur0n/sandbox/hls-bug-preprocessor/test/Spec.hs

While we might tell hie.yaml to ignore (cradle none) the Spec.hs file in particular, I don't see a reason why this even fails. HLS should support such files.

Thank you!

Hi, thank you for the bug report!
The same issue exists in hie: haskell/haskell-ide-engine#1500
And the upstream issue is in hie-bios: haskell/hie-bios#125

Work-around: make tasty-discover available in your path.

I just tested by adding haskell.packages.${ghcCompiler}.tasty-discover in my shell.nix and indeed, HLS no longer complains about Spec.hs, thank you @fendor , I appreciate the help and quick response time!

Let's use this issue to document this limitation, as well as link to upstream issue in hie-bios.

I'll try to propose a PR some time this week

I have opened #177 to document this limitation.

Should we keep this issue open to track the original issue?

Yeah, I think that is good idea.

Happen to know the response.

Back in the day (but most probably before this report), in tasty-discover put the info on how to properly bootstrap it.

Notice build-tool-depends: in:
https://github.com/haskell-works/tasty-discover#configure-cabal-or-hpack-test-suite

  • tasty-discover is not really a library dependency, it is a testing tool executable.
  • tasty-discover should not be build-depends: it is build-tool-depends:

When tool is in .cabal description build-tool-depends: - Cabal automatically installs & uses the executable.

P.S.
BTW cabal2nix also supports, respects, requires & handles build-tool-depends:. & the proper bootstrap of tasty-discover in .cabal is a requirement for the project to be properly imported into Nixpkgs. As a result, Nix description would build the package without tasty-discover in the environment, but at runtime tasty-discover would be provided. (Let us have a moment of respect for the work done by the initial Haskell Nixpkgs maintainer we all know.)

& #1159 also was merged

the original reporter mentioned stack, so not sure if it is specific to cabal
did you remove the other labels by accident? afaik it is blocked upstream on a hie-bios issue and it has a workaround...

Know that workaround, used to use it.

Stack configuration depends on Cabal configuration. Stack to work needs to respect Cabal descriptions (for example, as cabal2nix does). If Cabal build-tool-depends: is not respected by it - that implies Stack has own version of the entry for it & it only needs to be looked-up then.

#1159 implies the support of the directive is supported by HLS, that is why thought to close the report.

The current hie-bios report is haskell/hie-bios#187,

So then, yes - it still needs to be open.

Thanks for bouncing me on this.