@@ -149,6 +149,67 @@ where
149149 }
150150}
151151
152+ /// This struct stores metadata about each DepKind.
153+ ///
154+ /// Information is retrieved by indexing the `DEP_KINDS` array using the integer value
155+ /// of the `DepKind`. Overall, this allows to implement `DepContext` using this manual
156+ /// jump table instead of large matches.
157+ pub struct DepKindStruct < CTX : DepContext > {
158+ /// Anonymous queries cannot be replayed from one compiler invocation to the next.
159+ /// When their result is needed, it is recomputed. They are useful for fine-grained
160+ /// dependency tracking, and caching within one compiler invocation.
161+ pub is_anon : bool ,
162+
163+ /// Eval-always queries do not track their dependencies, and are always recomputed, even if
164+ /// their inputs have not changed since the last compiler invocation. The result is still
165+ /// cached within one compiler invocation.
166+ pub is_eval_always : bool ,
167+
168+ /// Whether the query key can be recovered from the hashed fingerprint.
169+ /// See [DepNodeParams] trait for the behaviour of each key type.
170+ pub fingerprint_style : FingerprintStyle ,
171+
172+ /// The red/green evaluation system will try to mark a specific DepNode in the
173+ /// dependency graph as green by recursively trying to mark the dependencies of
174+ /// that `DepNode` as green. While doing so, it will sometimes encounter a `DepNode`
175+ /// where we don't know if it is red or green and we therefore actually have
176+ /// to recompute its value in order to find out. Since the only piece of
177+ /// information that we have at that point is the `DepNode` we are trying to
178+ /// re-evaluate, we need some way to re-run a query from just that. This is what
179+ /// `force_from_dep_node()` implements.
180+ ///
181+ /// In the general case, a `DepNode` consists of a `DepKind` and an opaque
182+ /// GUID/fingerprint that will uniquely identify the node. This GUID/fingerprint
183+ /// is usually constructed by computing a stable hash of the query-key that the
184+ /// `DepNode` corresponds to. Consequently, it is not in general possible to go
185+ /// back from hash to query-key (since hash functions are not reversible). For
186+ /// this reason `force_from_dep_node()` is expected to fail from time to time
187+ /// because we just cannot find out, from the `DepNode` alone, what the
188+ /// corresponding query-key is and therefore cannot re-run the query.
189+ ///
190+ /// The system deals with this case letting `try_mark_green` fail which forces
191+ /// the root query to be re-evaluated.
192+ ///
193+ /// Now, if `force_from_dep_node()` would always fail, it would be pretty useless.
194+ /// Fortunately, we can use some contextual information that will allow us to
195+ /// reconstruct query-keys for certain kinds of `DepNode`s. In particular, we
196+ /// enforce by construction that the GUID/fingerprint of certain `DepNode`s is a
197+ /// valid `DefPathHash`. Since we also always build a huge table that maps every
198+ /// `DefPathHash` in the current codebase to the corresponding `DefId`, we have
199+ /// everything we need to re-run the query.
200+ ///
201+ /// Take the `mir_promoted` query as an example. Like many other queries, it
202+ /// just has a single parameter: the `DefId` of the item it will compute the
203+ /// validated MIR for. Now, when we call `force_from_dep_node()` on a `DepNode`
204+ /// with kind `MirValidated`, we know that the GUID/fingerprint of the `DepNode`
205+ /// is actually a `DefPathHash`, and can therefore just look up the corresponding
206+ /// `DefId` in `tcx.def_path_hash_to_def_id`.
207+ pub force_from_dep_node : Option < fn ( tcx : CTX , dep_node : DepNode < CTX :: DepKind > ) -> bool > ,
208+
209+ /// Invoke a query to put the on-disk cached value in memory.
210+ pub try_load_from_on_disk_cache : Option < fn ( CTX , DepNode < CTX :: DepKind > ) > ,
211+ }
212+
152213/// A "work product" corresponds to a `.o` (or other) file that we
153214/// save in between runs. These IDs do not have a `DefId` but rather
154215/// some independent path or string that persists between runs without
0 commit comments