feature(proc_macro) breaks attributes on custom derive

[evestera]

Using #![feature(proc_macro)] in combination with attributes enabled by #[proc_macro_derive(MyTrait, attributes(mycrate))] (e.g. #[mycrate(some_option = "something")]) fails to compile on the current nightly with error: macro undefined: 'mycrate!'.

Definition of custom derive:

#![feature(proc_macro)]

use std::str::FromStr;

extern crate proc_macro;
use proc_macro::TokenStream;

#[proc_macro_derive(MyTrait, attributes(mycrate))]
pub fn my_macro(_: TokenStream) -> TokenStream {
    TokenStream::from_str("").unwrap()
}

Use which fails:

#![feature(proc_macro)]

#[macro_use]
extern crate proc_macro_collision;

#[derive(MyTrait)]
#[mycrate(some_option = "something")]
struct Foo;

fn main() {
}

If #![feature(proc_macro)] is removed, compilation succeeds.

Compiling the above fails with the following output:

error: macro undefined: 'mycrate!'
 --> examples/with.rs:7:1
  |
7 | #[mycrate(some_option = "something")]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Compilation fails on current nightly:

$ rustc --version --verbose
rustc 1.16.0-nightly (df8debf6d 2017-01-25)
binary: rustc
commit-hash: df8debf6d9afc431adbbd8311dcaf2b70eb9762e
commit-date: 2017-01-25
host: x86_64-apple-darwin
release: 1.16.0-nightly
LLVM version: 3.9

However, compilation succeeds on a week old nightly:

$ rustc --version --verbose
rustc 1.16.0-nightly (c07a6ae77 2017-01-17)
binary: rustc
commit-hash: c07a6ae77cd4ceb3cf591d34c5608ca91d1f75d4
commit-date: 2017-01-17
host: x86_64-apple-darwin
release: 1.16.0-nightly
LLVM version: 3.9

This is probably connected to #[proc_macro_attribute] which was merged in this timeframe (PR), and not the feature flag itself.

serde_derive-based example failing the same way:

#![feature(proc_macro)]

#[macro_use]
extern crate serde_derive;

extern crate serde_json;

#[derive(Serialize, Deserialize, Debug)]
#[serde(deny_unknown_fields)]
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let point = Point { x: 1, y: 2 };

    // Convert the Point to a JSON string.
    let serialized = serde_json::to_string(&point).unwrap();

    // Prints serialized = {"x":1,"y":2}
    println!("serialized = {}", serialized);

    // Convert the JSON string back to a Point.
    let deserialized: Point = serde_json::from_str(&serialized).unwrap();

    // Prints deserialized = Point { x: 1, y: 2 }
    println!("deserialized = {:?}", deserialized);
}

[alexcrichton]

cc @jseyfried

[abonander]

@jseyfried I think I have an idea where to start on this but I'll need some guidance.

[jseyfried]

This raises the following question:

// Given a `#[proc_macro_attribute]` `foo`
use attrs::foo;
// and a custom derive `#[proc_macro_derive(Trait, attributes(foo))]`,
use derives::Trait;

#[derive(Trait)] #[foo] struct A; // (1)
#[foo] #[derive(Trait)] struct B; // (2)

Should #[foo] resolve to the #[proc_macro_attribute] or the inert attribute from the proc_macro_derive? More specifically, #[foo]'s scope could be

• (a) only the #[proc_macro_attribute]
• (b) both, causing an ambiguity error
  • most future compatible
• (c) both, and the inert attribute shadows
• (d) both, and the #[proc_macro_attribute] shadows
  • probably not feasible to implement due to deadlocking

For (1), the scope could be (b) or (c) -- I weakly prefer (b).

For (2), the scope could be (a), (b), or (c) in descending order of my preference.
However, the inert attribute is currently in scope for (2) (this about to land in stable), so (a) is not backwards compatible. However, (b) is backwards compatible and it is straightforward to transition from (b) to (a) with an indefinitely long warning cycle.

cc @nrc @keeperofdakeys

[nrc]

Hmm, I would go for 'd' in both cases (the user has explicitly imported the name, whereas the inert attr is implicit from the user's POV). But it sounds like this can't be done.

In which case I prefer 'b' for (1) because this feels like the least silent failure. And 'a' for (2) since it looks out of scope for the derive. In both cases the user can address the issue by renaming the import (which is good).

[jseyfried]

We decided to

• implement (b) for (1) and (2) ASAP to fix this issue
• transition (2) from (b) to (a) with a warning cycle
• maybe allow unexpanded attribute proc macro names to shadow inert attribute names
  • this is a compromised version of (d) to mitigate deadlocking

[abonander]

@jseyfried I'm ready to get started working on this but I'm not sure where to start.