-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Remove #[cfg]
attributes during cfg-expansion
#84110
Conversation
Currently, we don't remove `#[cfg]` attributes from a target when the predicates pass. This PR removes all 'passing' `#[cfg]` attributes during cfg-expansion, which causes derive proc-macros to never see any `#[cfg]` attributes in the input token stream. With rust-lang#82608 merged, we can now do this without losing spans.
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
@bors r+ rollup- (not evaluating cfg predicates repeatedly may be a performance improvement) |
📌 Commit b17a82d has been approved by |
@bors rollup=never |
⌛ Testing commit b17a82d with merge aa99cb5670ac26f1c282fe15f225d30da351a9fa... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Some clippy test failures. |
@petrochenkov: You're correct - the following test: rust/src/tools/clippy/tests/ui/crashes/returns.rs Lines 3 to 9 in f1ca558
tests that lints are not emitted, due to this check: rust/src/tools/clippy/clippy_lints/src/returns.rs Lines 171 to 182 in f1ca558
cc @rust-lang/clippy: This PR removes passing Possible solutions:
|
The thing I proposed in #79341 (which also wants to use cfg in a way similar to clippy) is to expand |
Would that |
Yes.
The input may already differ due to |
Is there any need to be able to observe |
I'm not that concerned about breaking existing crates. My main concern is that this could lead to confusing scenarios where running Clippy produces very different output than running rustc normally. When I was patching crates for the various I think something very similar could end up happening here - a proc-macro crate (for whatever reason) starts checking for |
Especially with |
triage: Any updates? |
LL | extern crate edition_lint_paths; | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove it |
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 a regression, this test won't (shouldn't?) pass with the span change.
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 think it actually will pass with the span change, but it is still a regression. The reason it will pass is because the #[cfg]
will end up being applied to the fn main() {}
that is directly below (from a whitespace- and comment-ignoring point of view) this extern crate
.
Probably the test should be changed to use #![crate_type = "lib"]
and to remove fn main() {}
so it will fail if there's a future regression like this.
@Aaron1011 |
expand: Pick `cfg`s and `cfg_attrs` one by one, like other attributes This is a rebase of rust-lang#83354, but without any language-changing parts ~(except for rust-lang#84110, i.e. the attribute expansion order is the same. This is a pre-requisite for any other changes making cfg attributes closer to regular macro attributes - Possibly changing their expansion order (rust-lang#83331) - Keeping macro backtraces for cfg attributes, or otherwise making them visible after expansion without keeping them in place literally (rust-lang#84110). Two exceptions to the "one by one" behavior are: - cfgs eagerly expanded by `derive` and `cfg_eval`, they are still expanded in a batch, that's by design. - cfgs at the crate root, they are currently expanded not during the main expansion pass, but before that, during `#![feature]` collection. I'll try to disentangle that logic later in a separate PR. r? `@Aaron1011`
Closing this as inactive |
Currently, we don't remove
#[cfg]
attributes from a target when thepredicates pass. This PR removes all 'passing'
#[cfg]
attributesduring cfg-expansion, which causes derive proc-macros to never see any
#[cfg]
attributes in the input token stream.With #82608 merged, we can now do
this without losing spans.