Stabilize assert_matches

[Voultapher]

View all comments

Closes#82775

This is a revive of #120234, with the suggested move from the public assert_matches module to macros. This necessitates the rename of the internal macros modules to core_macros and std_macros respectively.

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

HIR ty lowering was modified

cc @fmease

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

The run-make-support library was changed

cc @jieyouxu

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[Voultapher]

To all the people that got cc'd feel free to check the changes, but they should only amount to import renames.

[Voultapher]

Changing the filename of the private macros modules has wide reaching effects inside the rustc source code. Mostly the fix is to rename mentions to the path outside of rust code as in the error tests, but there are some places like src/tools/cargo/tests/testsuite/fix.rs that reference the path and I don't know why they do that.

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

[scottmcm]

Hmm, I found the FCP to stabilize in #82775 (comment)

But I couldn't find any decision on the module. So nominating for libs-api to weigh in on that part.

[Voultapher]

The module name was suggested here #120234 (comment) and here #120234 (comment)

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.

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.

Given how popular this feature is and the previously expressed desires of the libs-api team to avoid blocking on bikesheding, I'd appreciate it if we could avoid another round of bikesheding here. std::macros and core::macros are about as intuitive a place for a macro to be in. In the future we can pull assert_matches into the prelude for Rust edition 2027.

[Voultapher]

Plus this PR has to touch a lot of files by necessity, so it be great if we could move forward in a reasonable amount of time to limit the amount of merge conflict resolution I'll have to do.

[scottmcm]

Process-wise, a meeting consensus is generally not enough to make a one-way decision like picking a stable path, and it seems clear that this wasn't part of the previous FCP, so I'm not comfortable merging it without explicit libs-api assent.

If they disagree with my assessment that's fine, but it's their decision to make.

[Voultapher]

so I'm not comfortable merging it without explicit libs-api assent.

Neither am I. Let's please ask for their approval. What I'd like to avoid is a situation where we block this because the team is happy enough with the name but maybe there could be a better one and so the discussion starts.

[Amanieu]

@bors delegate+

[rust-bors]

✌️ @Voultapher, you can now approve this pull request!

If @Amanieu told you to "r=me" after making some further change, then please make that change and post @bors r=Amanieu.

[Amanieu]

r=me once CI passes

[Voultapher]

Looking at it the CI failed because GitHub was down.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Voultapher]

@bors r=Amanieu

[rust-bors]

📌 Commit 2f3b952 has been approved by Amanieu

It is now in the queue for this repository.

[michalfita]

I installed 1.95 and assert_matches is still unstable. Why? 🤔

[ojeda]

Because it was reverted: #154999.

[michalfita]

Thanks for super-quick reply, @ojeda. The issue destabilising this is #154406.

I don't the process here, but now the error leads here, to the tracking PR that is merged and marked for 1.95 milestone - kinda misleading. Certainly, now my comment indicates what went wrong. Shouldn't be a mechanism to reopen the tracking PR is such case with comment referencing the bug causing reversal?

[Skgland]

It also looks like it is stable on beta & nightly but the version is still set to 1.95.0