Attribute macros invoked at crate root have issues

[abonander]

When invoking some attribute procedural macro with inner form, i.e. #![foo_attr] at the crate root, a resolution error occurs:

#![feature(proc_macro)]
#![foo_attr]
//^ ERROR: cannot find attribute macro `foo_attr` in this scope

extern crate foo_macros;
use foo_attr_macro::foo_attr;

This should, ideally, resolve and execute properly.

[abonander]

cc @jseyfried

[jseyfried]

@abonander What about this?

#![feature(proc_macro)]

extern crate foo_macros;
use foo_macros::foo_attr;

mod bar {
    #![foo_attr]
}

If compiles, then the issue is that the attribute is at the crate root, not that it is an inner attribute.

[abonander]

@jseyfried Updated issue as this only affects the crate root

[abonander]

So @jseyfried and I figured out on IRC that this is due to the compiler trying to expand the attribute before the use_extern_macros code gets to see the actual import. I'd really like to make this work as I have some cool use-cases for it. We had a couple ideas for how to get this working but we figured we should expand the discussion on it before taking any action.

My best idea is along the lines of this: if an attribute macro fails to resolve at crate root only (since inner attributes on modules should resolve in the parent's scope), import-process root, get the resolution for the attribute, reinitialize the resolver and copy the resolution for the attribute macro, then expand the root module.

Some concerns from @jseyfried:

I believe that would be doable implementation-wise, but it could lead to coherence issues
For example, if the attribute macro expanded into nothing
Or if it expanded into a different import of itself
The resolution of a name isn't supposed to change as we expand things
It can only go from "indeterminate" to "success" or "indeterminate" to "failed"
If we preserve that with extra checks, what you're proposing could work though, I think

cc @nrc

[abonander]

@nrc Some input here when you get the chance, I'd like to tackle this soonish.

[nrc]

sorry it took a while to see this - I was away on parental leave and then had to nuke my notifications.

since inner attributes on modules should resolve in the parent's scope

I wonder if this axiom is correct? An alternative seems to be that we could resolve attributes at the scope in which they are written rather than the scope in which they apply. Would that have knock-on effects?

[jseyfried]

resolve attributes at the scope in which they are written rather than the scope in which they apply

Interesting, I like this idea. I'm not aware of any knock-on effects, it should be straightforward to implement, and it would address this use case.

[abonander]

I was under the impression that inner attributes were syntactic sugar for outer attributes, and it makes sense for outer attributes to resolve in the same scope as the item they're applied to. Crates are just special because there's no outer scope to resolve.

[nrc]

I was under the impression that inner attributes were syntactic sugar for outer attributes

Whether a feature is desugared or not is an implementation detail and we should do what makes the most sense from the user's POV, not the compilers. Desugaring can take place after name resolution if we like, so we don't need to change the implementation either.