-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Remove #[cfg]
attributes during cfg-expansion
#84110
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.