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.

[kmcallister]

It seems harmless, the path will just be absolute either way. That can be a followup PR, since the std lib macros don't need use $crate.

[sfackler]

Wouldn't $crate have to expand to ::foo for imported use or :: for local use to work consistently?

[kmcallister]

$crate::bar expands to either ::foo::bar or ::bar, and the latter works as a reference to something in the current crate.

[sfackler]

Oh, right.
On Sep 16, 2014 12:11 AM, "Keegan McAllister" [email protected]
wrote:

$crate::bar expands to either ::foo::bar or ::bar, and the latter works
as a reference to something in the current crate.

—
Reply to this email directly or view it on GitHub
#17103 (comment).

[alexcrichton]

@kmcallister there were some extensive discussion about the macro system at the last work week, but it appears that we didn't take very good notes during that sadly. You may want to sync up with @pcwalton or @nikomatsakis before going too far down this road as I remember we came up with fairly concrete plans, but they involved possibly significant changes to resolve.

[nikomatsakis]

Based on the discussion at the work week, I've been working on expanding my name resolution prototype to include macro import/export and expansion. So far I've not quite gotten there -- most of the work has been on expanding it to support lazy glob resolution and two namespaces.

[kmcallister]

@nikomatsakis, @alexcrichton: Do you think I should revive this PR as a near-term fix (along with a re-tooled #17100) or is the new name resolution work close to ready?

[alexcrichton]

We've been hesitant in the past to make any major adjustments to the macro system (which I think this falls into the category of). We still feel that macros are not quite where they need to be, and I'm not sure what something like $crate is where we'd want to end up long-term.

I would prefer to discuss this a bit more before moving forward. I know this is a huge pain point with macros! Such a feature would likely require an RFC to move forward (this is a large modification to macros, a language feature). We can discuss in the upcoming weekly meeting however to test the waters of whether we'd like to move forward with this now.

[kmcallister]

Okay. I'll prepare an RFC ahead of the meeting tomorrow.