Stabilize `assert_matches` #137487

Voultapher · 2025-02-23T15:31:33Z

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 · 2025-02-23T15:31:42Z

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 · 2025-02-23T15:31:45Z

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 · 2025-02-23T15:34:25Z

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

Voultapher · 2025-02-24T13:19:16Z

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 · 2025-02-24T13:21:46Z

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 · 2025-03-20T05:15:52Z

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 · 2025-03-20T09:04:28Z

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 · 2025-03-20T09:05:44Z

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 · 2025-03-20T09:11:16Z

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 · 2025-03-20T09:27:30Z

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.

Zalathar · 2026-01-19T06:43:59Z

Here's my proposed PR to reduce the impact on the compiler, by having the compiler temporarily use assert_matches! via its own re-export in rustc_data_structures instead.

compiler: Temporarily re-export assert_matches! to reduce stabilization churn #151359

RalfJung · 2026-01-19T07:58:05Z

Note that if this has such a big impact in the compiler, it likely also has a big impact in the wider ecosystem.

RalfJung · 2026-01-19T07:59:29Z

Also I think we generally prefer having stabilization PRs only do stabilization (for easier reverting, among other reasons). So any moving around of the definition should ideally be done first in a separate PR.

Voultapher · 2026-01-19T08:05:07Z

Note that if this has such a big impact in the compiler, it likely also has a big impact in the wider ecosystem.

It's an unstable opt-in feature, with a very easy migration path. If we are not willing to break those, we'll be stuck.

Voultapher · 2026-01-19T08:07:23Z

Also I think we generally prefer having stabilization PRs only do stabilization (for easier reverting, among other reasons). So any moving around of the definition should ideally be done first in a separate PR.

With the help of @Zalathar's PR we can make this one even smaller, but some internal rename logic is still necessary because of the bootstrap process and I don't see how to do it all in PRs beforehand without waiting a full version cycle for it, which seems like a steep price that would need some justification.

RalfJung · 2026-01-19T08:08:39Z

It's an unstable opt-in feature, with a very easy migration path. If we are not willing to break those, we'll be stuck.

Yeah we can break them, but we should still be aware of the churn this causes to existing nightly code.

With the help of @Zalathar's PR we can make this one even smaller, but some internal rename logic is still necessary because of the bootstrap process and I don't see how to do it all in PRs beforehand without waiting a full version cycle for it, which seems like a steep price that would need some justification.

I don't see why stabilization and rename need any sort of coupling.

Voultapher · 2026-01-19T09:00:57Z

I don't see why stabilization and rename need any sort of coupling.

Because features can't be exported both stably and unstably. If we want to stabilize something under the assert_matches feature name we can't simultaneously unstably export something under the same feature name to polyfill the rename. The meaning of what feature(assert_matches) means, changes between bootstrap and not due to the stabilization, so they are linked. There are ~60 places in the repo that interact with feature(assert_matches), they will need some form of accommodation.

It's possible to migrate all these places to the new path, wait a release cycle and then do the stabilization. I'd argue that is an expensive option to artificially delay a long sought after feature to make a 170 line PR easier to review and revert.

RalfJung · 2026-01-19T09:04:32Z

All I am saying is, have a PR that moves it to core::macros, while keeping it under the same feature gate. I wasn't talking about having the same feature gate be both stable or unstable, not sure where you got that from.

Voultapher · 2026-01-19T09:31:53Z

PR A)

Move std::assert_matches::assert_matches -> std::assert_matches
Change each bootstrap built use std::assert_matches::assert_matches; to:

#[cfg(bootstrap)]
use std::assert_matches::assert_matches;
#[cfg(not(bootstrap))]
use std::assert_matches;

PR B)

Mark assert_matches as stable.
Each #![feature(assert_matches)] is now a warning in cfg(not(bootstrap)).

Personally I don't see how one would get around around addressing B.2 before the stabilization PR.

RalfJung · 2026-01-19T09:35:35Z

Yes, that's what I would expect.

Personally I don't see how one would get around around addressing B.2 before the stabilization PR.

Indeed, the stabilization PR for features that are used by rustc itself often need cfg_attr(bootstrap, feature(...)). That's expected.

What we usually try to avoid is doing anything beyond toggling the feature gate (and the immediate fallout) in the stabilization PR.

Voultapher · 2026-01-19T09:39:17Z

Indeed, the stabilization PR for features that are used by rustc itself often need cfg_attr(bootstrap, feature(...)). That's expected.

Please look at the diff of the current PR state, that's more or less all it does.

I fully get that 60 occurrences is a lot and with #151359 we can get it smaller.

RalfJung · 2026-01-19T09:42:02Z

Your PR title says that this PR does two unrelated things:

move the macro to a different location
change the stability attributes of the macro

All I am saying is that those things should not happen in the same PR.
Is the PR title not an accurate reflection of what the PR does?

Voultapher · 2026-01-19T09:43:56Z

Is the PR title not an accurate reflection of what the PR does?

Honestly that title is a year old, forgot to update it.

RalfJung · 2026-01-19T09:44:00Z

It seems to be accurate, the code also does those two unrelated things.

Please look at the diff of the current PR state, that's more or less all it does.

That's not true. As I already said around 3 times, and as the PR title says, it also moves the macro to a different location. I am not sure where communication is breaking down here, I am not trying to say anything complicated.

RalfJung · 2026-01-19T09:44:34Z

library/core/src/lib.rs

-#[unstable(feature = "assert_matches", issue = "82775")]
-/// Unstable module containing the unstable `assert_matches` macro.
-pub mod assert_matches {
-    #[unstable(feature = "assert_matches", issue = "82775")]
-    pub use crate::macros::{assert_matches, debug_assert_matches};
-}
+// These macros are explicitly exported here and not in the preludes - for now - to require manual
+// import by users to avoid compatibility issues such as with the third-party assert_matches macro.
+// See https://github.com/rust-lang/rust/pull/137487 and
+// https://github.com/rust-lang/rust/issues/82913
+#[stable(feature = "assert_matches", since = "CURRENT_RUSTC_VERSION")]
+pub use crate::macros::{assert_matches, debug_assert_matches};


This does 2 things at once, when typically we prefer to do them separately: the stabilization PR should only change the stability of a feature, not change how it works.

Put differently, all code that worked before a stabilization PR should keep working, with the only difference being that there are new warnings about using feature on an already-stable feature.

I said this from the start:

So any moving around of the definition should ideally be done first in a separate PR.

Your replies were always about something unrelated. I can't figure out why.

Understood, will do.

Your replies were always about something unrelated. I can't figure out why.

There are two different renames/moves, the client-side rename of use and the export path. I believe you were talking about the latter or both and I was mostly talking and thinking about the former. In my mind I understood the issue as too much changes at once and the former was the major source of change.

RalfJung · 2026-01-19T09:45:16Z

Honestly that title is a year old, forgot to update it.

Please don't, the title was correct.

Voultapher · 2026-01-19T09:47:03Z

Please don't, the title was correct.

It seems we are talking past each other. The goal of this PR is the stabilization. I've now learned that doing that move separately is not a "it would be nice" as it has been described to me previously, but rather a you must do it that way. I don't object.

Voultapher · 2026-01-19T09:47:08Z

@rustbot author

rustbot · 2026-01-19T09:47:12Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

RalfJung · 2026-01-19T09:49:32Z

It seems we are talking past each other. The goal of this PR is the stabilization. I've now learned that doing that move separately is not a "it would be nice" as it has been described to me previously, but rather a you must do it that way.

Okay, at least we're talking about the same thing now. :)

I said it is "generally preferred" to do the move separately. It's not a hard rule but in the past there have been issues and mistakes that would have been prevented by separating the stabilization. The PR description didn't give a justification for why they should be merged into one PR, so I brought up this point.

compiler: Temporarily re-export `assert_matches!` to reduce stabilization churn rust-lang#137487 proposes to stabilize `feature(assert_matches)`, while simultaneously moving the `assert_matches!` and `debug_assert_matches!` macros out of the `std::assert_matches` submodule and exporting them directly from the `std` crate root instead. Unfortunately, that moving step would cause a lot of `cfg(bootstrap)` churn and noise in the compiler, because the compiler imports and uses those macros in dozens of places. This PR therefore aims to reduce the overall compiler churn, by temporarily adjusting the compiler to always use `assert_matches!` via a re-export from `rustc_data_structures`. That way, the stabilization itself would only need to add `cfg(bootstrap)` to that single re-export (plus the associated `#![feature(assert_matches)]` attributes), greatly reducing the immediate impact on the compiler. Once `assert_matches!` is stable in the stage0 bootstrap compiler, we can go back and delete the re-export, and adjust the rest of the compiler to import directly from `std` instead.

Rollup merge of #151359 - assert-matches, r=BoxyUwU,Noratrieb compiler: Temporarily re-export `assert_matches!` to reduce stabilization churn #137487 proposes to stabilize `feature(assert_matches)`, while simultaneously moving the `assert_matches!` and `debug_assert_matches!` macros out of the `std::assert_matches` submodule and exporting them directly from the `std` crate root instead. Unfortunately, that moving step would cause a lot of `cfg(bootstrap)` churn and noise in the compiler, because the compiler imports and uses those macros in dozens of places. This PR therefore aims to reduce the overall compiler churn, by temporarily adjusting the compiler to always use `assert_matches!` via a re-export from `rustc_data_structures`. That way, the stabilization itself would only need to add `cfg(bootstrap)` to that single re-export (plus the associated `#![feature(assert_matches)]` attributes), greatly reducing the immediate impact on the compiler. Once `assert_matches!` is stable in the stage0 bootstrap compiler, we can go back and delete the re-export, and adjust the rest of the compiler to import directly from `std` instead.

rust-bors · 2026-01-20T02:34:54Z

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

@petrochenkov

…ros, r=petrochenkov Explicitly export core and std macros Currently all core and std macros are automatically added to the prelude via #[macro_use]. However a situation arose where we want to add a new macro `assert_matches` but don't want to pull it into the standard prelude for compatibility reasons. By explicitly exporting the macros found in the core and std crates we get to decide on a per macro basis and can later add them via the rust_20xx preludes. Closes rust-lang/rust#53977 Unlocks rust-lang/rust#137487 Reference PR: - rust-lang/reference#2077 # Stabilization report lib Everything N/A or already covered by lang report except, breaking changes: The unstable and never intended for public use `format_args_nl` macro is no longer publicly accessible as requested by @petrochenkov. Affects <10 crates including dependencies. # Stabilization report lang ## Summary Explicitly export core and std macros. This change if merged would change the code injected into user crates to no longer include #[macro_use] on extern crate core and extern crate std. This change is motivated by a near term goal and a longer term goal. The near term goal is to allow a macro to be defined at the std or core crate root but not have it be part of the implicit prelude. Such macros can then be separately promoted to the prelude in a new edition. Specifically this is blocking the stabilization of assert_matches rust-lang/rust#137487. The longer term goal is to gradually deprecate #[macro_use]. By no longer requiring it for standard library usage, this serves as a step towards that goal. For more information see rust-lang/rust#53977. PR link: rust-lang/rust#139493 Tracking: - rust-lang/rust#147319 Reference PRs: - rust-lang/rust#139493 cc @rust-lang/lang @rust-lang/lang-advisors ### What is stabilized Stabilization: * `#[macro_use]` is no longer automatically included in the crate root module. This allows the explicit import of macros in the `core` and `std` prelude e.g. `pub use crate::dbg;`. * `ambiguous_panic_imports` lint. Code that previously passed without warnings, but included the following or equivalent - only pertaining to core vs std panic - will now receive a warning: ```rust #![no_std] extern crate std; use std::prelude::v1::*; fn xx() { panic!(); // resolves to core::panic //~^ WARNING `panic` is ambiguous //~| WARNING this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! } ``` This lint is tied to a new exception to the name resolution logic in [compiler/rustc_resolve/src/ident.rs](https://github.com/rust-lang/rust/pull/139493/files#diff-c046507afdba3b0705638f53fffa156cbad72ed17aa01d96d7bd1cc10b8d9bce) similar to an exception added for rust-lang/rust#145575. Specifically this only happens if the import of two builtin macros is ambiguous and they are named `sym::panic`. I.e. this can only happen for `core::panic` and `std::panic`. While there are some tiny differences in what syntax is allowed in `std::panic` vs `core::panic` in editions 2015 and 2018, [see](rust-lang/rust#139493 (comment)). The behavior at runtime will always be the same if it compiles, implying minimal risk in what specific macro is resolved. At worst some closed source project not captured by crater will stop compiling because a different panic is resolved than previously and they were using obscure syntax like `panic!(&String::new())`. ## Design N/A ### Reference > What updates are needed to the Reference? Link to each PR. If the Reference is missing content needed for describing this feature, discuss that. - rust-lang/reference#2077 ### RFC history > What RFCs have been accepted for this feature? N/A ### Answers to unresolved questions N/A ### Post-RFC changes > What other user-visible changes have occurred since the RFC was accepted? Describe both changes that the lang team accepted (and link to those decisions) as well as changes that are being presented to the team for the first time in this stabilization report. N/A ### Key points > What decisions have been most difficult and what behaviors to be stabilized have proved most contentious? Summarize the major arguments on all sides and link to earlier documents and discussions. - Nothing was really contentious. ### Nightly extensions > Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? N/A ### Doors closed > What doors does this stabilization close for later changes to the language? E.g., does this stabilization make any other RFCs, lang experiments, or known in-flight proposals more difficult or impossible to do later? No known doors are closed. ## Feedback ### Call for testing > Has a "call for testing" been done? If so, what feedback was received? No. ### Nightly use > Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative. N/A ## Implementation ### Major parts > Summarize the major parts of the implementation and provide links into the code and to relevant PRs. > > See, e.g., this breakdown of the major parts of async closures: > > - <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html> The key change is [compiler/rustc_builtin_macros/src/standard_library_imports.rs](https://github.com/rust-lang/rust/pull/139493/files#diff-be08752823b8f862bb0c7044ef049b0f4724dbde39306b98dea2adb82ec452b0) removing the macro_use inject and the `v1.rs` preludes now explicitly `pub use`ing the macros https://github.com/rust-lang/rust/pull/139493/files#diff-a6f9f476d41575b19b399c6d236197355556958218fd035549db6d584dbdea1d + https://github.com/rust-lang/rust/pull/139493/files#diff-49849ff961ebc978f98448c8990cf7aae8e94cb03db44f016011aa8400170587. ### Coverage > Summarize the test coverage of this feature. > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. Tests should of course comprehensively demonstrate that the feature works. Think too about demonstrating the diagnostics seen when common mistakes are made and the feature is used incorrectly. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to our review. > > Describe any known or intentional gaps in test coverage. > > Contextualize and link to test folders and individual tests. A variety of UI tests including edge cases have been added. ### Outstanding bugs > What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not. An old bug is made more noticeable by this change rust-lang/rust#145577 but it was recommended to not block on it rust-lang/rust#139493 (comment). ### Outstanding FIXMEs > What FIXMEs are still in the code for that feature and why is it OK to leave them there? ``` // Turn ambiguity errors for core vs std panic into warnings. // FIXME: Remove with lang team approval. ``` https://github.com/rust-lang/rust/pull/139493/files#diff-c046507afdba3b0705638f53fffa156cbad72ed17aa01d96d7bd1cc10b8d9bce ### Tool changes > What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues. - ~~rustfmt~~ - ~~rust-analyzer~~ - ~~rustdoc (both JSON and HTML)~~ - ~~cargo~~ - ~~clippy~~ - ~~rustup~~ - ~~docs.rs~~ No known changes needed or expected. ### Breaking changes > If this stabilization represents a known breaking change, link to the crater report, the analysis of the crater report, and to all PRs we've made to ecosystem projects affected by this breakage. Discuss any limitations of what we're able to know about or to fix. Breaking changes: * It's possible for user code to invoke an ambiguity by defining their own macros with standard library names and glob importing them, e.g. `use nom::*` importing `nom::dbg`. In practice this happens rarely based on crater data. The 3 public crates where this was an issue, have been fixed. The ambiguous panic import is more common and affects a non-trivial amount of the public - and likely private - crate ecosystem. To avoid a breaking change, a new future incompatible lint was added ambiguous_panic_imports see rust-lang/rust#147319. This allows current code to continue compiling, albeit with a new warning. Future editions of Rust make this an error and future versions of Rust can choose to make this error. Technically this is a breaking change, but crater gives us the confidence that the impact will be at worst a new warning for 99+% of public and private crates. ```rust #![no_std] extern crate std; use std::prelude::v1::*; fn xx() { panic!(); // resolves to core::panic //~^ WARNING `panic` is ambiguous //~| WARNING this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! } ``` * Code using `#![no_implicit_prelude]` *and* Rust edition 2015 will no longer automatically have access to the prelude macros. The following works on nightly but would stop working with this change: ```rust #![no_implicit_prelude] // Uncomment to fix error. // use std::vec; fn main() { let _ = vec![3, 6]; } ``` Inversely with this change the `panic` and `unreachable` macro will always be in the prelude even if `#![no_implicit_prelude]` is specified. Error matrix when using `#![no_implicit_prelude]`, ✅ means compiler passes 🚫 means compiler error: Configuration | Rust 2015 | Rust 2018+ --------------|-----------|----------- Nightly (panic\|unreachable) macro | ✅ | 🚫 PR (panic\|unreachable) macro | ✅ | ✅ Nightly (column\|concat\|file\|line\|module_path\|stringify) macro | ✅ | ✅ PR (column\|concat\|file\|line\|module_path\|stringify) macro | ✅ | ✅ Nightly remaining macros | ✅ | 🚫 PR remaining macros | 🚫 | 🚫 Addressing this issue is deemed expensive. Crater found no instance of this pattern in use. Affected code can fix the issue by directly importing the macros. The new behavior matches the behavior of `#![no_implicit_prelude]` in Rust editions 2018 and beyond and it's intuitive meaning. Crater report: - https://crater-reports.s3.amazonaws.com/pr-139493-2/index.html (latest run, but partial run) - https://crater-reports.s3.amazonaws.com/pr-139493-1/index.html (previous full run, one fix missing) Crater analysis: - Discussed in breaking changes. PRs to affected crates: - Michael-F-Bryan/gcode-rs#57 - stbuehler/rust-ipcrypt#1 - jcreekmore/dmidecode#55 ## Type system, opsem ### Compile-time checks > What compilation-time checks are done that are needed to prevent undefined behavior? > > Link to tests demonstrating that these checks are being done. N/A ### Type system rules > What type system rules are enforced for this feature and what is the purpose of each? N/A ### Sound by default? > Does the feature's implementation need specific checks to prevent UB, or is it sound by default and need specific opt-in to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? N/A ### Breaks the AM? > Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? Describe this if so. N/A ## Common interactions ### Temporaries > Does this feature introduce new expressions that can produce temporaries? What are the scopes of those temporaries? N/A ### Drop order > Does this feature raise questions about the order in which we should drop values? Talk about the decisions made here and how they're consistent with our earlier decisions. N/A ### Pre-expansion / post-expansion > Does this feature raise questions about what should be accepted pre-expansion (e.g. in code covered by `#[cfg(false)]`) versus what should be accepted post-expansion? What decisions were made about this? N/A ### Edition hygiene > If this feature is gated on an edition, how do we decide, in the context of the edition hygiene of tokens, whether to accept or reject code. E.g., what token do we use to decide? N/A ### SemVer implications > Does this feature create any new ways in which library authors must take care to prevent breaking downstreams when making minor-version releases? Describe these. Are these new hazards "major" or "minor" according to [RFC 1105](https://rust-lang.github.io/rfcs/1105-api-evolution.html)? No. ### Exposing other features > Are there any other unstable features whose behavior may be exposed by this feature in any way? What features present the highest risk of that? No. ## History > List issues and PRs that are important for understanding how we got here. - This change was asked for here rust-lang/rust#137487 (comment) ## Acknowledgments > Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this *not* think it should be stabilized right now? We'd like to hear about that if so. More or less solo developed by @Voultapher with some help from @petrochenkov. ## Open items > List any known items that have not yet been completed and that should be before this is stabilized. None.

rustbot assigned scottmcm Feb 23, 2025

Voultapher changed the title ~~Stabilize assert_matches and move it to core::macros~~ Stabilize assert_matches and move it to core::macros Feb 23, 2025

This comment has been minimized.

Sign in to view

Voultapher force-pushed the stabilize-assert-matches branch from 01b7c95 to 6859a17 Compare February 23, 2025 15:54

This comment has been minimized.

Sign in to view

rustbot added the A-rustc-dev-guide Area: rustc-dev-guide label Feb 24, 2025

This comment has been minimized.

Sign in to view

Voultapher changed the title ~~Stabilize assert_matches and move it to core::macros~~ Stabilize assert_matches Jan 19, 2026

RalfJung reviewed Jan 19, 2026

View reviewed changes

RalfJung changed the title ~~Stabilize assert_matches~~ Stabilize assert_matches and move it to core::macros Jan 19, 2026

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 19, 2026

Voultapher changed the title ~~Stabilize assert_matches and move it to core::macros~~ Stabilize assert_matches Jan 20, 2026

Voultapher mentioned this pull request Jan 20, 2026

Move assert_matches to planned stable path #151423

Open

Uh oh!

Stabilize assert_matches #137487

Are you sure you want to change the base?

Stabilize assert_matches #137487

Conversation

Voultapher commented Feb 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 23, 2025

Uh oh!

rustbot commented Feb 23, 2025

Uh oh!

Voultapher commented Feb 23, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Voultapher commented Feb 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 24, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

scottmcm commented Mar 20, 2025

Uh oh!

Voultapher commented Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Voultapher commented Mar 20, 2025

Uh oh!

scottmcm commented Mar 20, 2025

Uh oh!

Voultapher commented Mar 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zalathar commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

RalfJung Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Voultapher Jan 19, 2026

Choose a reason for hiding this comment

Uh oh!

Voultapher Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Uh oh!

Voultapher commented Jan 19, 2026

Stabilize `assert_matches` #137487

Stabilize `assert_matches` #137487

Voultapher commented Feb 23, 2025 •

edited

Loading

Voultapher commented Feb 24, 2025 •

edited

Loading

Voultapher commented Mar 20, 2025 •

edited

Loading

Voultapher commented Mar 20, 2025 •

edited

Loading

Voultapher commented Jan 19, 2026 •

edited

Loading

RalfJung Jan 19, 2026 •

edited

Loading

Voultapher Jan 19, 2026 •

edited

Loading

RalfJung commented Jan 19, 2026 •

edited

Loading