-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
proc_macro_derive(attributes(path::to)) both does and doesn't work #55168
Comments
This may be an accidental regression from #50030, similarly to #53489. This cannot work without significant work and introducing an entirely new entity into name resolution ("derive helper modules" or something), so |
I don't think you can do this, as these work for attributes within the type on stable 1.32: use repro_derive::Example;
#[derive(Example)]
#[example::attr] // Does not work
struct Demo {
#[example::attr] // Works
field: i32,
}
fn main() {} extern crate proc_macro;
use proc_macro::TokenStream;
#[proc_macro_derive(Example, attributes(example::attr))]
pub fn example_derive(_input: TokenStream) -> TokenStream {
TokenStream::new()
} |
Oh god. Self-assigning, I should be able to fix it this weekend. |
Is there any suggested way to have my desired syntax of #[derive(Example)]
#[example::attr]
struct Demo {
#[example::attr]
field: i32,
} |
@shepmaster Actually, the derive macro itself could be able to introduce "tool modules" into scope (like |
@petrochenkov Is there a reason we cannot let From a user facing perspective at least, @shepmaster's #55168 (comment) example seems reasonable and "expected". |
Fixed in #58899
I'd prefer to see crater results first. |
Do not accidentally treat multi-segment meta-items as single-segment Fixes rust-lang#55168 and many other regressions from rust-lang#50030 Basically, attributes like `#[any::prefix::foo]` were commonly interpreted as `#[foo]` due to `name()` successfully returning the last segment (this applies to nested things as well `#[attr(any::prefix::foo)]`).
Do not accidentally treat multi-segment meta-items as single-segment Fixes rust-lang#55168 and many other regressions from rust-lang#50030 Basically, attributes like `#[any::prefix::foo]` were commonly interpreted as `#[foo]` due to `name()` successfully returning the last segment (this applies to nested things as well `#[attr(any::prefix::foo)]`).
Do not accidentally treat multi-segment meta-items as single-segment Fixes #55168 and many other regressions from #50030 Basically, attributes like `#[any::prefix::foo]` were commonly interpreted as `#[foo]` due to `name()` successfully returning the last segment (this applies to nested things as well `#[attr(any::prefix::foo)]`).
I would expect either for this to work or for
#[proc_macro_derive(attributes(..))]
to reject a path and only accept an ident, as specifying a path here doesn't work.The text was updated successfully, but these errors were encountered: