Module rustc_query_system::dep_graph::dep_node
source · Expand description
This module defines the DepNode type which the compiler uses to represent
nodes in the dependency graph. A DepNode consists of a DepKind (which
specifies the kind of thing it represents, like a piece of HIR, MIR, etc)
and a Fingerprint, a 128 bit hash value the exact meaning of which
depends on the node’s DepKind. Together, the kind and the fingerprint
fully identify a dependency node, even across multiple compilation sessions.
In other words, the value of the fingerprint does not depend on anything
that is specific to a given compilation session, like an unpredictable
interning key (e.g., NodeId, DefId, Symbol) or the numeric value of a
pointer. The concept behind this could be compared to how git commit hashes
uniquely identify a given commit and has a few advantages:
- A
DepNodecan simply be serialized to disk and loaded in another session without the need to do any “rebasing (like we have to do for Spans and NodeIds) or “retracing” like we had to do forDefIdin earlier implementations of the dependency graph. - A
Fingerprintis just a bunch of bits, which allowsDepNodeto implementCopy,Sync,Send,Freeze, etc. - Since we just have a bit pattern,
DepNodecan be mapped from disk into memory without any post-processing (e.g., “abomination-style” pointer reconstruction). - Because a
DepNodeis self-contained, we can instantiateDepNodesthat refer to things that do not exist anymore. In previous implementationsDepNodecontained aDefId. ADepNodereferring to something that had been removed between the previous and the current compilation session could not be instantiated because the current compilation session contained noDefIdfor thing that had been removed.
DepNode definition happens in rustc_middle with the define_dep_nodes!() macro.
This macro defines the DepKind enum and a corresponding DepConstructor enum. The
DepConstructor enum links a DepKind to the parameters that are needed at runtime in order
to construct a valid DepNode fingerprint.
Because the macro sees what parameters a given DepKind requires, it can
“infer” some properties for each kind of DepNode:
- Whether a
DepNodeof a given kind has any parameters at all. SomeDepNodes could represent global concepts with only one value. - Whether it is possible, in principle, to reconstruct a query key from a
given
DepNode. ManyDepKinds only require a singleDefIdparameter, in which case it is possible to map the node’s fingerprint back to theDefIdit was computed from. In other cases, too much information gets lost during fingerprint computation.
Structs
- This serves as an index into arrays built by
make_dep_kind_array. - This struct stores metadata about each DepKind.
- A “work product” corresponds to a
.o(or other) file that we save in between runs. These IDs do not have aDefIdbut rather some independent path or string that persists between runs without the need to be mapped or unmapped. (This ensures we can serialize them even in the absence of a tcx.)