-
Notifications
You must be signed in to change notification settings - Fork 13k
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 encode only locally used attrs #95562
Conversation
r? @estebank (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 b98bb027949f170814d85f3cc530638351349065 with merge 72c6b3095acbcb061511d821eb46205167a0f5f2... |
☀️ Try build successful - checks-actions |
Queued 72c6b3095acbcb061511d821eb46205167a0f5f2 with parent 0677edc, future comparison URL. |
Finished benchmarking commit (72c6b3095acbcb061511d821eb46205167a0f5f2): comparison url. Summary:
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. @bors rollup=never Footnotes |
Unfortunately, I believe the performance gains seen here are not real. The benchmark showing such large improvements was switched out for another version that uses a different feature set and compiles in general roughly twice as fast. You can find the discussion about this here |
r? @davidtwco Let's trigger another perf run to see what the actual improvements are (excluding the big improvements from the last run, probably going to be a modest improvement). @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b98bb027949f170814d85f3cc530638351349065 with merge ad580c3d5edddb91a7378991ba50ec39bd6676ef... |
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.
LGTM, r=me if perf results are good and you want to land this
☀️ Try build successful - checks-actions |
Queued ad580c3d5edddb91a7378991ba50ec39bd6676ef with parent 133859d, future comparison URL. |
Finished benchmarking commit (ad580c3d5edddb91a7378991ba50ec39bd6676ef): comparison url. Summary:
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. @bors rollup=never Footnotes |
Could we have a debug assertion to check that there is no attempt made to get an |
@@ -359,7 +378,7 @@ pub const BUILTIN_ATTRIBUTES: &[BuiltinAttribute] = &[ | |||
ungated!(panic_handler, Normal, template!(Word), WarnFollowing), // RFC 2070 | |||
|
|||
// Code generation: | |||
ungated!(inline, Normal, template!(Word, List: "always|never"), FutureWarnFollowing), | |||
ungated!(inline, Normal, template!(Word, List: "always|never"), FutureWarnFollowing, @only_local: true), | |||
ungated!(cold, Normal, template!(Word), WarnFollowing), |
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 can be skipped too I think.
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@481db40. Direct link to PR: <rust-lang/rust#95562> 💔 miri on windows: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk). 💔 miri on linux: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk).
Finished benchmarking commit (481db40): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Status: Compilation succeeds but regression fails due to new intrinsic. Relevant changes: - rust-lang/rust#95837 - rust-lang/rust#95562 - rust-lang/rust#96883
don't encode only locally used attrs Part of rust-lang/compiler-team#505. We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR. After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates. cc rust-lang#94963 (comment)
* Update rust toolchain to 2022-05-17 Status: Compilation succeeds but regression fails due to new intrinsic. Relevant changes: - rust-lang/rust#95837 - rust-lang/rust#95562 - rust-lang/rust#96883 * Implement new intrinsic ptr_offset_from_unsigned This new intrinsic is used in many different places in the standard library and it was failing some tests for vectors. * Apply suggestions from code review Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com> * Address PR comments - Fix order of checks. - Improve error message. - Add comments to the new tests. Co-authored-by: Adrian Palacios <73246657+adpaco-aws@users.noreply.github.com>
// FIXME(@lcnr): Remove this function. | ||
pub fn get_attrs_unchecked(self, did: DefId) -> &'tcx [ast::Attribute] { | ||
if let Some(did) = did.as_local() { | ||
self.hir().attrs(self.hir().local_def_id_to_hir_id(did)) | ||
} else { | ||
self.item_attrs(did) | ||
} | ||
} |
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.
Hey @lcnr , if and when you get around to removing this, what will be the recommended way to query for multi-component attributes?
We have a compiler tool with a late lint pass that checks for the presence of some foo::bar
attribute on items, and it seems like if you get rid of this function, I won't be able to query for that since PartialEq<Symbol> for Path
wants the path to have exactly one component.
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.
if i understand you correctly you should still be able to fetch all attributes with foo
and then check for the ones with bar
🤔
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 don't think so. If I get_attrs
with attr = Symbol("foo")
, then that calls a.has_name("foo")
for each attribute, which does a.path == "foo"
, and that ==
wants path
to have exactly one component:
rust/compiler/rustc_ast/src/ast.rs
Lines 103 to 108 in ebf9583
impl PartialEq<Symbol> for Path { | |
#[inline] | |
fn eq(&self, symbol: &Symbol) -> bool { | |
self.segments.len() == 1 && { self.segments[0].ident.name == *symbol } | |
} | |
} |
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.
ah... so we should maybe add something like get_tool_attrs
or something? 🤔 we definitely want to keep supporting this in some way '^^
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.
Something like that, yeah.
…ed}` [rust-lang/rust#95562][1] renames the existing method `get_attrs` to `get_attrs_unchecked` and introduces a new method in its former place. The new method takes an attribute name and returns attributes of that name. It also checks that, if the attribute name is marked as local- only, the given `DefId` is local as well to prevent misuses. The old method, now named `get_attrs_unchecked`, returns all attributes of a given `DefId`; thus it's "unchecked" in the sense that it's up to the callers to be certain whether the attributes they are looking for are local-only. The new `get_attrs` method lacks the support for attribute names with more than one path component, which is why we can't just migrate to the new `get_attrs` method here. Although `get_attrs_unchecked` is marked for future removal in the compile source code, there's also a discussion about [supporting][2] this use case. [1]: rust-lang/rust#95562 [2]: https://github.com/rust-lang/rust/pull/95562/files#r915537557
…ed}` [rust-lang/rust#95562][1] renames the existing method `get_attrs` to `get_attrs_unchecked` and introduces a new method in its former place. The new method takes an attribute name and returns attributes of that name. It also checks that, if the attribute name is marked as local- only, the given `DefId` is local as well to prevent misuses. The old method, now named `get_attrs_unchecked`, returns all attributes of a given `DefId`; thus it's "unchecked" in the sense that it's up to the callers to be certain whether the attributes they are looking for are local-only. The new `get_attrs` method lacks the support for attribute names with more than one path component, which is why we can't just migrate to the new `get_attrs` method here. Although `get_attrs_unchecked` is marked for future removal in the compile source code, there's a discussion about [supporting][2] this use case. [1]: rust-lang/rust#95562 [2]: https://github.com/rust-lang/rust/pull/95562/files#r915537557
Part of rust-lang/compiler-team#505.
We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse
get_attrs
now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a methodfn get_attrs_unchecked
which I intend to remove in a followup PR.After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.
cc #94963 (comment)