proc_macro_derive(attributes(path::to)) both does and doesn't work

// crate `derive`
// lib.proc-macro = true
#[proc_macro_derive(WellThen, attributes(well::then))]
pub fn derive(i: ::proc_macro::TokenStream) -> ::proc_macro::TokenStream {
    i
}

// crate `user`
use derive::WellThen;
#[derive(WellThen)]
#[well::then]
struct A;

error[E0433]: failed to resolve. Use of undeclared type or module `well`
  --> user\main.rs:3:3
   |
 3 | #[well::then]
   |   ^^^^ Use of undeclared type or module `well`

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.

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 #[proc_macro_derive(attributes(..))] needs to validate its arguments harder and reject non-identifier paths.

reject non-identifier paths

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.
If not reject, then issue a deprecation warning immediately.

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

@shepmaster
Not right now, but something like #57921 may help.

Actually, the derive macro itself could be able to introduce "tool modules" into scope (like rustfmt in rustfmt::skip, but not global to the whole crate).
#[proc_macro_derive(Example, tools(example))] or something.
Right now this is almost trivial to add for "macro expanded" attribute targets, like the item itself, but some additional work is needed to support it for other targets, e.g. fields (as you can see #[rustfmt::skip] doesn't work on fields yet).

@petrochenkov

@petrochenkov Is there a reason we cannot let #[proc_macro_derive(Example, attributes(example::attr))] mean #[proc_macro_derive(Example, tools(example))] plus some validation for the ::attr part? handwave

From a user facing perspective at least, @shepmaster's #55168 (comment) example seems reasonable and "expected".

Fixed in #58899

Is there a reason we cannot let #[proc_macro_derive(Example, attributes(example::attr))] ...

I'd prefer to see crater results first.

Rollup merge of rust-lang#58899 - petrochenkov:derval2, r=estebank

Navigation Menu

Repository navigation

proc_macro_derive(attributes(path::to)) both does and doesn't work #55168

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

proc_macro_derive(attributes(path::to)) both does and doesn't work #55168

Description

Activity

petrochenkov commented on Oct 18, 2018

shepmaster commented on Feb 27, 2019

petrochenkov commented on Feb 27, 2019

shepmaster commented on Feb 27, 2019

petrochenkov commented on Feb 27, 2019

Centril commented on Feb 28, 2019

petrochenkov commented on Mar 3, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions