Repository navigation
Clarify cross-crate dependency story #32015
Description
We're currently doing some wrong-ish things with respect to dep-graph tracking across crate boundaries. I think what I want to do is this:
- Create a
DepNode::MetaData(DefId)variant that plays a role likeHir- it basically represents the metadata for some item
- Whenever we load from metadata for item
X, we'll generate a read onMetaData(X) - In the metadata, we'll include a hash for each item, either:
- hashing the saved contents of the item
- or hashing all the base input nodes that are deps of the things serialized into
- basically some hash we can use to tell if the metadata for an item changed in some way
- When we save the dep-graph, we'll save the hash out of the crate metadata
- When we load, we'll reload the hash out of the current crate metadata and compare
For inlined items, I hope we will transition to MIR and not need to inline sooner or later, but in the meantime, I think we can basically translate reads to Hir(X) where X is an inlined def-id to MetaData(Y) where Y is the original def-id -- we may also just be able to ignore accesses to inlined def-ids, since we'll presumably add an appropriate edge from some other source.
Activity
Auto merge of #32016 - nikomatsakis:incr-comp-save, r=mw
michaelwoerister commentedon Jul 19, 2016
I think this is implemented (mostly via #32016) except for correctly handling access to inlined HIR.
As far as I can see, there is no special handling of inlined HIR anywhere, which means that the following will happen:
nikomatsakis commentedon Jul 23, 2016
@michaelwoerister
I agree -- however, it seems like inlined HIR is going away. That is, once we transition to MIR trans, this point will no longer be an issue, right?