Nodes in the dependency graph.
A node in the dependency graph is represented by 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.,
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. The fingerprinting approach 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 the
define_dep_nodes!() macro. This macro
DepKind enum. Each
DepKind has its own parameters that are
needed at runtime in order to construct a valid
CompileMonoItem are constructed
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.
make_compile_mono_items, together with
DepNode::new(), ensures that only valid
DepNode instances can be
constructed. For example, the API does not allow for constructing
DepNodes with anything other than a zeroed out fingerprint.
More generally speaking, it relieves the user of the
DepNode API of
having to know how to compute the expected fingerprint for a given set of
- Contains variant => str representations for constructing DepNode groups for tests.
- This serves as an index into arrays built by
- This enum serves as an index into arrays built by