Struct rustc_query_system::dep_graph::DepKindStruct

pub struct DepKindStruct<Tcx: DepContext> {
    pub is_anon: bool,
    pub is_eval_always: bool,
    pub fingerprint_style: FingerprintStyle,
    pub force_from_dep_node: Option<fn(tcx: Tcx, dep_node: DepNode<Tcx::DepKind>) -> bool>,
    pub try_load_from_on_disk_cache: Option<fn(_: Tcx, _: DepNode<Tcx::DepKind>)>,
}

This struct stores metadata about each DepKind.

Information is retrieved by indexing the DEP_KINDS array using the integer value of the DepKind. Overall, this allows to implement DepContext using this manual jump table instead of large matches.

Fields

is_anon: bool

Anonymous queries cannot be replayed from one compiler invocation to the next. When their result is needed, it is recomputed. They are useful for fine-grained dependency tracking, and caching within one compiler invocation.

is_eval_always: bool

Eval-always queries do not track their dependencies, and are always recomputed, even if their inputs have not changed since the last compiler invocation. The result is still cached within one compiler invocation.

fingerprint_style: FingerprintStyle

Whether the query key can be recovered from the hashed fingerprint. See DepNodeParams trait for the behaviour of each key type.

force_from_dep_node: Option<fn(tcx: Tcx, dep_node: DepNode<Tcx::DepKind>) -> bool>

The red/green evaluation system will try to mark a specific DepNode in the dependency graph as green by recursively trying to mark the dependencies of that DepNode as green. While doing so, it will sometimes encounter a DepNode where we don’t know if it is red or green and we therefore actually have to recompute its value in order to find out. Since the only piece of information that we have at that point is the DepNode we are trying to re-evaluate, we need some way to re-run a query from just that. This is what force_from_dep_node() implements.

In the general case, a DepNode consists of a DepKind and an opaque GUID/fingerprint that will uniquely identify the node. This GUID/fingerprint is usually constructed by computing a stable hash of the query-key that the DepNode corresponds to. Consequently, it is not in general possible to go back from hash to query-key (since hash functions are not reversible). For this reason force_from_dep_node() is expected to fail from time to time because we just cannot find out, from the DepNode alone, what the corresponding query-key is and therefore cannot re-run the query.

The system deals with this case letting try_mark_green fail which forces the root query to be re-evaluated.

Now, if force_from_dep_node() would always fail, it would be pretty useless. Fortunately, we can use some contextual information that will allow us to reconstruct query-keys for certain kinds of DepNodes. In particular, we enforce by construction that the GUID/fingerprint of certain DepNodes is a valid DefPathHash. Since we also always build a huge table that maps every DefPathHash in the current codebase to the corresponding DefId, we have everything we need to re-run the query.

Take the mir_promoted query as an example. Like many other queries, it just has a single parameter: the DefId of the item it will compute the validated MIR for. Now, when we call force_from_dep_node() on a DepNode with kind MirValidated, we know that the GUID/fingerprint of the DepNode is actually a DefPathHash, and can therefore just look up the corresponding DefId in tcx.def_path_hash_to_def_id.

try_load_from_on_disk_cache: Option<fn(_: Tcx, _: DepNode<Tcx::DepKind>)>

Invoke a query to put the on-disk cached value in memory.

Layout

Note: Most layout information is completely unstable and may even differ between compilations. The only exception is types with certain repr(...) attributes. Please see the Rust Reference’s “Type Layout” chapter for details on type layout guarantees.

Size: 24 bytes