-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Replace DepKind
by trait objects
#78314
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for cc-ing me. I left some nitpicks.
I can't comment on the larger picture though, because it's still to complicated for me after two weeks working in the query system. (It seems like I have chosen the worst part a beginner can work on. But at least it's a challenge!)
So, I'm curious what you envision the next steps to be here.
It seems orthogonal to what I tried in in #78275.
|
||
$( | ||
#[allow(non_camel_case_types)] | ||
pub struct $variant; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to rename $variant
to $name
here to be consistent with the proc macro and compiler/rustc_middle/src/ty/query/mod.rs
Specifically the inconsistency with the line $(impl dep_kind::$name {
bothers me.
pub mod dep_kind { | ||
$( | ||
#[allow(non_camel_case_types)] | ||
#[derive(Debug)] | ||
pub struct $variant; | ||
)* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this struct to define_dep_kinds
.
@@ -24,14 +25,14 @@ pub type PreviousDepGraph = rustc_query_system::dep_graph::PreviousDepGraph<DepK | |||
pub type SerializedDepGraph = rustc_query_system::dep_graph::SerializedDepGraph<DepKind>; | |||
|
|||
impl rustc_query_system::dep_graph::DepKind for DepKind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these different types that are named DepKind
get confusing.
Maybe name it DynDepKind
?
@@ -103,95 +120,136 @@ macro_rules! contains_eval_always_attr { | |||
($($attr:ident $(($($attr_args:tt)*))* ),*) => ({$(is_eval_always_attr!($attr) | )* false}); | |||
} | |||
|
|||
macro_rules! define_dep_nodes { | |||
macro_rules! define_dep_kinds { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this into a new file dep_kind.rs
.
@@ -765,7 +753,7 @@ impl<'a, 'tcx> Decodable<CacheDecoder<'a, 'tcx>> for &'tcx [Span] { | |||
//- ENCODING ------------------------------------------------------------------- | |||
|
|||
/// This trait is a hack to work around specialization bug #55243. | |||
trait OpaqueEncoder: Encoder { | |||
pub trait OpaqueEncoder: Encoder { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why move the trait to make it private and then make it public again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This trait is a hack. Ideally, all E: OpaqueEncoder
should be E = opaque::Encoder
. It needs to be public because it appears in CacheEncoder
, which is public because it appears in DepKindTrait
. Removing E: OpaqueEncoder
from CacheEncoder
definition breaks specialization (I don't know why).
// FIXME: This match is just a workaround for incremental bugs and should | ||
// be removed. https://github.com/rust-lang/rust/issues/62649 is one such | ||
// bug that must be fixed before removing this. | ||
match self.index() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All this workaround code is now duplicated for every dep_kind::$variant
. That's not good for compile times.
What's the reason for doing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this was a bad idea.
@@ -481,51 +459,28 @@ pub fn rustc_queries(input: TokenStream) -> TokenStream { | |||
if modifiers.eval_always { | |||
attributes.push(quote! { eval_always }); | |||
}; | |||
// Pass on the cache modifier | |||
if modifiers.cache.is_some() { | |||
attributes.push(quote! { cached }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this attribute used? I can't find it.
EDIT: Fount it in encode_query_results
. Can you add a comment documenting this dependency?
$($variant),* | ||
} | ||
|
||
pub static DEP_KINDS: &[DepKind] = &[ $(&dep_kind::$variant),* ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting trick! ^^
@@ -304,6 +526,271 @@ rustc_dep_node_append!([define_dep_nodes!][ <'tcx> | |||
[] CompileCodegenUnit(Symbol), | |||
]); | |||
|
|||
impl DepKindTrait for dep_kind::Null { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't these traits be implemented by the macro, by adding them to the
rustc_dep_node_append!([define_dep_kinds!][ <'tcx> ]);
invokation,
similarly to how it's done for define_dep_nodes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those DepKind
s are not associated to queries. This requires a special workaround for force_from_dep_node
and try_load_from_on_disk_cache
.
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit 41720af with merge ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf... |
☀️ Try build successful - checks-actions |
Queued ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf with parent 89fdb30, future comparison URL. |
Finished benchmarking try commit (ca3c21d7ea44af5f9bbe58698ce3fd2e5cd675bf): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Access query (DepKind) metadata through fields This refactors the access to query definition metadata (attributes such as eval always, anon, has_params) and loading/forcing functions to generate a number of structs, instead of matching on the DepKind enum. This makes access to the fields cheaper to compile. Using a struct means that finding the metadata for a given query is just an offset away; previously the match may have been compiled to a jump table but likely not completely inlined as we expect here. A previous attempt explored a similar strategy, but using trait objects in rust-lang#78314 that proved less effective, likely due to higher overheads due to forcing dynamic calls and poorer cache utilization (all metadata is fairly densely packed with this PR).
Most of the code depending on
DepNode
s just matches on theirDepKind
.This PR replaces those matches by trait objects, using a unit struct for each
DepKind
variant.Everything still has to be declared inside
rustc_middle
, but the need for the macros is significantly reduced.I would have preferred defining the trait inside
rustc_query_system
, but this needs more work.cc @Julian-Wollersberger
Based on #77830 for the first few commits.