Expand items before their derives by abonander · Pull Request #48465 · rust-lang/rust (original) (raw)

@nrc Ok.

To be clear, cfgs are only evaluated out of order with respect to derive macros, not any other kind.

I don't think we can land this because changing expansion order is a breaking change

I doubt this is breaking in practice, but yeah back-compat could complicate things...

The fact that cfgs are evaluated out of order with respect to macros is an unfortunate historical artefact and shouldn't be considered precedent here.

I think it's worth noting though that just about every major derive macro today needs cfg to be expanded first. That is, if the historical artifact had not existed, just about every derive macro would need to opt in to (at least) cfg getting expanded first (via expand: Tokenstream -> Tokenstream or some other mechanism) to support people deriving things on structs with conditionally compiled fields.

The trouble I think is that one can create examples which benefit from either expansion order

Can you think of examples of derives that don't want their input fully expanded? These seem like a far smaller class, especially if we assume that attribute macros will eventually be allowed on struct fields.

Given that, I think we must go for the most predictable and consistent behaviour

I think most predictable/consistent would be either everything is expanded first, or the macro sees the original, raw, unmodified Tokenstream from the source code. Halfway seems weird.

I like @abonander's idea of allowing the macro author to request either unexpanded or fully expanded input. If derive back-compat is an issue, not requesting either could default to today's behavior.