Support macro re-export

[kmcallister]

The mechanics should be easy because exported macros are just stored as strings in crate metadata. But it won't be very useful unless names mentioned by macros can change to follow the re-export. If we can find a pleasing solution to this problem, we can eliminate a lot of duplicated code e.g. between libcore/macros.rs and libstd/macros.rs.

[kmcallister]

Hm, we know the crate from which a macro was imported at expansion time. We could introduce a special metavar $crate which expands to the name of that crate. Then libstd can re-export libcore's macros as long as it re-exports a compatible module structure.

We could also arrange that ::$crate would expand to nothing at all within macros defined and used in the same crate. That would eliminate some additional hacks throughout the standard libraries.

cc @alexcrichton

[kmcallister]

I have this working on a branch. As short-term kludges go, this one has a lot to recommend it:

• The naming issue is handled with one new rule in MBE transcription. The syntax $crate was previously invalid, so this should not break existing code. There's no change to name resolution or other parts of the language.
• It solves both the re-export naming issue and the "exported macro is used locally" problems with a single mechanism.

This doesn't affect procedural macros at all. I'll update #17100 once this lands.

[sfackler]

I haven't looked that deeply at the branch, but how does this interact if the crate is imported outside of the crate root or with a nonstandard name?

[kmcallister]

It does handle renaming.

I hadn't thought about extern crate outside the crate root. In fact I didn't know you could do that :) Is there an existing use case?

[sfackler]

I've only seen it used in test modules, but it's definitely something you can do. Supporting non-root crate names will be a bit awkward since you need relative paths in some context and absolute paths in others. Maybe insert a gensymed import of the crate at the crate root?

[huonw]

Non-crate root macros are currently broken anyway.

[sfackler]

What do you mean?

[sfackler]

We could always have $crate expand to an absolute path and just force relative usages of it to prefix it with ::, e.g. let foo = ::$crate::MyType.

[huonw]

#![feature(phase)]


mod foo {
    #[phase(plugin, link)] extern crate log;

    fn bar() {
        debug!("hi")
    }
}

fn main() {}

<log macros>:3:21: 3:24 error: failed to resolve. Maybe a missing `extern crate log`?
<log macros>:3         static LOC: ::log::LogLocation = ::log::LogLocation {
                                   ^~~
<log macros>:1:1: 13:2 note: in expansion of log!
<log macros>:2:46: 2:76 note: expansion site
<log macros>:1:1: 3:2 note: in expansion of debug!
<anon>:8:9: 9:6 note: expansion site
<log macros>:3:21: 3:39 error: use of undeclared type name `log::LogLocation`
<log macros>:3         static LOC: ::log::LogLocation = ::log::LogLocation {
                                   ^~~~~~~~~~~~~~~~~~
[...]

http://is.gd/IV7ooc

[kmcallister]

Right now, $crate expands to ::foo when imported from foo, and nothing when defined locally. (That's a bit different from what I wrote above.) This means $crate::bar::baz will be an absolute path either way, which seems good.

[sfackler]

That will break if you try to do something like use $crate::MyStruct though.

[kmcallister]

Is there any reason use shouldn't accept paths starting with ::?

[sfackler]

Dunno, but it's currently a parser error.