stabilise assert_matches

[Dylan-DPC]

Closes #82775

Currently there is some discussion around #82913. So I assume this would either be blocked on that if needed.

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[bors]

☔ The latest upstream changes (presumably #119968) made this pull request unmergeable. Please resolve the merge conflicts.

[cuviper]

Currently there is some discussion around #82913. So I assume this would either be blocked on that if needed

Then I'll leave that to API folks.

r? libs-api

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting. The consensus we came up with was:

We want to stabilize this. We're not thrilled with the module name assert_matches (std::assert_matches::assert_matches!), and would prefer a more general name there. However, we don't want to delay stabilization while trying to bikeshed that name. So, we're proposing that we leave the assert_matches module unstable for now (and let that bikeshed painting happen asynchronously), but go ahead and re-export the assert_matches macro from std::prelude::rust_2024, so that people can use it either by moving to Rust 2024 or by importing std::prelude::rust_2024::assert_matches.

Meanwhile, if someone comes up with a great idea for a module assert_matches should live in, we can move it there and stabilize that module.

[Voultapher]

@joshtriplett to clarify, did the libs team talk about the concern I raised? Your comment does not mention it at all. That's why I'm asking.

[Amanieu]

@Voultapher We did discuss your concern about the if syntax. Our conclusion is that it is more important for the syntax of assert_matches to be consistent with the one for matches.

If changes to the syntax are needed, this should be applied to both matches and assert_matches, although the bar for changing an already-stable API (matches) is very high. Regardless, this should be discussed separately from the stabilization of assert_matches.

[cuviper]

Meanwhile, if someone comes up with a great idea for a module assert_matches should live in, we can move it there and stabilize that module.

Was a simple core::assert module considered? All of the assertion macros could live there, while still being re-exported from the root for compatibility. I know core::assert::assert_matches! is a bit of a stutter, but that's no different than alloc::vec::Vec, core::sync::atomic::Atomic*, etc.

[Amanieu]

core::assert causes issues because importing will cause conflicts with the assert macro in the crate root.

[cuviper]

Ah -- then maybe core::assertions, though that's a bit more of a mouthful. A broader core::macros wouldn't be horrible either IMO, but I could understand hesitation about that.

[Voultapher]

@Amanieu thanks for clarifying and considering the point. While it's a bit unfortunate I don't see a better alternative either, that doesn't involve a time machine.

[joshtriplett]

Ah -- then maybe core::assertions, though that's a bit more of a mouthful. A broader core::macros wouldn't be horrible either IMO, but I could understand hesitation about that.

We did consider core::macros as well. We're going to consider the module name further, but we wanted to let this proceed without waiting on the bikeshedding. :)

[eirnym]

@joshtriplett Have you considered the same placement as the rest assertions? I believe this one would useful be the same as other assertions

[joshtriplett]

@eirnym The rest of the assertions are in the root of core, which we can't do with assert_matches due to conflicts.

[joshtriplett]

What's the current status of this? Is it possible to stabilize the addition of assert_matches to the prelude without stabilizing the non-prelude location of it?

[Dylan-DPC]

I haven't looked at it since the last review, i'll give it this week or next (hopefully) and update here accordingly