The Rust standard library now runs cargo-semver-checks in CI to catch accidental breakage of stable APIs, following a history of incidents where unstable methods or soundness fixes accidentally broke stable code (async-std in 2020, BuildHasher's dyn-safety in 2021, ChunksMut's Send/Sync in 2022, and a tokio Windows breakage in Rust 1.94 that required a 1.94.1 point release). The work required teaching cargo-semver-checks to understand Rust's stability attributes (#[stable], #[unstable], const-stability, default-body stability) and exposing that data through new rustdoc JSON fields, reusing existing #[doc(hidden)] handling infrastructure so hundreds of existing lints work correctly without modification. The effort grew out of hallway conversations at RustWeek 2026 and the Rust All Hands, took months and 15,000+ lines of code, and remaining work includes better UX for reporting stability breakage and covering more platforms.
Table of contents
Stability, breakage, and stability breakagePlugging stability info into cargo-semver-checksHow we got here and what lies aheadQuestions this post answers
Why did tokio's test suite fail to compile on Windows with Rust 1.94?
A standard library trait gained new unstable methods that inadvertently broke tokio's test suite compilation on Windows under Rust 1.94. The breakage was severe enough that the Rust team shipped a fix in the 1.94.1 point release in March 2026 rather than waiting for the next regular release cycle. Track point-release fixes like this on daily.dev so a Rust upgrade doesn't quietly break your Windows CI.
Does cargo-semver-checks now run in the Rust compiler's CI to catch stdlib API breakage?
Yes, cargo-semver-checks is now integrated into Rust's CI to catch accidental breakage of the standard library's stable API surface. This followed months of work adding stability metadata (stable, unstable, const-stability, default-body stability) to rustdoc JSON so the existing semver-checking lints could correctly distinguish stable APIs from unstable ones without being rewritten. Rust maintainers weighing new CI tooling can follow releases like this through daily.dev.
How does cargo-semver-checks treat an #[unstable] item in the Rust standard library for breakage purposes?
It treats any #[unstable] item as non-public API, exactly as if it were marked #[doc(hidden)], so breaking it is not flagged as a semver violation. The same logic applies to const-unstable items, which are treated as non-const, and unstable default trait method bodies, which are treated as not provided at all. Developers building semver tooling for their own crates can find deep dives like this via daily.dev.
189.4K Impressions2 Comments