-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Move attribute validation from rustc_parse
to rustc_attr_parsing
#143963
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?
Move attribute validation from rustc_parse
to rustc_attr_parsing
#143963
Conversation
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #143958) made this pull request unmergeable. Please resolve the merge conflicts. |
78e9f18
to
89169bd
Compare
This comment has been minimized.
This comment has been minimized.
b166f19
to
6b0c356
Compare
Signed-off-by: Jonathan Brouwer <[email protected]>
rustc_parse
to rustc_attr_parsing
Signed-off-by: Jonathan Brouwer <[email protected]>
Signed-off-by: Jonathan Brouwer <[email protected]>
6b0c356
to
4091a29
Compare
id: S::Id, | ||
emit_lint: &mut impl FnMut(AttributeLint<S::Id>), | ||
) { | ||
let builtin_attr_info = attr.ident().and_then(|ident| BUILTIN_ATTRIBUTE_MAP.get(&ident.name)); |
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 PR still gets safety information of attributes from BUILTIN_ATTRIBUTE_MAP
.
The BUILTIN_ATTRIBUTES
global duplicates quite some information (templates, encode cross crate, duplicate logic) from the new parsers. Is the long term goal to remove this global? If yes, I can also make a new match statement somewhere to store this information
@rustbot ready I don't expect this PR to have a performance effect but it should definitely get a perf run. Could you do this? |
|
Some changes occurred in compiler/rustc_attr_data_structures Some changes occurred in compiler/rustc_attr_parsing These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
This comment has been minimized.
This comment has been minimized.
Ok now how did I break incremental compilation?... |
Reminder, once the PR becomes ready for a review, use |
Signed-off-by: Jonathan Brouwer <[email protected]>
4091a29
to
cff21c0
Compare
@@ -278,7 +278,7 @@ pub fn no_mangle() {} | |||
#[rustc_clean(cfg = "cfail3")] | |||
#[rustc_clean(cfg = "cfail5")] | |||
#[rustc_clean(cfg = "cfail6")] | |||
#[no_mangle] | |||
#[unsafe(no_mangle)] |
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.
These changes are needed because the "this should be unsafe" lint (in edition <2021) is now produced by the attribute parsing system, and therefore stored in
rust/compiler/rustc_hir/src/hir.rs
Line 1537 in 0864097
pub delayed_lints: DelayedLints, |
One version of this test produces the lint (which matters, even though it is allowed, because it is stored as mentioned above), the other one does not. The easy solution is to make both versions not produce the lint, by adding unsafe
@rustbot ready |
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Move attribute validation from `rustc_parse` to `rustc_attr_parsing` This moves the old attribute validation from `rustc_parse` to `rustc_attr_parsing`. This PR is easiest to review commit-by-commit. This is part 1 of 2, of a fix for #143940, the perfomance regression caused by #143460. This PR does not yet fix the performance regression but does the refactoring work to prepare for fixing it. After all these changes there should be no functional change to the compiler, other than some re-ordering of the errors.
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (52b9195): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking 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. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @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.9%, secondary -3.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.6%, secondary 3.6%)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: 466.613s -> 465.542s (-0.23%) |
Hm I don't like that, I'm gonna see if I can figure out what is causing that. It's all incremental related so I think it might be the lint stashing |
☔ The latest upstream changes (presumably #144269) made this pull request unmergeable. Please resolve the merge conflicts. |
This moves the old attribute validation from
rustc_parse
torustc_attr_parsing
.This PR is easiest to review commit-by-commit.
This is part 1 of 2, of a fix for #143940, the perfomance regression caused by #143460.
This PR does not yet fix the performance regression but does the refactoring work to prepare for fixing it. After all these changes there should be no functional change to the compiler, other than some re-ordering of the errors.