-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Port #[rustc_as_ptr]
to the new attribute system
#142498
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
base: master
Are you sure you want to change the base?
Conversation
Some changes occurred in compiler/rustc_attr_data_structures Some changes occurred in compiler/rustc_attr_parsing Some changes occurred in compiler/rustc_passes/src/check_attr.rs |
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.
Or how these argumentless attributes should be called (I've loosely referred to them as markers in the name of the new module in this PR, but not sure how good it is).
"markers" already means quite a lot, see https://doc.rust-lang.org/nightly/nightly-rustc/rustc_attr_parsing/index.html for example.
Anyway, your questions seem to be about code organization - I think it would be better to organize attributes based on what they do rather than how they are parsed.
a single impl parsing all such attributes
The downside of this approach is that updating an attribute to take an argument would get annoying. Say if we had just #[blah]
and then changed it to #[blah(alot|maybe| <nothing>)]
then that would require moving all the code related to parsing blah
, rather than just making changes in it.
@@ -147,6 +147,9 @@ impl<'tcx> CheckAttrVisitor<'tcx> { | |||
| AttributeKind::ConstStabilityIndirect | |||
| AttributeKind::MacroTransparency(_), | |||
) => { /* do nothing */ } | |||
Attribute::Parsed(AttributeKind::AsPtr) => { | |||
self.check_applied_to_fn_or_method(hir_id, attr, span, target) |
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 ICE, check_applied_to_fn_or_method
runs attr.span() which aren't supported on parsed attributes
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.
Fixed
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 it isn't, look
rust/compiler/rustc_passes/src/check_attr.rs
Line 1835 in 86039cc
attr_span: attr.span(), |
It still calls attr.span()
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 it isn't, look
rust/compiler/rustc_passes/src/check_attr.rs
Line 1835 in 86039cc
attr_span: attr.span(), It still calls attr.span()
Which works fine, because of
https://github.com/rust-lang/rust/pull/142498/files#diff-67c494d6d292cbe0a96d420fa02cf4589c7fad5a8d9abbdfa317d49a8bdce6daR1305
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 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.
I kind of want to get rid of that function, the few that are in that list are there because it was too painful to migrate otherwise
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.
could you solve it properly?
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.
could you solve it properly?
Fully getting rid of that function is going to be quite an effort, because it is in impl AttributeExt for Attribute
, which is relied on by many parts of the compiler.
I've started the process (#142552) of migrating from Attribute
to either AttrItem
or AttributeKind
in other parts of the compiler, which should help both with getting rid of that impl
specifically and with other #131229-related changes in general.
While this PR can technically be fixed independently of #142552, it will cause merge conflicts, so I'm going to wait for that one first instead.
I agree with @mejrs here, all attributes should get their own parser. Only if a parsed hir attribute's diagnostics depends on more than one syntactic attribute is it sensible to combine accept functions (see stability, and for example I intend to do this with allow/deny) |
I do intend to make a simpler parser for single word attribute parsers just like there's already SingleAttributeParser. That transformation is trivial later, let's keep it as is for now. This change is at least conceptually good @GrigorenkoPV , just needs some minor work |
@rustbot author |
Reminder, once the PR becomes ready for a review, use |
21f71d7
to
86039cc
Compare
@rustbot ready |
@rustbot author |
@rustbot ready |
@rustbot author |
It might make sense to introduce some new parser analogous to
Single
, but even more simple: for parsing attributes that take no arguments and may appear only once (such as#[rustc_as_ptr]
or#[rustc_const_stable_indirect]
). Not sure if this should be a singleimpl
parsing all such attributes, or one impl per attribute. Or how it will play along with the upcoming rework of attribute validation. Or how these argumentless attributes should be called (I've loosely referred to them asmarkers
in the name of the new module in this PR, but not sure how good it is).This is a part of #131229, so
r? @jdonszelmann
For reference, the
#[rustc_as_ptr]
attribute was created back in #132732 as a followup to #128985.@rustbot label +S-blocked
Blocked on #142552.