This module defines the
DepNode type which the compiler uses to represent
nodes in the dependency graph. A
DepNode consists of a
specifies the kind of thing it represents, like a piece of HIR, MIR, etc)
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:
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 for
DefIdin earlier implementations of the dependency graph.
Fingerprintis just a bunch of bits, which allows
- 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 instantiate
DepNodesthat refer to things that do not exist anymore. In previous implementations
DepNodereferring to something that had been removed between the previous and the current compilation session could not be instantiated because the current compilation session contained no
DefIdfor thing that had been removed.
DepNode definition happens in
rustc_middle with the
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
Because the macro sees what parameters a given
DepKind requires, it can
“infer” some properties for each kind of
- Whether a
DepNodeof a given kind has any parameters at all. Some
DepNodes could represent global concepts with only one value.
- Whether it is possible, in principle, to reconstruct a query key from a
DepKinds only require a single
DefIdparameter, in which case it is possible to map the node’s fingerprint back to the
DefIdit was computed from. In other cases, too much information gets lost during fingerprint computation.
A “work product” corresponds to a
.o (or other) file that we
save in between runs. These IDs do not have a
DefId but 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.)