Remove #[cfg] attributes during cfg-expansion#84110
Remove #[cfg] attributes during cfg-expansion#84110Aaron1011 wants to merge 1 commit intorust-lang:masterfrom
#[cfg] attributes during cfg-expansion#84110Conversation
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.
This is a regression, this test won't (shouldn't?) pass with the span change.
There was a problem hiding this comment.
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.