Is there a gentler way to land the assert_matches macro?

[anp]

As a user I'm really excited for std::assert_matches!, but I'm a little worried about the level of breakage it introduces and I'm hoping to discuss possible paths forward.

The Fuchsia roll to update rustc is currently blocked by ambiguous macro resolution errors with code that glob-imports matches::assert_matches!. It seems that a locally defined glob import does not take precedence over macros defined in std.

This implies a workaround of changing all the glob imports to use matches::assert_matches, but this does not account for submodules which use super::*;. Unfortunately it seems that the test_case crate wraps the function body in a submodule and adds a use super::*to the new module.

What this means in practice is that every function using the test_case crate must have an explicit import added or have the macro referenced via a fully qualified name. AIUI this change counts as an acceptable breakage and so I'm still putting together a diff which will resolve all of our roll blockers.

What I'm wondering though is whether knowing about this source of breakage offers a path to a smoother release. If so, we could revert the change and prepare to roll it out more gently.

Two options that came up in private discussions:

1. remove assert_matches from the prelude until the 2021 edition

• this wouldn't make it immediately available but it would prevent the breakage

2. make local glob imports take precedence over std/prelude macros

• this would make it immediately available but may not be possible within language constraints

Any other suggestions for how to make this change less disruptive? cc @m-ou-se @tmandry @joshtriplett

[estebank]

cc @petrochenkov for resolution

[anp]

I've prepared a change which should allow us to update to the current nightly and might give a sense of the frequency within our codebase (more than I'd expect but less than I'd feared). I'm not sure to what extent that holds for the rest of the ecosystem, maybe a crater run would be useful to determine the severity here.

[tmandry]

This was a big enough breakage for Fuchsia (and the error messages are confusing enough) that I think a crater run is warranted.

I'm not sure if the release team wants to weigh in at this point or not, but nominating for discussion in the release team meeting.

@rustbot label: +T-release +I-nominated

[joshtriplett]

We discussed this in today's @rust-lang/libs meeting.

We'd propose the following:

• Remove assert_matches! from the prelude, and only add it in a submodule. (Hopefully we don't have to extensively bikeshed the path to this.) People who want to use it can import it, for now.
• Consider adding assert_matches! to the prelude in the next edition.

[Mark-Simulacrum]

(I think the libs team decision makes this a bit moot, but perhaps not)

I think for unexpected, extensive breakage it usually makes sense to revert and perhaps reland with no changes, just giving folks a chance to evaluate the breakage - potentially via crater. I think the compiler team has been moving towards reverting eagerly, too, though there's not been set policy yet, and I think there's not quite consensus.

I'll leave this nominated in case others on the release team have thoughts and bring it up in our meeting too.

[Mark-Simulacrum]

It looks like the removal here hasn't happened, and has now hit beta. Tagging as a beta regression.