Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get rid of DepConstructor #80829

Merged
merged 1 commit into from
Jan 14, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 13 additions & 32 deletions compiler/rustc_middle/src/dep_graph/dep_node.rs
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,10 @@
//! contained no `DefId` for thing that had been removed.
//!
//! `DepNode` definition happens in the `define_dep_nodes!()` macro. This macro
//! defines the `DepKind` enum and a corresponding `dep_constructor` module. The
//! `dep_constructor` module links a `DepKind` to the parameters that are needed at
//! runtime in order to construct a valid `DepNode` fingerprint.
//! defines the `DepKind` enum. Each `DepKind` has its own parameters that are
//! needed at runtime in order to construct a valid `DepNode` fingerprint.
//! However, only `CompileCodegenUnit` is constructed explicitly (with
//! `make_compile_codegen_unit`).
//!
//! Because the macro sees what parameters a given `DepKind` requires, it can
//! "infer" some properties for each kind of `DepNode`:
Expand All @@ -44,22 +45,14 @@
//! `DefId` it was computed from. In other cases, too much information gets
//! lost during fingerprint computation.
//!
//! The `dep_constructor` module, together with `DepNode::new()`, ensures that only
//! `make_compile_codegen_unit`, together with `DepNode::new()`, ensures that only
//! valid `DepNode` instances can be constructed. For example, the API does not
//! allow for constructing parameterless `DepNode`s with anything other
//! than a zeroed out fingerprint. More generally speaking, it relieves the
//! user of the `DepNode` API of having to know how to compute the expected
//! fingerprint for a given set of node parameters.

use crate::mir::interpret::{GlobalId, LitToConstInput};
use crate::traits;
use crate::traits::query::{
CanonicalPredicateGoal, CanonicalProjectionGoal, CanonicalTyGoal,
CanonicalTypeOpAscribeUserTypeGoal, CanonicalTypeOpEqGoal, CanonicalTypeOpNormalizeGoal,
CanonicalTypeOpProvePredicateGoal, CanonicalTypeOpSubtypeGoal,
};
use crate::ty::subst::{GenericArg, SubstsRef};
use crate::ty::{self, ParamEnvAnd, Ty, TyCtxt};
use crate::ty::TyCtxt;

use rustc_data_structures::fingerprint::Fingerprint;
use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, CRATE_DEF_INDEX};
Expand Down Expand Up @@ -338,25 +331,6 @@ macro_rules! define_dep_nodes {
$($variant),*
}

#[allow(non_camel_case_types)]
pub mod dep_constructor {
use super::*;

$(
#[inline(always)]
#[allow(unreachable_code, non_snake_case)]
pub fn $variant(_tcx: TyCtxt<'_>, $(arg: $tuple_arg_ty)*) -> DepNode {
// tuple args
$({
erase!($tuple_arg_ty);
return DepNode::construct(_tcx, DepKind::$variant, &arg)
})*

return DepNode::construct(_tcx, DepKind::$variant, &())
}
)*
}

fn dep_kind_from_label_string(label: &str) -> Result<DepKind, ()> {
match label {
$(stringify!($variant) => Ok(DepKind::$variant),)*
Expand Down Expand Up @@ -384,9 +358,16 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx>

[anon] TraitSelect,

// WARNING: if `Symbol` is changed, make sure you update `make_compile_codegen_unit` below.
[] CompileCodegenUnit(Symbol),
]);

// WARNING: `construct` is generic and does not know that `CompileCodegenUnit` takes `Symbol`s as keys.
// Be very careful changing this type signature!
crate fn make_compile_codegen_unit(tcx: TyCtxt<'_>, name: Symbol) -> DepNode {
DepNode::construct(tcx, DepKind::CompileCodegenUnit, &name)
}

pub type DepNode = rustc_query_system::dep_graph::DepNode<DepKind>;

// We keep a lot of `DepNode`s in memory during compilation. It's not
Expand Down
3 changes: 2 additions & 1 deletion compiler/rustc_middle/src/dep_graph/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,8 @@ pub use rustc_query_system::dep_graph::{
WorkProduct, WorkProductId,
};

pub use dep_node::{dep_constructor, label_strs, DepKind, DepNode, DepNodeExt};
crate use dep_node::make_compile_codegen_unit;
pub use dep_node::{label_strs, DepKind, DepNode, DepNodeExt};

pub type DepGraph = rustc_query_system::dep_graph::DepGraph<DepKind>;
pub type TaskDeps = rustc_query_system::dep_graph::TaskDeps<DepKind>;
Expand Down
4 changes: 2 additions & 2 deletions compiler/rustc_middle/src/mir/mono.rs
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
use crate::dep_graph::{dep_constructor, DepNode, WorkProduct, WorkProductId};
use crate::dep_graph::{DepNode, WorkProduct, WorkProductId};
use crate::ich::{NodeIdHashingMode, StableHashingContext};
use crate::ty::{subst::InternalSubsts, Instance, InstanceDef, SymbolName, TyCtxt};
use rustc_data_structures::base_n;
Expand Down Expand Up @@ -358,7 +358,7 @@ impl<'tcx> CodegenUnit<'tcx> {
}

pub fn codegen_dep_node(&self, tcx: TyCtxt<'tcx>) -> DepNode {
dep_constructor::CompileCodegenUnit(tcx, self.name())
crate::dep_graph::make_compile_codegen_unit(tcx, self.name())
}
}

Expand Down