haskell-language-server State of multiple home units for HLS

Loading multiple cabal/stack components into HLS has been a pain point since its early beginnings. Essentially, it allows us to provide diagnostics and code actions across components, such as libraries, executables, test suites, etc...

In this issue, we outline the current progress of native multiple home unit support.

[x] Cabal --enable-multi-repl support, added in 3.11 https://github.com/haskell/cabal/pull/8726
[x] GHC multiple home units, added 9.4 https://gitlab.haskell.org/ghc/ghc/-/issues/10827
[ ] HLS needs to support multiple home units:
- [x] https://github.com/haskell/haskell-language-server/pull/2994
- [ ] https://github.com/haskell/haskell-language-server/pull/3462
- [x] https://github.com/haskell/haskell-language-server/pull/3686
[x] Hie-bios API changes to permit using cabal 3.11's multi repl support https://github.com/haskell/hie-bios/pull/409
[ ] Release HLS with the new hie-bios version

This means, we have native multi repl support for cabal >=3.11 and GHC >=9.4 once hie-bios's #409 is merged and published.

However, not everyone can switch to cabal-3.12 (once it is released), so we are thinking about adding custom support for older cabal versions, using build-info and exploiting the information from plan.json. The idea is as follows:

For all targets, figure out the component they belong to using build-info.json
Calculate the dependency closure of all targets that shall be loaded into the same GHC session. This upholds the closure property for GHC.
Read the respective build-info.json files to find the build options of local components.

Jul 31 '23 14:07 fendor

I don't think its unreasonable to expect users to upgrade to cabal 3.12 to get this to work reliably.

Jul 31 '23 14:07 wz1000

Right, but things need to work gracefully if they don't have it.

Wasn't there an implicit-hie bit?

Jul 31 '23 15:07 michaelpj

Right, but things need to work gracefully if they don't have it.

Yes, they will continue to work (or not work) as they currently have been.

Wasn't there an implicit-hie bit?

I think implicit-hie can interfere with the cradles and prevent them from being usable for multi-unit support.

Jul 31 '23 15:07 wz1000

I think implicit-hie can interfere with the cradles and prevent them from being usable for multi-unit support

In particular, the thing that I want to be true is that a user who has a new enough cabal and a new enough GHC should just get a multi-repl cradle, without having to do manual configuration.

Jul 31 '23 15:07 michaelpj

We also need a way to turn it off in case it's buggy.
- Where to configure? hie.yaml?
We want it to be clear from the logs whether it's on or not, since it'll probably be relevant for bug reports.
We also need a cabal release.

Aug 09 '23 11:08 michaelpj

I think this is almost done, the only question in my mind is whether we're logging this clearly?

Jan 17 '24 10:01 michaelpj

I'm not sure if we have in fact got the usability bits I suggested in https://github.com/haskell/haskell-language-server/issues/3738#issuecomment-1671172848 ? @fendor @wz1000 ? I do think it's quite important that we can turn this off and that it's clearly signalled in the logs.

Apr 02 '24 11:04 michaelpj

Indeed, as reported by https://github.com/haskell/cabal/issues/9860, we do not have the desired usability bits in place, if I am not mistaken.

However, it should be possible to implement the usability feature entirely on the HLS side.

Apr 02 '24 11:04 fendor

I think we can close this now!

Apr 23 '24 14:04 michaelpj

What a journey! Can't wait to migrate our project to cabal and start using it. Thanks to everyone involved :clap:

Apr 23 '24 14:04 jhrcek