Make #[derive(A, B, ...)] cfg-eval its input only for A, B, ... and stabilize feature(macro_attributes_in_derive_output)

[petrochenkov]

Stabilization report: #87220 (comment)

Closes #81119
r? @Aaron1011

[petrochenkov]

Stabilization Report

Historically #[derive] attribute eagerly expands all cfg and cfg_attr attributes in its item ("fully configures" it) before passing that item to derive macros.

For example, in the next example

#[derive(Trait)]
struct S {
    #[cfg(FALSE)]
    field: u8,
}

Trait will see tokens struct S {} rather than struct S { #[cfg(FALSE)] field: u8, }.

PR #79078 ("Turn #[derive] into a regular macro attribute") supported macro attributes written after #[derive]:

#[derive(Trait)]
#[my_macro]
struct S {
    #[cfg(FALSE)]
    field: u8,
}

Attributes on the same item are expanded in left to right order, so my_macro is expanded immediately after derive.
The question is: which tokens my_macro receives as an input?

1. It can receive the original, not configured, item. In other words #[derive] feeds a configured version of the item to Trait, but otherwise emit the item in unmodified form so all the cfgs and cfg_attrs in it are expanded later in natural order.
2. It can receive the same fully configured item as Trait.
3. It can receive the item transformed in some entirely different way (not considering this variant here, no motivation to do that).

Code depending on the answer is currently gated by feature(macro_attributes_in_derive_output).

We propose stabilizing the variant 1. and feeding the fully configured item only to traits inside #[derive] and keeping the original item it for later expansion.
This seems to be the most principled solution - #[derive] only affects itself and not attributes written after it.
As a result attributes that want to do custom cfg processing (like those found by crater in #85073 (comment)) can be written after #[derive] too.
The variant 1. also prevents abusing empty #[derive()] as a cfg-expanding attribute (this problem is going to be addressed by #[cfg_eval] (#82679) which I'm planning to stabilize next).
The main concern here is performance because some things may need to be configured twice, but as a perf experiment in #86057 shows, it's not an issue in practice.

The more radical alternative is to fully configure items before expanding any attributes, not only derive.
That alternative was implemented as an experiment in #85073.
Crater showed that there are indeed attributes that want to do some custom cfg processing (#85073 (comment)) which are broken by this change, so we need some kind opt-out from eager configuration, but it's not clear how that opt-out should look like.
We suggest considering switching to this alternative for the next edition (~Rust 2024), but leave it alone for now.

Examples

#[derive(Trait)] // (1) `Trait` sees `struct S {}` as input
#[my_macro] // (2) `my_macro` sees `struct S { #[cfg(FALSE)] field: u8, }` as input
struct S {
    #[cfg(FALSE)]
    field: u8,
}

Test cases

• src/test/ui/proc-macro/attribute-after-derive.rs - (2) in the example above
• src\test\ui\proc-macro\expand-to-derive.rs or any other test with derive and cfg - (1) in the example above

Documentation

rust-lang/reference#1074

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting. We agreed with this proposal, and we think it makes sense to change this for current Rust. We do feel that we should move to eager-evaluation by default for a future edition, with an opt-out for macros/attributes that really want to deal with unevaluated cfg. But for now, this change seems like the right approach.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[Aaron1011]

r=me with the merge conflicts addressed

[petrochenkov]

@bors r=Aaron1011

[bors]

📌 Commit 85f0290 has been approved by Aaron1011

[bors]

⌛ Testing commit 85f0290 with merge 60fe8b3...

[bors]

☀️ Test successful - checks-actions
Approved by: Aaron1011
Pushing 60fe8b3 to master...

[rust-timer]

Finished benchmarking commit (60fe8b3): 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