-
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
Compute default query providers at compile-time #87040
Conversation
All of the `provide` functions are made `const`, allowing us to compute the default local and extern query providers entirely at compile-time. In addition to moving runtime work to compile-time, this will allow our internal documentation to show all query implementations, once rust-lang#87038 is implemented.
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 366f8f3 with merge a50316edc0300b2760fd4fcb6df11c2851875464... |
@@ -737,35 +736,35 @@ pub fn prepare_outputs( | |||
Ok(outputs) | |||
} | |||
|
|||
pub static DEFAULT_QUERY_PROVIDERS: SyncLazy<Providers> = SyncLazy::new(|| { | |||
let providers = &mut Providers::default(); | |||
pub const DEFAULT_QUERY_PROVIDERS: Providers = { |
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 isn't the same semantics as before, it will make a copy of the Providers struct everywhere it's used (which defeats the whole point of having this in rustc proper, originally in #73566 I just use a thread_local in rustdoc and @eddyb asked me not to for performance reasons).
pub const DEFAULT_QUERY_PROVIDERS: Providers = { | |
pub static DEFAULT_QUERY_PROVIDERS: Providers = { |
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.
We already copy DEFAULT_QUERY_PROVIDERS
in both places where it's used, so making this a static
will just result in an unnecessary static allocation in the final library.
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's not copied in rustdoc:
> rg DEFAULT_QUERY_PROVIDERS src/librustdoc/
src/librustdoc/core.rs
295: (rustc_interface::DEFAULT_QUERY_PROVIDERS.typeck)(tcx, def_id)
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.
Anyway, I'm not completely opposed to changing it, but I don't think it belongs here. AIUI the point of this is to compute the providers at compiletime, which you can do without changing these to consts.
providers | ||
}; | ||
|
||
pub const DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = { |
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.
pub const DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = { | |
pub static DEFAULT_EXTERN_QUERY_PROVIDERS: Providers = { |
Oh yay, that was the PR I was looking for: #74347. Yes, changing |
☀️ Try build successful - checks-actions |
Queued a50316edc0300b2760fd4fcb6df11c2851875464 with parent a31431f, future comparison URL. |
Finished benchmarking try commit (a50316edc0300b2760fd4fcb6df11c2851875464): comparison url. Summary: This change led to significant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @bors rollup=never |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit aaeca08 with merge 24c4eabf24250ef1b13b23eb38ad979c56316abb... |
☀️ Try build successful - checks-actions |
Queued 24c4eabf24250ef1b13b23eb38ad979c56316abb with parent dfd7b8d, future comparison URL. |
Finished benchmarking try commit (24c4eabf24250ef1b13b23eb38ad979c56316abb): comparison url. Summary: This change led to significant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @bors rollup=never |
@Aaron1011 the changes LGTM. Do you have an idea where the perf regression could come from? |
Doesn't this PR run into the same issue described in #74283 (comment) ? Even if you use |
r? @eddyb |
Triage: |
Triage: |
I'm going to close this for now since there are performance regressions and I'm unclear whether they're possible to fix: #87040 (comment) |
All of the
provide
functions are madeconst
, allowingus to compute the default local and extern query providers
entirely at compile-time.
In addition to moving runtime work to compile-time, this will
allow our internal documentation to show all query implementations,
once #87038 is implemented.