Enforce the shadowing restrictions from RFC 1560 for today's macros

[jseyfried]

This PR enforces a weakened version of the shadowing restrictions from RFC 1560. More specifically,

• If a macro expansion contains a macro_rules! macro definition that is used outside of the expansion, the defined macro may not shadow an existing macro.
• If a macro expansion contains a #[macro_use] extern crate macro import that is used outside of the expansion, the imported macro may not shadow an existing macro.

This is a [breaking-change]. For example,

macro_rules! m {() => {}}macro_rules! n {() => {
macro_rules! m {() => {}}//< This shadows an existing macro.
m!();//< This is inside the expansion that generated `m`'s definition, so it is OK.}}n!();m!();//< This use of `m` is outside the expansion, so it causes the shadowing to be an error.

r? @nrc

[jseyfried]

cc #35896, cc @eddyb (this is helpful for def/use orthogonality)
Also, this will need a crater run.

[nrc]

@brson, @nikomatsakis, @eddyb could one of you schedule a crater run please?

[eddyb]

@nrc Starting now.

[eddyb]

Crater run shows two regressions (conv and tokei).

[nrc]

Code looks good, but I'm not sure about the Crater regressions. They certainly seem real and could indicate more uses in the wild. It is probably prudent to have a warning cycle for this if it is possible.

[durka]

• A macro defined by a macro-expanded macro_rules! may not shadow an existing macro.

Can it shadow a macro which was previously defined by a macro?

I use the above trick in static-cond. If it's not permitted, you can only invoke static_cond! once per crate, and there's no way to create unique identifiers, so... this sucks.

[jseyfried]

@durka Yeah, looks like this PR and unhygienic macro names are a bad combination.

I wonder if it would be backwards compatible in practice to make macro names hygienic (EDIT: it isn't). That would avoid breaking static-cond as well as the two Crater-detected crates.

If we can't make macro names hygienic, we could instead only disallow macro-expanded shadowing if the shadowing macro is used outside of the expansion. This would also avoid breaking static-cond and the two Crater-detected crates, and it wouldn't compromise name resolution in any way.

[jseyfried]

I weakened the shadowing restrictions to avoid breakage in practice (see the edited initial comment).
This PR no longer breaks static-cond or the two crates from the Crater run.

[nrc]

Code looks good, I'd like to get another Crater run before we land though. @eddyb, @brson, @nikomatsakis could someone oblige please?

[eddyb]

On it!

[eddyb]

Crater report looks good (the unrelated breakage is rust-num/num#231, I reused the "before" results).

[nrc]

Thanks @eddyb !

@bors: r+

[bors]

📌 Commit 057302b has been approved by nrc

[bors]

⌛ Testing commit 057302b with merge f374565...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-rustbuild
Approved by: nrc
Pushing f374565 to master...