expand: Pick cfgs and cfg_attrs one by one, like other attributes
#92473
Conversation
rustbot
added
the
T-compiler
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit b21c022c081c8a6a8171d59636bc343789021b84 with merge 34b11d60da4bbfc5edb08212309a5616388876f0... |
petrochenkov
removed
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
petrochenkov
added
S-waiting-on-author
|
☀️ Try build successful - checks-actions |
|
Queued 34b11d60da4bbfc5edb08212309a5616388876f0 with parent ad0d419, future comparison URL. |
|
Finished benchmarking commit (34b11d60da4bbfc5edb08212309a5616388876f0): comparison url. Summary: This change led to moderate relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking 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 led to changes in compiler perf. @bors rollup=never |
rustbot
added
the
S-waiting-on-review
|
Ugh, the improvements are likely due to the #84110 part (which is an observable change). |
petrochenkov
removed
the
S-waiting-on-review
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 80f4f4b5c44fe3c14a95315173756c0c04d95669 with merge 1ea11a5b0c68fb5007144cdf7287545e8071b41e... |
petrochenkov
removed
the
S-waiting-on-author
|
☀️ Try build successful - checks-actions |
|
Queued 1ea11a5b0c68fb5007144cdf7287545e8071b41e with parent 7b13c62, future comparison URL. |
|
Finished benchmarking commit (1ea11a5b0c68fb5007144cdf7287545e8071b41e): comparison url. Summary: This change led to moderate relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking 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 led to changes in compiler perf. @bors rollup=never |
petrochenkov
force-pushed
the
ltrattr2
branch
from
edaa65f to
e87ce7a
Compare
petrochenkov
changed the title
cfgs and cfg_attrs one by one, like other attributescfgs and cfg_attrs one by one, like other attributes
|
This should be ready now. |
rustbot
added
S-waiting-on-review
|
@bors r+ |
|
📌 Commit e87ce7a has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (fd20513): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
…erister rustc_interface: Add a new query `pre_configure` It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early. Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes. This is a continuation of rust-lang#92473 and one more step to very unstable crate-level proc macro attributes maybe actually working. Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
…erister rustc_interface: Add a new query `pre_configure` It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early. Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes. This is a continuation of rust-lang#92473 and one more step to very unstable crate-level proc macro attributes maybe actually working. Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
…erister rustc_interface: Add a new query `pre_configure` It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early. Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes. This is a continuation of rust-lang#92473 and one more step to very unstable crate-level proc macro attributes maybe actually working. Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
…ister rustc_interface: Add a new query `pre_configure` It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early. Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes. This is a continuation of rust-lang#92473 and one more step to very unstable crate-level proc macro attributes maybe actually working. Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into `ast::Crate`.
This is a rebase of #83354, but without any language-changing parts
(except for #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
#[cfg]and#[cfg_attr]left-to-right for consistency with other attributes #83331)#[cfg]attributes during cfg-expansion #84110).Two exceptions to the "one by one" behavior are:
deriveandcfg_eval, they are still expanded in a batch, that's by design.#![feature]collection. I'll try to disentangle that logic later in a separate PR.r? @Aaron1011