expand: Leave traces when expanding cfg_attr attributes
#138515
Merged
+136
−19
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
rustbot
added
A-attributes
|
Some changes occurred in compiler/rustc_passes/src/check_attr.rs Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
petrochenkov
removed
the
S-waiting-on-review
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 14, 2025
expand: Leave traces when expanding `cfg_attr` attributes Currently `cfg_trace` just disappears during expansion, but after this PR `#[cfg_attr(some tokens)]` will leave a `#[cfg_attr_trace(some tokens)]` attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute). This trace attribute can then be used by lints or other diagnostics, rust-lang#133823 has some examples. Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior. This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise. The idea belongs to `@estebank.`
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
|
TODO: ignore the trace attributes during AST pretty-printing, we shouldn't break people parsing pretty-printed code, if possible. |
|
Finished benchmarking commit (c78b933): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking 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 may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.1%, secondary 3.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -1.7%, secondary 3.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 773.132s -> 772.081s (-0.14%) |
rustbot
added
perf-regression
petrochenkov
added
the
S-waiting-on-author
|
The slight regressions are expected, because we actually add more information to AST. |
|
@rustbot ready |
rustbot
added
S-waiting-on-review
|
Another idea - |
rustbot
added
S-waiting-on-author
rustbot
removed
the
S-waiting-on-author
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 17, 2025
expand: Leave traces when expanding `cfg_attr` attributes Currently `cfg_trace` just disappears during expansion, but after this PR `#[cfg_attr(some tokens)]` will leave a `#[cfg_attr_trace(some tokens)]` attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute). This trace attribute can then be used by lints or other diagnostics, rust-lang#133823 has some examples. Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior. This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise. The next step is to do the same thing with `cfg` attributes (`#[cfg(TRUE)]` currently remains in both AST and tokens after expanding, it should be replaced with a trace instead). The idea belongs to `@estebank.`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 17, 2025
expand: Leave traces when expanding `cfg_attr` attributes Currently `cfg_trace` just disappears during expansion, but after this PR `#[cfg_attr(some tokens)]` will leave a `#[cfg_attr_trace(some tokens)]` attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute). This trace attribute can then be used by lints or other diagnostics, rust-lang#133823 has some examples. Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior. This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise. The next step is to do the same thing with `cfg` attributes (`#[cfg(TRUE)]` currently remains in both AST and tokens after expanding, it should be replaced with a trace instead). The idea belongs to `@estebank.`
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 18, 2025
expand: Leave traces when expanding `cfg_attr` attributes Currently `cfg_trace` just disappears during expansion, but after this PR `#[cfg_attr(some tokens)]` will leave a `#[cfg_attr_trace(some tokens)]` attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute). This trace attribute can then be used by lints or other diagnostics, rust-lang#133823 has some examples. Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior. This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise. The next step is to do the same thing with `cfg` attributes (`#[cfg(TRUE)]` currently remains in both AST and tokens after expanding, it should be replaced with a trace instead). The idea belongs to `@estebank.`
|
The job Click to see the possible cause of the failure (guessed by this bot)For more information how to resolve CI failures of this job, visit this link. |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing d8e44b7 (parent) -> 78948ac (this PR) Test differencesShow 6 test diffs
Additionally, 4 doctest diffs were found. These are ignored, as they are noisy. Job group index
|
|
Finished benchmarking commit (78948ac): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -6.9%, secondary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -1.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 775.297s -> 774.951s (-0.04%) |
|
After this change, we see an It isn't clear to me if this is a true or false positive, since it seems to render correctly here: https://docs.aya-rs.dev/aya/maps/perf/struct.asyncperfeventarray. |
|
@tamird I'll fix it today or tomorrow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently
cfg_tracejust disappears during expansion, but after this PR#[cfg_attr(some tokens)]will leave a#[cfg_attr_trace(some tokens)]attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute).This trace attribute can then be used by lints or other diagnostics, #133823 has some examples.
Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior.
This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise.
The next step is to do the same thing with
cfgattributes (#[cfg(TRUE)]currently remains in both AST and tokens after expanding, it should be replaced with a trace instead).The idea belongs to @estebank.