Multiple Home Units

Here for CI. Seems to be basically working 😎

TODO

• Dependencies between home units

• Solution for Template Haskell splices assuming that compilation is relative to directory with cabal file

• Allow specifying module visibility for home package units

• Make package imports work with home units by adding a flag which informs GHC about what the package would be called, if it were one.

• Consistently use cwd for runProgram rather than rewriting paths

• Adds tests for -I and -optP-include

• Warnings for bad situations, which I need to think about

• Error for not loading a package in between two home units (p -> q -> r)

• Testing testing testing (tested loading lens and all dependencies, works fine).

Known Shortcomings (these should become issues)

• Think about how to deal with reexported modules, not sure how Cabal handles these, will probably leave unsupported in first iteration.
• Currently two backpack tests fail because HoleUnit doesn't distinguish when home unit it should be from.
• Loading wired-in packages (such as template-haskell) currently fails due to how wired-in packages get different -this-unit-id. Will probably leave unsupported as only template-haskell is really affected.
• Package thinning/renaming is not supported
• More complicated reexported (with renaming) not working
• Backpack almost certainly doesn't work with multiple home units, completely untested.
• Downsweep should be parallelized, it is quite slow with 1800 modules/139 packages.
• Some existing shortcomings with ghci (#20474 (closed) #20689) which are exposed more by this patch.

Future Work

• Rewrite .bkp mode to use multiple home units.
• Allow GHCi to load multiple home units, simple mode, one "main" unit, the rest depend on it.
• Should -working-dir offset source paths passed on the command line? (For example should C.hs be interpreted as work-dir/C.hs).(yes)