-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[WIP] Expand all attributes in left-to-right order #83354
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
@bors try |
⌛ Trying commit 6a42bf1e0b4588b67e16e436325a62eecd8e5f78 with merge 99a443d6903f71d521237d8acb5a3016b534d17b... |
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot retry-report |
🛠️ Generation of the report for ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
There's a variety of errors (some of them are strange and I need to check why they happen in more detail), but my impression so far is that we won't be able to do this. #[generate_something]
#[cfg(FALSE)]
ITEM where "something" is unintentionally generated despite the We should be able to report warnings for out-of-order expansions though (similarly to #79202). I haven't seen regressions from |
Analysis of regressions. Group 1: Proc macro attribute is written before
Group 2:
Group 3:
Group 4: Some lints use
|
Blocked on #87220. |
☔ The latest upstream changes (presumably #84956) made this pull request unmergeable. Please resolve the merge conflicts. |
expand: Move some more derive logic to rustc_builtin_macros And cleanup some `unwrap`s in `cfg_eval`. Refactorings extracted from rust-lang#83354 and rust-lang#86057. r? `@Aaron1011`
expand: Move some more derive logic to rustc_builtin_macros And cleanup some `unwrap`s in `cfg_eval`. Refactorings extracted from rust-lang#83354 and rust-lang#86057. r? ``@Aaron1011``
Superseded by #92473. |
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`
Fixes #83331.
r? @Aaron1011