-
John Ericson authored
Backpack instantiations need to be typechecked to make sure that the arguments fit the parameters. `tcRnInstantiateSignature` checks instantiations with concrete modules, while `tcRnCheckUnitId` checks instantiations with free holes (signatures in the current modules). Before this change, it worked that `tcRnInstantiateSignature` was called after typechecking the argument module, see `HscMain.hsc_typecheck`, while `tcRnCheckUnitId` was called in `unsweep'` where-bound in `GhcMake.upsweep`. `tcRnCheckUnitId` was called once per each instantiation once all the argument sigs were processed. This was done with simple "to do" and "already done" accumulators in the fold. `parUpsweep` did not implement the change. With this change, `tcRnCheckUnitId` instead is associated with its own node in the `ModuleGraph`. Nodes are now: ```haskell data WorkGraphNode = InstantiationNode IndefUnitId | ModuleNode ModSummary ``` instead of just `ModSummary`; the `InstantiationNode` case is the instantiation of a unit to be checked. The dependencies of such nodes are the same free holes as was checked with the accumulator before. Both upsweeps on such a node call `tcRnCheckUnitId`. The instantiation nodes are not depended on by other nodes; `tcRnCheckUnitId` is just being called for errors. I do take this as evidence for the argument that perhaps my patch is over-engineered; one could also just leave the graph as-is and post upsweep `tcRnCheckUnitId` all unit-ids unconditionally. Now, if there is extra `-j` sooner one can get the errors quicker than that with mine, but without the dependencies into the merged node (mimicking the eagerness of the fold of the sequential upsweep) this isn't guaranteed to happen. I admit I went with the current approach before I realized that nothing else depended on the effects for `tcRnCheckUnitId`, but I still think it is the right one with future changes in mind. For this, I refer to "Note [Identity versus semantic module]". The current reasoning appeals to the compilation pipeline invariants, but if we get multi package support [proposal 23], we could have all three of the original signature, argument, and instiation in home packages. I think having separate dependency nodes for each of those 3 might yield more incrementality and/or parallelism, especially if nodes became per pipeline stage. Fixes #17188 Things yet to do: * [ ] There are extra numbered steps that don't print out, probably should have some `[m of n] checking instantiation ...` * [ ] Errors are rendered slightly differently for some reason [proposal 23]: https://github.com/ghc-proposals/ghc-proposals/pull/263
c56de4b8