Long story short: in my attribute proc-macro I need to detect presence of other proc-macro attributes. It looks like I can see other attributes if they are placed after (below of) my macro and can't see ones before (above) it.
The question is: is this order specified and can I rely on it? Is there any plans to change this behavior?
I'm asking here and not on users.forum because I think this question is should be adressed directly to compiler hackers, so here I am.
Expansion order for macros on the same item is left-to-right
#[attr1] // Expands first, sees attr2 and attr3 as a part of its input.
#[attr2] // Expands second, sees attr3 as a part of its input.
#[attr3] // Expands last, doesn't see the other attributes as a part of its input.
struct S;
#[cfg] is the exception and is always expands first, but I'd like to change that and see what happens, and perhaps issue a warning when expansion order doesn't match the source code order.
Things become a bit more complex when inert attributes are added to the mix - https://github.com/rust-lang/rust/issues/63221.
#[inert_attr] // "Expands" first by just leaving itself in place and marking itself as expanded.
#[macro_attr] // Expands second with input `#[inert_attr] struct S;`
struct S;
So, does it mean I can rely on this expansion order or this is subject to change in the future?
Well, the behavior (LTR expansion order of macro attributes on the same item) is available on stable, reasonable, and there are no plans to change it, so I think it can be relied upon.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.