HLS can't execute build-tools if they are defined in the project's own cabal file

[l-epple]

Your environment

Which OS do you use?
NixOS
Which version of GHC do you use and how did you install it?
9.0.2 from nixpkgs
How is your project built (alternative: link to the project)?
Cabal/cabal-install in a nixpkgs/direnv-provided environment

Which LSP client (editor/plugin) do you use?
Emacs, VSCode
Which version of HLS do you use and how did you install it?
1.7.0.0 from nixpkgs
Have you configured HLS in any way (especially: a hie.yaml file)?

cradle:
  cabal:
    - path: "src"
      component: "lib:demo"

    - path: "./Main.hs"
      component: "demo:exe:demo"

    - path: "./Paths_demo.hs"
      component: "demo:exe:demo"

    - path: "test"
      component: "demo:test:spec"

    - path: "./vendor/github.com/xyz/haskell-lib/prelude"
      component: "lib:xyz"

Edit: The entry for our equivalent of my-tool below is missing here, but adding it makes no difference to the behavior observed.

Steps to reproduce

If you have a project that defines a

• a executable my-tool
• a library that has build-tool-depends: my-project:my-tool

and the latter contains a file like this:

{-# OPTIONS_GHC -F -pgmF my-tool #-}

-- any further code

HLS will show an error on that file saying it can't execute my-tool.

Expected behaviour

HLS should (in my opinion) do one of the two things:

• Recognize that the executable is declared properly as a build-tool and present in the same cabal package, but can't be executed because it would not be available in PATH automatically / prior to building it. Instead of an error, it should display a warning informing about the situation.
• Execute the preprocessor from dist/dist-newstlye as Cabal would. This is of course tricky, because it'd mean that HLS needs to build this executable without an explicit request from the user to avoid using an outdated version of the preprocessor.

Actual behaviour

HLS will show an error on that file saying it can't execute my-tool.

[michaelpj]

I'm a little surprised this doesn't work. When HLS requests flags from cabal to build the library, I would expect cabal to rebuild my-tool before responding. Which might result in an unpleasant amount of rebuilding, but that's what you asked for!

Or maybe we're just failing to get the information about build-tools correctly? I don't actually know how that works, cc @fendor ?

[fendor]

Hi, that's a known issue in hie-bios: haskell/hie-bios#187

TLDR; cabal and stack prepend the binary directory where these tools are installed to PATH, and we currently don't know it. E.g., there's nothing specified in the GHC compilation options, since it is a cabal feature.

It is a bit tricky to figure out the PATH for cabal (it is trivial for stack, we have stack path) and then we'd need to add it hie-bios's API.

Then the really tricky part is to teach HLS to only run build actions for components with that specific PATH. (Tricky, because I bet 20€ we have many undocumented assumptions in ghcide code)