Crates can't migrate to 2018 edition when they invoke coupled procedural macros

[alexcrichton]

Procedural macros are often coupled with "runtime crates" which support the various macros that the procedural macro exports. These runtime crates, however, sometimes also want to invoke the procedural macro itself (think panic! and libstd, which exports it for users and also defines it itself).

Let's say our runtime crate is called foo. The macro today generally expands to paths that look like ::foo::MyType. This doesn't work by default in the crate foo itself, so foo typically includes a module that looks like:

mod foo { pub use super::*; }

And the enables the crate foo to use its own macros internally.

In the 2018 edition, however, the ::foo::MyType path unconditionally requires foo to be a crate, which isn't the case when we're compiling foo! As a result, these sorts of runtime crates don't have a great path forward when migrating to the 2018 edition.

[alexcrichton]

This was first reported at dtolnay/syn#507

[eddyb]

cc @rust-lang/lang @petrochenkov

[joshtriplett]

Shouldn't such macros use $self::MyType or similar instead? (Does that not work for procedural macros, for some reason?)

[dtolnay]

@joshtriplett the procedural macro and the runtime support live in separate crates, think serde_derive vs serde. You would need some way to specify what crate $self would refer to, because in code generated by serde_derive all the types are defined by serde not serde_derive.

[petrochenkov]

Hack: provide a version of macro with an extra argument for internal use and replace ::foo with crate if it's used.

[petrochenkov]

Hack 2: --extern foo=self that adds foo into extern prelude as an alias to crate.

[petrochenkov]

Or, in general, some way to add a name that's associated with the current crate into extern prelude.

[joshtriplett]

@dtolnay Ah, I misunderstood the phrase "the crate foo to use its own macros internally".

[petrochenkov]

Perhaps even #![crate_name = "foo"] and --crate-name NAME can be re-purposed for that.
In general, if the crate knows its name (which is not always true), we can add that name into extern prelude.

EDIT: Nah, perhaps this need is too special, my_crate_name being generally available as an alias to crate in all crates built by Cargo would probably mostly cause confusion.

[petrochenkov]

extern crate foo = PATH; 😄

[eddyb]

@petrochenkov wouldn't that create a bit of a "side-effect" in the system?
Or would you be required to place it in the root of another crate?

[petrochenkov]

@eddyb
Do you mean extern crate foo?
If by side effect you mean that the extern prelude set becomes dynamic and can change in the process of expansion, then yes.
It's not so bad, it's the same thing as #[macro_use] extern crate ... adding names into the macro prelude, so it's trivially implementable in the existing infrastructure.
It breaks the uniform import path scheme with canaries though, so it's one more reason to move the implementation to the proper search in scope sooner (EDIT: or perhaps not and we'll just need more canaries?).