Allow renaming imported macros

[kmcallister]

e.g.

#[macro_use(fail="panic")]
extern crate std;

Now which way around does it go...

[kmcallister]

I'd say fail="panic" to import the current panic! as fail!. This matches extern crate "foo" as bar. The quoted string is the external reference and the un-quoted one is the identifier you use in your program.

[steveklabnik]

Traige: no change

[Nemo157]

I have an actual use-case for this now :)

I'm trying to write some benchmarks comparing maud, horrorshow and a new alternative I'm working on, every one of these defines an html! macro as the basis of their system, so currently it's impossible to easily bring them all into a single benchmark .

As an aside, there is no warning or error that the macros are conflicting, it seems it just uses the last one to be imported, I should probably find/open a ticket about that. (EDIT: #32911)

I did think I would be able to work around it by pulling the crates into internal modules and just exposing functions for the benchmarks to call into, but that fails as for some reason you can only import macros in at the crate root (seems like an arbitrary restriction, if you can define private macros in a sub-module why can't you import private macros that are only needed in a sub-module to prevent polluting your global macro namespace).

The only workaround I've found is to group my benchmarks by implementing crate instead of grouping them by what they are doing, this makes changing the benchmarks more error-prone as I have to make almost identical changes to 3 different files without being able to easily see them all at once to check they're still doing the same thing.

[LeoTestard]

I can implement that if there is consensus on it. Shouldn't be too hard.

[LeoTestard]

Question: what to do when using both #[macro_use] and #[macro_reexport] on the same extern crate declaration?

Let's say you have a renaming item foo="bar". Should this apply to, say, #[macro_reexport(bar)]? Would the macro be exported as foo instead? Or should we instead refer to the macro by its local name when reexporting it, as in #[macro_reexport(foo)]? Also, it could be great to be able to provide a different renaming for exporting than for importing, so to be able to say #[macro_reexport(foo="bar")], wether the reexported macros are selected with their original or with their local name.

[caipre]

for some reason you can only import macros in at the crate root (seems like an arbitrary restriction, if you can define private macros in a sub-module why can't you import private macros that are only needed in a sub-module to prevent polluting your global macro namespace).

I'm also annoyed by this. Is this an intentional restriction?

[LeoTestard]

I'm also annoyed by this. Is this an intentional restriction?

I don't think so. Not super easy to change though, given the current implementation.

[kdar]

Would also be nice to be able to only import certain macros.

[Mark-Simulacrum]

I believe this should be fixed by the use_extern_macros feature, once that stabilizes.

[Mark-Simulacrum]

I'm going to close this in favor of the tracking issue for use_extern_macros (#35896), since I don't think tracking it separately is helpful.