Work out the actual policy for macros across editions wrt dependencies updating

[Manishearth]

I don’t think we’ve adequately worked out what we want for macros with editions.

Are we okay with a Rust 2015 crate that exposes a macro updating to Rust 2018 (including new idioms) with a minor bump? I.e. should our edition hygiene account for this? Or are macro authors instructed to do major bumps when they

Taking a hypothetical: if dyn were something we only exposed on Rust 2018, and a macro crate upgraded to the new edition, should we do the heavy lifting of ensuring that crates on Rust 2015 can use macros from crates on Rust 2018 that use 2018-only features? Or do we require the crate author to do a major version bump?

Similarly, what level of trouble are we okay with for crates attempting to upgrade to the 2018 edition that use macros from 2015 crates?

cc @rust-lang/lang

[nikomatsakis]

Moved to the lang team project management dashboard to track status.

[nikomatsakis]

I think the scenario in question is:

• Crate A is in Rust 2018 Edition
  • It exports a macro M using a Rust 2018-only feature (e.g., catch)
• Crate B is in Rust 2015 Edition
  • It uses the macro M

Right? If so, I definitely think we should make this work if we can (and hence it would not require a semver major bump).

[Manishearth]

Sounds good. Seems tricky to implement.

[nikomatsakis]

I feel like if we were to serialize macros as token trees, and we reflect whether a given identifier is a token or not as part of that info, it would "just work". I must be missing something though.

[upsuper]

If a procedural macro drops span information, this may still be a problem. But it's probably not a big concern given the current common practice of writing procedural macro?

Parsing in a procedural macro can also fail due to syntax difference, but its probably not worse than introducing new syntax in current manner. The tricky thing is that it may become less clear whether a change in the parsing part is breaking or non-breaking change. (Do we consider requiring a newer version of compiler a breaking change?) Some authors of procedural macro may eventually find supporting syntax of old edition an extra burden and drop such support, which may lead to questioning Rust's interoperability promise.