Struct rustc_query_impl::plumbing::QueryStruct

pub struct QueryStruct {
    pub(crate) force_from_dep_node: fn(tcx: QueryCtxt<'_>, dep_node: &DepNode) -> bool,
    pub(crate) try_load_from_on_disk_cache: fn(_: QueryCtxt<'_>, _: &DepNode),
}

This struct stores metadata about each Query.

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

Fields

force_from_dep_node: fn(tcx: QueryCtxt<'_>, dep_node: &DepNode) -> 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.

When you implement a new query, it will likely have a corresponding new DepKind, and you’ll have to support it here in force_from_dep_node(). As a rule of thumb, if your query takes a DefId or LocalDefId as sole parameter, then force_from_dep_node() should not fail for it. Otherwise, you can just add it to the “We don’t have enough information to reconstruct…” group in the match below.

try_load_from_on_disk_cache: fn(_: QueryCtxt<'_>, _: &DepNode)

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