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.