|
29 | 29 | //! contained no `DefId` for thing that had been removed.
|
30 | 30 | //!
|
31 | 31 | //! `DepNode` definition happens in the `define_dep_nodes!()` macro. This macro
|
32 |
| -//! defines the `DepKind` enum and a corresponding `dep_constructor` module. The |
33 |
| -//! `dep_constructor` module links a `DepKind` to the parameters that are needed at |
34 |
| -//! runtime in order to construct a valid `DepNode` fingerprint. |
| 32 | +//! defines the `DepKind` enum. Each `DepKind` has its own parameters that are |
| 33 | +//! needed at runtime in order to construct a valid `DepNode` fingerprint. |
| 34 | +//! However, only `CompileCodegenUnit` is constructed explicitly (with |
| 35 | +//! `make_compile_codegen_unit`). |
35 | 36 | //!
|
36 | 37 | //! Because the macro sees what parameters a given `DepKind` requires, it can
|
37 | 38 | //! "infer" some properties for each kind of `DepNode`:
|
|
44 | 45 | //! `DefId` it was computed from. In other cases, too much information gets
|
45 | 46 | //! lost during fingerprint computation.
|
46 | 47 | //!
|
47 |
| -//! The `dep_constructor` module, together with `DepNode::new()`, ensures that only |
| 48 | +//! `make_compile_codegen_unit`, together with `DepNode::new()`, ensures that only |
48 | 49 | //! valid `DepNode` instances can be constructed. For example, the API does not
|
49 | 50 | //! allow for constructing parameterless `DepNode`s with anything other
|
50 | 51 | //! than a zeroed out fingerprint. More generally speaking, it relieves the
|
51 | 52 | //! user of the `DepNode` API of having to know how to compute the expected
|
52 | 53 | //! fingerprint for a given set of node parameters.
|
53 | 54 |
|
54 |
| -use crate::mir::interpret::{GlobalId, LitToConstInput}; |
55 |
| -use crate::traits; |
56 |
| -use crate::traits::query::{ |
57 |
| - CanonicalPredicateGoal, CanonicalProjectionGoal, CanonicalTyGoal, |
58 |
| - CanonicalTypeOpAscribeUserTypeGoal, CanonicalTypeOpEqGoal, CanonicalTypeOpNormalizeGoal, |
59 |
| - CanonicalTypeOpProvePredicateGoal, CanonicalTypeOpSubtypeGoal, |
60 |
| -}; |
61 |
| -use crate::ty::subst::{GenericArg, SubstsRef}; |
62 |
| -use crate::ty::{self, ParamEnvAnd, Ty, TyCtxt}; |
| 55 | +use crate::ty::TyCtxt; |
63 | 56 |
|
64 | 57 | use rustc_data_structures::fingerprint::Fingerprint;
|
65 | 58 | use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, CRATE_DEF_INDEX};
|
@@ -338,25 +331,6 @@ macro_rules! define_dep_nodes {
|
338 | 331 | $($variant),*
|
339 | 332 | }
|
340 | 333 |
|
341 |
| - #[allow(non_camel_case_types)] |
342 |
| - pub mod dep_constructor { |
343 |
| - use super::*; |
344 |
| - |
345 |
| - $( |
346 |
| - #[inline(always)] |
347 |
| - #[allow(unreachable_code, non_snake_case)] |
348 |
| - pub fn $variant(_tcx: TyCtxt<'_>, $(arg: $tuple_arg_ty)*) -> DepNode { |
349 |
| - // tuple args |
350 |
| - $({ |
351 |
| - erase!($tuple_arg_ty); |
352 |
| - return DepNode::construct(_tcx, DepKind::$variant, &arg) |
353 |
| - })* |
354 |
| - |
355 |
| - return DepNode::construct(_tcx, DepKind::$variant, &()) |
356 |
| - } |
357 |
| - )* |
358 |
| - } |
359 |
| - |
360 | 334 | fn dep_kind_from_label_string(label: &str) -> Result<DepKind, ()> {
|
361 | 335 | match label {
|
362 | 336 | $(stringify!($variant) => Ok(DepKind::$variant),)*
|
@@ -384,9 +358,16 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx>
|
384 | 358 |
|
385 | 359 | [anon] TraitSelect,
|
386 | 360 |
|
| 361 | + // WARNING: if `Symbol` is changed, make sure you update `make_compile_codegen_unit` below. |
387 | 362 | [] CompileCodegenUnit(Symbol),
|
388 | 363 | ]);
|
389 | 364 |
|
| 365 | +// WARNING: `construct` is generic and does not know that `CompileCodegenUnit` takes `Symbol`s as keys. |
| 366 | +// Be very careful changing this type signature! |
| 367 | +crate fn make_compile_codegen_unit(tcx: TyCtxt<'_>, name: Symbol) -> DepNode { |
| 368 | + DepNode::construct(tcx, DepKind::CompileCodegenUnit, &name) |
| 369 | +} |
| 370 | + |
390 | 371 | pub type DepNode = rustc_query_system::dep_graph::DepNode<DepKind>;
|
391 | 372 |
|
392 | 373 | // We keep a lot of `DepNode`s in memory during compilation. It's not
|
|
0 commit comments