Add support for multi unit argument syntax

[wz1000]

Implements the argument parsing logic for multiple home units found in GHC 9.4: https://downloads.haskell.org/ghc/9.4.4/docs/users_guide/using.html#multiple-home-units

We now support arguments of the form

-unit @unitA -unit @unitB

where the response files unitA and unitB contain the actual list of arguments for that unit:

-this-unit-id a-0.1.0.0
-i
-isrc
A1
A2

Also refactor the session loader and simplify it.

Also adds error messages on GHC 9.4 if the units are not closed (#3422).

Depends on haskell/hie-bios#387

[mpickering]

What happens if the closure property is violated? That seemed the main point of design on the issue?

[pepeiborra]

Wat?

[fendor]

Probably the new cabal feature that uses multiple home-units when loading them into a repl?

[wz1000]

Yes, @fendor is right, I generated the -unit files by using a special branch of cabal with the new feature and then editing it a bit.

This cabal.project isn't necessary or even useful in this patch so I will remove it.

[wz1000]

With the cabal feature you can set up your hie.yaml to load your entire project including all components with this patch like so:

cradle:
  cabal:
    - path: "./"
      component: "all"

[fendor]

I am interested to know what branch and what @mpickering is planning there, and whether we still need the work from haskell/cabal#7500, or whether the changes done in that fork render cabal status command irrelevant?
Maybe we can briefly discuss that at the next meeting.

[wz1000]

Here is the branch, it is still a WIP: https://github.com/mpickering/cabal/tree/wip/no-configure

[wz1000]

What happens if the closure property is violated?

We get the same error we would get from GHC, which is not ideal and could probably be improved.

I checked if recovery is possible once more components are loaded but it seems it is not, so that needs a bit more work.

[mpickering]

What happens if the closure property is violated?

We get the same error we would get from GHC, which is not ideal and could probably be improved.

I checked if recovery is possible once more components are loaded but it seems it is not, so that needs a bit more work.

I think that things should carry on working for the unit you have currently loaded but just ignore any files which would be in the new component (until the require components are loaded in).

[mpickering]

I tested again and the closure check seems to be working properly now.

But I think the question I raised about what should happen if the closure check is violated is still unresolved.

[mpickering]

Branch appears to no longer build due to a version mismatch of hie-bios. What's the plan @wz1000 ?

[fendor]

I think, the plan looks roughly as follows:

• For cabal versions that support multi-repl, we remember the filepaths that caused components to be loaded.
  On subsequent calls to runCradle, we pass in all previous filepaths, s.t. hie-bios invokes cabal repl fp1 fp2 fp3 and cabal then calculates the dependency closure. That works fine, afaict, except for potential issues with the maximal cli parameter length. This branch is currently using an extension to hie-bios allowing to pass in multiple filepaths, but it is neither merged nor has a PR yet.
• For other cabal versions, we might also be able to hack something together. After the closure check is violated, we know exactly which unit-ids are missing. So, we can look them up in plan.json, then look up build-info.json files and report these back. This will not work for certain project setups, e.g. the dependency chain of hie-compat -> hiedb -> ghcide, since hiedb is not part of this project, we can't find the compilation options, afaict.

[fendor]

LGTM, let's go!