-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Don't query stability data when staged_api
is off
#76656
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
Don't query stability data when staged_api
is off
#76656
Conversation
r? @lcnr (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit a447c21 with merge 2bc97edb7f7a2845b0c5942bc0a2ab9fc969cece... |
|
||
// The query lookup can take a measurable amount of time in crates with many items. Check if | ||
// the stability attributes are even enabled before using their queries. | ||
if self.feat.staged_api || self.tcx.sess.opts.debugging_opts.force_unstable_if_unmarked { |
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 wonder if we should optimize force_unstable_if_unmarked - we know the result of the query ahead of time if staged API is false, right?
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.
Is that flag used anywhere outside building libstd?
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.
No (well, rustc too), but speeding up compiler development if possible seems good.
☀️ Try build successful - checks-actions, checks-azure |
Queued 2bc97edb7f7a2845b0c5942bc0a2ab9fc969cece with parent dbb73f8, future comparison URL. |
Finished benchmarking try commit (2bc97edb7f7a2845b0c5942bc0a2ab9fc969cece): 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 |
This looks good to me 👍 @jonas-schievink do you want to implement the review by @Mark-Simulacrum in this PR? Otherwise r=me |
@bors r=lcnr |
📌 Commit a447c21 has been approved by |
⌛ Testing commit a447c21 with merge 2425de123523e1d5b68e8944d5891546ea8a82b1... |
💥 Test timed out |
@bors retry |
☀️ Test successful - checks-actions, checks-azure |
Hi! This PR showed up in the weekly perf triage report. It resulted in a moderate improvement in instruction counts (up to -1.5% on A small win, as expected. Nice work! |
This data only needs to be encoded when
#![feature(staged_api)]
or-Zforce-unstable-if-unmarked
is on. Running these queries takes measurable time on large crates with many items, so skip it when the unstable flags have not been enabled.