The idea is to make the initial refactors so we can have multi-package ghci (and perhaps ghc --make too). That feature is just super useful. It also falls under the principle that units of code for humans (top level definitions, modules, components, packages...) should be completely independent of units of work for the tools---humans should be able to organize things without worrying about how the machines will cope.
Credit to Ken Micklas for doing this work and getting the ball rolling.
The first PR is pretty much mechanistic except for two parts:
-
Package imports now are resolved in other home package tables, though they don't yet filter those by name as they should
-
ghc --backpackuses this when setting up a new DynFlags, though it still uses the ExternalPackageTable when perhaps it shouldn't.
After this PR, I really want to do something like https://github.com/ghc-proposals/ghc-proposals/pull/266 but for HscEnv, so I have a better idea of which parts of the code base access which information. This will make it easier to refine the data structures, as there's some friction today (both with and without this change).
-
are either individually buildable or squashed -
have commit messages which describe what they do (referring to Notes and tickets using #NNNNsyntax when appropriate) -
have added source comments describing your change. For larger changes you likely should add a Note and cross-reference it from the relevant places. -
add a testcase to the testsuite. -
replace this message with a description motivating your change
If you have any questions don't hesitate to open your merge request and inquire
in a comment. If your patch isn't quite done yet please do add prefix your MR
title with WIP:.