Skip to content

Commit 921b284

Browse files
committed
Make force_from_dep_node a function pointer.
1 parent bee1fbb commit 921b284

File tree

3 files changed

+90
-110
lines changed

3 files changed

+90
-110
lines changed

compiler/rustc_middle/src/dep_graph/dep_node.rs

+69-1
Original file line numberDiff line numberDiff line change
@@ -66,6 +66,7 @@ use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, CRATE_DEF_INDEX};
6666
use rustc_hir::definitions::DefPathHash;
6767
use rustc_hir::HirId;
6868
use rustc_span::symbol::Symbol;
69+
use rustc_span::DUMMY_SP;
6970
use std::hash::Hash;
7071

7172
pub use rustc_query_system::dep_graph::{DepContext, DepNodeParams};
@@ -95,6 +96,50 @@ pub struct DepKindStruct {
9596
// can be made a specialized associated const.
9697
can_reconstruct_query_key: fn() -> bool,
9798

99+
/// The red/green evaluation system will try to mark a specific DepNode in the
100+
/// dependency graph as green by recursively trying to mark the dependencies of
101+
/// that `DepNode` as green. While doing so, it will sometimes encounter a `DepNode`
102+
/// where we don't know if it is red or green and we therefore actually have
103+
/// to recompute its value in order to find out. Since the only piece of
104+
/// information that we have at that point is the `DepNode` we are trying to
105+
/// re-evaluate, we need some way to re-run a query from just that. This is what
106+
/// `force_from_dep_node()` implements.
107+
///
108+
/// In the general case, a `DepNode` consists of a `DepKind` and an opaque
109+
/// GUID/fingerprint that will uniquely identify the node. This GUID/fingerprint
110+
/// is usually constructed by computing a stable hash of the query-key that the
111+
/// `DepNode` corresponds to. Consequently, it is not in general possible to go
112+
/// back from hash to query-key (since hash functions are not reversible). For
113+
/// this reason `force_from_dep_node()` is expected to fail from time to time
114+
/// because we just cannot find out, from the `DepNode` alone, what the
115+
/// corresponding query-key is and therefore cannot re-run the query.
116+
///
117+
/// The system deals with this case letting `try_mark_green` fail which forces
118+
/// the root query to be re-evaluated.
119+
///
120+
/// Now, if `force_from_dep_node()` would always fail, it would be pretty useless.
121+
/// Fortunately, we can use some contextual information that will allow us to
122+
/// reconstruct query-keys for certain kinds of `DepNode`s. In particular, we
123+
/// enforce by construction that the GUID/fingerprint of certain `DepNode`s is a
124+
/// valid `DefPathHash`. Since we also always build a huge table that maps every
125+
/// `DefPathHash` in the current codebase to the corresponding `DefId`, we have
126+
/// everything we need to re-run the query.
127+
///
128+
/// Take the `mir_promoted` query as an example. Like many other queries, it
129+
/// just has a single parameter: the `DefId` of the item it will compute the
130+
/// validated MIR for. Now, when we call `force_from_dep_node()` on a `DepNode`
131+
/// with kind `MirValidated`, we know that the GUID/fingerprint of the `DepNode`
132+
/// is actually a `DefPathHash`, and can therefore just look up the corresponding
133+
/// `DefId` in `tcx.def_path_hash_to_def_id`.
134+
///
135+
/// When you implement a new query, it will likely have a corresponding new
136+
/// `DepKind`, and you'll have to support it here in `force_from_dep_node()`. As
137+
/// a rule of thumb, if your query takes a `DefId` or `LocalDefId` as sole parameter,
138+
/// then `force_from_dep_node()` should not fail for it. Otherwise, you can just
139+
/// add it to the "We don't have enough information to reconstruct..." group in
140+
/// the match below.
141+
pub(super) force_from_dep_node: fn(tcx: TyCtxt<'_>, dep_node: &DepNode) -> bool,
142+
98143
/// Invoke a query to put the on-disk cached value in memory.
99144
pub(super) try_load_from_on_disk_cache: fn(TyCtxt<'_>, &DepNode),
100145
}
@@ -156,7 +201,7 @@ macro_rules! contains_eval_always_attr {
156201
pub mod dep_kind {
157202
use super::*;
158203
use crate::ty::query::{queries, query_keys};
159-
use rustc_query_system::query::QueryDescription;
204+
use rustc_query_system::query::{force_query, QueryDescription};
160205

161206
// We use this for most things when incr. comp. is turned off.
162207
pub const Null: DepKindStruct = DepKindStruct {
@@ -165,6 +210,7 @@ pub mod dep_kind {
165210
is_eval_always: false,
166211

167212
can_reconstruct_query_key: || true,
213+
force_from_dep_node: |_, dep_node| bug!("force_from_dep_node: encountered {:?}", dep_node),
168214
try_load_from_on_disk_cache: |_, _| {},
169215
};
170216

@@ -175,6 +221,7 @@ pub mod dep_kind {
175221
is_eval_always: true,
176222

177223
can_reconstruct_query_key: || true,
224+
force_from_dep_node: |_, dep_node| bug!("force_from_dep_node: encountered {:?}", dep_node),
178225
try_load_from_on_disk_cache: |_, _| {},
179226
};
180227

@@ -184,6 +231,7 @@ pub mod dep_kind {
184231
is_eval_always: false,
185232

186233
can_reconstruct_query_key: || false,
234+
force_from_dep_node: |_, _| false,
187235
try_load_from_on_disk_cache: |_, _| {},
188236
};
189237

@@ -193,6 +241,7 @@ pub mod dep_kind {
193241
is_eval_always: false,
194242

195243
can_reconstruct_query_key: || false,
244+
force_from_dep_node: |_, _| false,
196245
try_load_from_on_disk_cache: |_, _| {},
197246
};
198247

@@ -217,6 +266,24 @@ pub mod dep_kind {
217266
<query_keys::$variant<'_> as DepNodeParams<TyCtxt<'_>>>::recover(tcx, dep_node)
218267
}
219268

269+
fn force_from_dep_node(tcx: TyCtxt<'_>, dep_node: &DepNode) -> bool {
270+
if !can_reconstruct_query_key() {
271+
return false;
272+
}
273+
274+
if let Some(key) = recover(tcx, dep_node) {
275+
force_query::<queries::$variant<'_>, _>(
276+
tcx,
277+
key,
278+
DUMMY_SP,
279+
*dep_node
280+
);
281+
return true;
282+
}
283+
284+
false
285+
}
286+
220287
fn try_load_from_on_disk_cache(tcx: TyCtxt<'_>, dep_node: &DepNode) {
221288
if !can_reconstruct_query_key() {
222289
return
@@ -238,6 +305,7 @@ pub mod dep_kind {
238305
is_anon,
239306
is_eval_always,
240307
can_reconstruct_query_key,
308+
force_from_dep_node,
241309
try_load_from_on_disk_cache,
242310
}
243311
};)*

compiler/rustc_middle/src/dep_graph/mod.rs

+20-2
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,6 @@ use rustc_hir::def_id::LocalDefId;
88

99
mod dep_node;
1010

11-
pub(crate) use rustc_query_system::dep_graph::DepNodeParams;
1211
pub use rustc_query_system::dep_graph::{
1312
debug, hash_result, DepContext, DepNodeColor, DepNodeIndex, SerializedDepNodeIndex,
1413
WorkProduct, WorkProductId,
@@ -155,7 +154,26 @@ impl<'tcx> DepContext for TyCtxt<'tcx> {
155154
}
156155

157156
debug!("try_force_from_dep_node({:?}) --- trying to force", dep_node);
158-
ty::query::force_from_dep_node(*self, dep_node)
157+
158+
// We must avoid ever having to call `force_from_dep_node()` for a
159+
// `DepNode::codegen_unit`:
160+
// Since we cannot reconstruct the query key of a `DepNode::codegen_unit`, we
161+
// would always end up having to evaluate the first caller of the
162+
// `codegen_unit` query that *is* reconstructible. This might very well be
163+
// the `compile_codegen_unit` query, thus re-codegenning the whole CGU just
164+
// to re-trigger calling the `codegen_unit` query with the right key. At
165+
// that point we would already have re-done all the work we are trying to
166+
// avoid doing in the first place.
167+
// The solution is simple: Just explicitly call the `codegen_unit` query for
168+
// each CGU, right after partitioning. This way `try_mark_green` will always
169+
// hit the cache instead of having to go through `force_from_dep_node`.
170+
// This assertion makes sure, we actually keep applying the solution above.
171+
debug_assert!(
172+
dep_node.kind != DepKind::codegen_unit,
173+
"calling force_from_dep_node() on DepKind::codegen_unit"
174+
);
175+
176+
(dep_node.kind.force_from_dep_node)(*self, dep_node)
159177
}
160178

161179
fn has_errors_or_delayed_span_bugs(&self) -> bool {

compiler/rustc_middle/src/ty/query/mod.rs

+1-107
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
use crate::dep_graph::{self, DepKind, DepNode, DepNodeParams};
1+
use crate::dep_graph;
22
use crate::hir::exports::Export;
33
use crate::hir::map;
44
use crate::infer::canonical::{self, Canonical};
@@ -103,112 +103,6 @@ pub use self::profiling_support::{IntoSelfProfilingString, QueryKeyStringBuilder
103103

104104
rustc_query_append! { [define_queries!][<'tcx>] }
105105

106-
/// The red/green evaluation system will try to mark a specific DepNode in the
107-
/// dependency graph as green by recursively trying to mark the dependencies of
108-
/// that `DepNode` as green. While doing so, it will sometimes encounter a `DepNode`
109-
/// where we don't know if it is red or green and we therefore actually have
110-
/// to recompute its value in order to find out. Since the only piece of
111-
/// information that we have at that point is the `DepNode` we are trying to
112-
/// re-evaluate, we need some way to re-run a query from just that. This is what
113-
/// `force_from_dep_node()` implements.
114-
///
115-
/// In the general case, a `DepNode` consists of a `DepKind` and an opaque
116-
/// GUID/fingerprint that will uniquely identify the node. This GUID/fingerprint
117-
/// is usually constructed by computing a stable hash of the query-key that the
118-
/// `DepNode` corresponds to. Consequently, it is not in general possible to go
119-
/// back from hash to query-key (since hash functions are not reversible). For
120-
/// this reason `force_from_dep_node()` is expected to fail from time to time
121-
/// because we just cannot find out, from the `DepNode` alone, what the
122-
/// corresponding query-key is and therefore cannot re-run the query.
123-
///
124-
/// The system deals with this case letting `try_mark_green` fail which forces
125-
/// the root query to be re-evaluated.
126-
///
127-
/// Now, if `force_from_dep_node()` would always fail, it would be pretty useless.
128-
/// Fortunately, we can use some contextual information that will allow us to
129-
/// reconstruct query-keys for certain kinds of `DepNode`s. In particular, we
130-
/// enforce by construction that the GUID/fingerprint of certain `DepNode`s is a
131-
/// valid `DefPathHash`. Since we also always build a huge table that maps every
132-
/// `DefPathHash` in the current codebase to the corresponding `DefId`, we have
133-
/// everything we need to re-run the query.
134-
///
135-
/// Take the `mir_promoted` query as an example. Like many other queries, it
136-
/// just has a single parameter: the `DefId` of the item it will compute the
137-
/// validated MIR for. Now, when we call `force_from_dep_node()` on a `DepNode`
138-
/// with kind `MirValidated`, we know that the GUID/fingerprint of the `DepNode`
139-
/// is actually a `DefPathHash`, and can therefore just look up the corresponding
140-
/// `DefId` in `tcx.def_path_hash_to_def_id`.
141-
///
142-
/// When you implement a new query, it will likely have a corresponding new
143-
/// `DepKind`, and you'll have to support it here in `force_from_dep_node()`. As
144-
/// a rule of thumb, if your query takes a `DefId` or `LocalDefId` as sole parameter,
145-
/// then `force_from_dep_node()` should not fail for it. Otherwise, you can just
146-
/// add it to the "We don't have enough information to reconstruct..." group in
147-
/// the match below.
148-
pub fn force_from_dep_node<'tcx>(tcx: TyCtxt<'tcx>, dep_node: &DepNode) -> bool {
149-
// We must avoid ever having to call `force_from_dep_node()` for a
150-
// `DepNode::codegen_unit`:
151-
// Since we cannot reconstruct the query key of a `DepNode::codegen_unit`, we
152-
// would always end up having to evaluate the first caller of the
153-
// `codegen_unit` query that *is* reconstructible. This might very well be
154-
// the `compile_codegen_unit` query, thus re-codegenning the whole CGU just
155-
// to re-trigger calling the `codegen_unit` query with the right key. At
156-
// that point we would already have re-done all the work we are trying to
157-
// avoid doing in the first place.
158-
// The solution is simple: Just explicitly call the `codegen_unit` query for
159-
// each CGU, right after partitioning. This way `try_mark_green` will always
160-
// hit the cache instead of having to go through `force_from_dep_node`.
161-
// This assertion makes sure, we actually keep applying the solution above.
162-
debug_assert!(
163-
dep_node.kind != DepKind::codegen_unit,
164-
"calling force_from_dep_node() on DepKind::codegen_unit"
165-
);
166-
167-
if !dep_node.kind.can_reconstruct_query_key() {
168-
return false;
169-
}
170-
171-
macro_rules! force_from_dep_node {
172-
($($(#[$attr:meta])* [$($modifiers:tt)*] $name:ident($K:ty),)*) => {
173-
match dep_node.kind {
174-
// These are inputs that are expected to be pre-allocated and that
175-
// should therefore always be red or green already.
176-
DepKind::CrateMetadata |
177-
178-
// These are anonymous nodes.
179-
DepKind::TraitSelect |
180-
181-
// We don't have enough information to reconstruct the query key of
182-
// these.
183-
DepKind::CompileCodegenUnit |
184-
185-
// Forcing this makes no sense.
186-
DepKind::Null => {
187-
bug!("force_from_dep_node: encountered {:?}", dep_node)
188-
}
189-
190-
$(DepKind::$name => {
191-
debug_assert!(<$K as DepNodeParams<TyCtxt<'_>>>::can_reconstruct_query_key());
192-
193-
if let Some(key) = <$K as DepNodeParams<TyCtxt<'_>>>::recover(tcx, dep_node) {
194-
force_query::<queries::$name<'_>, _>(
195-
tcx,
196-
key,
197-
DUMMY_SP,
198-
*dep_node
199-
);
200-
return true;
201-
}
202-
})*
203-
}
204-
}
205-
}
206-
207-
rustc_dep_node_append! { [force_from_dep_node!][] }
208-
209-
false
210-
}
211-
212106
mod sealed {
213107
use super::{DefId, LocalDefId};
214108

0 commit comments

Comments
 (0)