-
Notifications
You must be signed in to change notification settings - Fork 13.3k
proc_macro_derive(attributes(path::to)) both does and doesn't work #55168
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: