-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Port diagnostic::do_not_recommend to new attr parsing
#151056
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: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred in compiler/rustc_passes/src/check_attr.rs cc @jdonszelmann, @JonathanBrouwer Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor Some changes occurred in compiler/rustc_attr_parsing cc @jdonszelmann, @JonathanBrouwer Some changes occurred in compiler/rustc_hir/src/attrs |
|
☔ The latest upstream changes (presumably #151051) made this pull request unmergeable. Please resolve the merge conflicts. |
787588b to
b54dd13
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
b54dd13 to
d53e06b
Compare
This comment has been minimized.
This comment has been minimized.
| if parts == &[sym::rustc_dummy] { | ||
| // The arguments of rustc_dummy and diagnostic attributes are not validated | ||
| // if the arguments are delimited | ||
| if parts == &[sym::rustc_dummy] || parts[0] == sym::diagnostic { |
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.
Hmmm the special casting of this attribute is a little ugly here. Especially since this will affect all diagnostic attributes, and we're introducing a new one soon (#150935) which should not suffer the mistakes from the past
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 we perhaps do a crater run and see how bad making a breaking change is for this? Since these attributes are so niche I expect making the breaking change will be fine
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.
which should not suffer the mistakes from the past
There were no mistakes, this is the intended behavior. That is, any syntactically valid input is allowed, similar to attribute macros. I do not want to shut the door on being able to use non-metaitem syntax going forward. For example in the future I'd like to expand these attributes to reference types and traits, and something like From<i32> is not valid metaitem syntax.
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 we want to do this in the future, we would need to add support for parsing types and traits to the attribute parser. As I see it, that is even more an argument for removing this special case now, since this special case skips the attribute parser for this attribute.
I.e. If this attribute skips the attribute parser now, we can not use the attribute parser to parse any arguments in the future
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 we want to do this in the future, we would need to add support for parsing types and traits to the attribute parser.
Yes, we would need to add some kind of support for that. But the semantics of the diagnostic namespace are that any such future extensions are ignored by older compilers and do not raise errors.
In other words: to extend the attribute in the future, we must be maximally permissive now.
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.
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 see, that makes sense, thanks for explaining!
Could you add a comment to https://doc.rust-lang.org/reference/attributes/diagnostics.html#r-attributes.diagnostic.namespace.unknown-invalid-syntax on this check then?
This still doesn't really solve the usecase for diagnostic attributes that do need to have arguments parsed. Ideally the attribute parser would run, but any errors should be warnings instead. Not sure if we should solve this problem in this PR or when it comes up tho
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.
Not sure if we should solve this problem in this PR or when it comes up tho
This will be an issue with the other diagnostic attributes, so I'll see if I can figure something out.
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.
Nice job! Some minor comments :)
|
Reminder, once the PR becomes ready for a review, use |
|
(Jana feel free to steal the assign back, since I think you two might know eachother?) |
d53e06b to
ed6e630
Compare
|
I've pushed the link , I'll need to think more about a proper fix for the other diagnostic attributes. But that doesn't matter today. @rustbot ready |
|
Don't expect this to have a significant performance impact, but attr parsing has been surprisingly perf sensitive so let's see |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Port `diagnostic::do_not_recommend` to new attr parsing
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (f1840ed): comparison URL. Overall result: ❌✅ regressions and improvements - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.8%, secondary -3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.7%, secondary 3.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 474.176s -> 474.127s (-0.01%) |
r? @jdonszelmann