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
DepNode
can 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 forDefId
in earlier implementations of the dependency graph. - A
Fingerprint
is just a bunch of bits, which allowsDepNode
to implementCopy
,Sync
,Send
,Freeze
, etc. - Since we just have a bit pattern,
DepNode
can be mapped from disk into memory without any post-processing (e.g., “abomination-style” pointer reconstruction). - Because a
DepNode
is self-contained, we can instantiateDepNodes
that refer to things that do not exist anymore. In previous implementationsDepNode
contained aDefId
. ADepNode
referring to something that had been removed between the previous and the current compilation session could not be instantiated because the current compilation session contained noDefId
for 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
DepNode
of a given kind has any parameters at all. SomeDepNode
s could represent global concepts with only one value. - Whether it is possible, in principle, to reconstruct a query key from a
given
DepNode
. ManyDepKind
s only require a singleDefId
parameter, in which case it is possible to map the node’s fingerprint back to theDefId
it was computed from. In other cases, too much information gets lost during fingerprint computation.
Modules§
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 aDefId
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.)