Tracking issue for `macro_reexport` feature

[aturon]

Tracking for stabilization of #[macro_reexport].

[durka]

Any opinions on whether this should be stabilized?

I would love to see it stabilized. Currently, a crate A which exports a macro whose expansion references a macro from crate B cannot express that dependency: it is pushed onto the user of crate A, even though otherwise they wouldn't have to know about the implementation detail. If crate A could reexport the macro from crate B, it would be a better situation.

[aturon]

cc @rust-lang/lang, particularly @nrc.

In the long run this will be able to go through the normal pub use system (as eventually macros will work with the normal name resolution system). But given that that's a ways off, and we already have stabilized the basics of macro_rules, we could consider doing something here as well.

Nominating for discussion in next lang meeting.

[nikomatsakis]

Hear ye, hear ye. This issue is hereby promoted to final comment period. The discussion is whether to stabilize this feature beginning in the next release cycle.

[nrc]

I think we should stabilise. As @aturon says, eventually it should be replaced, but having it in the short/medium term is a big win.

[alexcrichton]

Some serious bugs and downsides of macro_reexport that I know of are:

• The source of macro is mangled during the reexportation process. This means that error messages of the macro when used from the reexported location get worse. For example compare std's try! to core's
• The macro is just copy/pasted into the reexported crate. This means that references like $crate break because they don't refer to the original crate, but now the reexported crate. This means it's basically useless to reexport a macro unless the two crates have the same exact internal structure.

I personally see this as a half-baked feature that was just nice to reduce duplication in std/core, it doesn't seem like it fits the normal high standard we might have for language features. There's certainly an argument that macro_rules! is "bad enough" that this doesn't make it worse, but I would prefer to not continue to make it worse.

I'd be fine deprecating and removing this while just copying the macros between core/std to have the same source.

[durka]

The first bug seems possible to fix -- if the mangled source of a macro is stored in crate metadata, the unmangled source can be too. I agree the second one is a downside, but it can be mitigated by pub useing items that are referenced from a macro when you reexport it. And not all macros reference items in the crate anyway! With no stable way to reexport macros, macro crates cannot participate in the dependency system. So I think this makes macro_rules! better (though not a whole lot better), not worse.

[nrc]

We should fix both the bugs that @alexcrichton points out before stabilising (I was not aware of them). Are there issues filed for those?

[alexcrichton]

Unfortunately not that I know of :(

Sorry I meant to write these thoughts down when the initial tracking issue was made, but I guess I forgot...

[durka]

The mangled-source issue is #20923.

[nikomatsakis]

Making $crate "work" when re-exporting a macro seems to have no easy
fix. Or perhaps it depends on what you mean by "fix" and "work". That
is, you could expand to a path that is relative to the extern crate in
the intermediate crate, but that would require the intermediate crate
to make that extern crate a public export, which may not be what you
want.

Also, if $crate DOES expand to the original source crate, that means
that you MUST pub use the crate link, versus reproducing the
members, right?