#[proc_macro_attribute] doesn't work on trait methods

[alexcrichton]

Given this procedural macro:

#![feature(proc_macro)]

extern crate proc_macro;

use proc_macro::TokenStream;

#[proc_macro_attribute]
pub fn foo(attr: TokenStream, item: TokenStream) -> TokenStream {
    println!("attr: {}", attr);
    println!("item: {}", item);
    item
}

and this crate:

#![feature(proc_macro)]

extern crate foo;

use foo::foo;

trait Trait {
    #[foo]
    fn trait_function(&self);
    #[foo]
    fn trait_function_default(&self) {}
}

fn main() {}

Building:

$ cargo +nightly build
   Compiling foo v0.1.0 (file:///home/alex/code/foo)
    Finished dev [unoptimized + debuginfo] target(s) in 0.73 secs

I saw no output :(

I find that #[foo] is resolved, it just doesn't seem to get expanded!

[jseyfried]

cc @abonander

[abonander]

I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like #[inline] that doesn't make sense on them?

[jseyfried]

Not that I know of -- I'll do some debugging to figure out where the issue is (resolve, syntax, etc.).

[alexcrichton]

Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as Determinacy::Undetermined and then resolved as Determinacy::Determined which triggers this branch to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.

[alexcrichton]

In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve foo in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that hygienic_lexical_parent is returning None because while the trait does have a parent which presumably points to the crate's module they both have an expansion of Mark(0). The loop in hygienic_lexical_parent currently enforces parent_expansion != module_expansion which means that it can't go up one level.

Does that ring any bells @jseyfried or @abonander? Or maybe this is all a red herring?

[jseyfried]

@alexcrichton

that resolution is attempting to resolve foo in the "trait's namespace"

Haven't looked into this yet, but this explanation makes sense.

The loop in hygienic_lexical_parent currently enforces parent_expansion != module_expansion which means that it can't go up one level.

I believe the issue here is that hygienic_lexical_parent shouldn't be called with a trait module.
hygienic_lexical_parent enforces parent_expansion != module_expansion for mod modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude).

That is,

mod foo {
    fn f() {}
    mod bar {
        fn g() { f() } // `f` doesn't resolve here
    }
}

However, due to hygiene, the following resolves:

mod foo {
    fn f() {}
    m!(f); // Due to hygiene, this `f` reliably resolves to the above `f` ...
}

macro m($f:ident) {
    mod bar {
        fn g() { $f } // ... no matter where it ends up being used in the macro definition.
        // fn $f() {} // (unless the macro definition explicitly shadows it like this)
    }
}

If this issue is as I expect, I can fix quickly tomorrow.

[alexcrichton]

Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!