-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run decorators on expanded AST #34010
Conversation
cc @durka |
This is (I think) a breaking change since a decorator author could be using macros in the AST as input to their functionality. I think I prefer the expansion order to be the same for all attributes, seems confusing to have difference expansion orders. Other than #32950, is there any reason to do this? re #32950, I think a better fix is to implement |
What if the decorator produces more decorators? |
cc #33769, the previous attempt to fix this |
@durka decorator-generated items would still get expanded. |
Agreed, but I'm pretty sure it wouldn't break anything in practice.
I agree that this would be a downside.
I believe some use cases of decorators might benefit from having access to expanded AST, but I don't have any specific examples in mind (besides #32950, of course). In lieu of specific examples, a thought experiment: if we allowed macros in field declaration positions (not saying this would be a good idea), for example struct Foo {
x: i32,
mac!(), //< say `mac!()` expands to `y: i32`
} then |
That being said, I only weakly support this PR -- @nrc if you still don't think this is a good idea I'll close. |
Only a plugin-breaking-change, to be clear, since the only stable "decorator author" is rustc. |
It does seem to make some intuitive sense that a decorator on an item would be the last thing to be expanded, after any macros which generate parts of the item. But what about |
Agreed, although it could theoretically break code that uses (unstable) decorator plugins without breaking the plugins themselves (highly unlikely, imo).
We would expand macro_rules! mac {
(#[derive($i:ident)] $it:item) => { println!(stringify!($i)); }
}
fn main() {
mac! { #[derive(Foo)] struct Bar; } // prints "Foo"
} After expanding |
9747f66
to
635a82e
Compare
Hmm, I'm still not super-happy about having different expansion orders, but this seems to be a fine solution other than that. I think it should probably land. We'll have an opportunity to change direction with the procedural macro overhaul in any case. @bors: r+ |
📌 Commit 635a82e has been approved by |
Fixes #32950.
r? @nrc