incr. comp.: Clarify story around MIR dependency tracking

[michaelwoerister]

At the moment, dependency tracking around MIR related things is not implemented completely. In particular:

• We generate various MIR-related dependency nodes (MirMapConstruction, MirPass, MirTypeck) but we don't seem to register any reads to these nodes later on: The MirMap allows for accessing MIR with the dependency tracking system knowing about it.
• There doesn't seem to be a reason why MirTypeck is its own kind of dependency node while all other passes use the MirPass node.
• There is no clear dependency node for registering read edges to after MIR has been fully constructed. MirMapConstruction more or less tracks dependencies of constructing MIR before any transformations are done on it. Reusing it for registering reads to the final MIR would be possible, but would lead to a strange tangle of circular dependencies between MirMapConstruction, MirTypeck, and MirPass nodes. It would not be wrong but it would be messy.

I suggest that we either just have one kind of MIR dependency node that subsumes MIR construction and all transformations on it, or that we have a more accurate representation of dependencies where each kind of MIR pass has its own kind of dependency node and then there is a FinalMir node, that represents the MIR in its final state.

[michaelwoerister]

cc @nikomatsakis

[nikomatsakis]

Yeah, this seems bad. I've also been thinking a bit about how to go about saving/restoring MIR -- as the .o re-use stuff gets close to completion, and MIR-trans is landing, this is going to be the Next Big Step to save a lot of compilation time.

The most straight-forward thing would be to model the MIR passes the way we model everything else:

• MirMap(DefId) -- tracks the MIR that we created for a given def-id.
• one DepNode variant per MIR pass, so e.g. MirConstruction, MirSimplify, MirElaborate, etc.

This seems like the most straightforward thing to do. But I think it's probably more data than we need. I think we could collapse all the passes into one with no loss of fidelity. For that matter, we could probably just remove the dep-node for the pass and just use a single dep-node (Mir) for both the mir itself and passes that construct and transform the MIR. That would seem to match your "simple" suggestion. I think we should go for that -- but view it as an "optimization" on the canonical model.

Generalizing somewhat, if the purpose of a pass is just to produce a single particular data-structure, then distinguishing MirBuild(DefId) from Mir(DefId) doesn't seem to buy us anything.

But if we have a single pass that may generate a lot of data-structures, I think it makes more sense, particularly if those data structures can be changed from other places (otherwise, you can lose precision in the graph).

[michaelwoerister]

Is there any case you foresee where it would make sense to have more than one DepNode? As long as each pass just produces a transformed version of a function's MIR, the simple approach should be fine, I think.

[nikomatsakis]

This was fixed by #35166.