The 1.96.0 pre-release is ready for testing. The release is scheduled for May 28. Release notes can be found here.
You can try it out locally by running:
RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable
The index is https://dev-static.rust-lang.org/dist/2026-05-26/index.html.
The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.
If you end up regenerating the release notes for whatever reason – there's a <code> block in them (in the first bullet point in the section about Rustdoc) that contains two consecutive spaces (and is intended to do so because they're semantically important), but it isn't marked as non-breaking. On my browser, the two consecutive spaces happen to appear at the end of the line, so you can't see them. (This isn't a serious issue because there's a clarifying comment "two spaces and a newline" afterwards, and thus isn't worth regenerating the release notes over if doing so is difficult, but it does look somewhat wrong and would be worth fixing if the release notes need updating for some other reason.)
Hmm, I'm not sure how to fix that, but if you know could you make a suggestion on the main PR?
With our release process, fixing this in the stable artifacts would require a whole new build though, so I don't think we'll bother unless something else comes up.
Unfortunately the page seems to be written in Markdown, and I'm not sure how to do that in a way that would be reliable across different Markdown renderers and hosts. Normally you'd wrap it in <span style="white-space: nowrap">…</span> or an equivalent, but some Markdown renderers won't copy inline CSS and some webhosts have a content-security policy against it (meaning that it won't render properly). There's also the complication that you would need to specify preserving multiple spaces in addition to not wrapping…
(It would probably be better to ask a webdev for information on how to fix this sort of problem than it would be to ask a systems programmer like me.)
Perhaps this would be a good time to use a printing space mark, e.g.
the standard markdown method of forcing a linebreak, which is
"␣␣\n"(two spaces followed by a newline).
That's U+2423 OPEN BOX, aka \textvisiblespace in LaTeX-ese, but there are several other characters that could be used.
I'm with you on that. 
I made a different suggested edit here, "... which is two spaces followed by a newline ("\n")."
I thought I found a quirk in this release to do with the scoping of assert_matches! and debug_assert_matches!, but it turned out that it is merely that both macros are not in the prelude, and
#![no_std]
#[macro_use]
extern crate std;
brings them into scope but a normal std-using crate doesn’t.
Right, that's intentional to avoid prelude conflicts with existing crates that provide those macros.