Rust 1.98 lands August 20. One change can break your crate.

Rust 1.98.0 becomes stable on August 20, 2026, six weeks after Rust 1.97.0 shipped on July 9, 2026. Most releases in this cadence are safe to take on release day. This one has a sharp edge worth ten minutes of your attention.

The compiler now takes a fast path for derive(PartialOrd) when Ord is derived on the same type. The draft release notes flag it as a compatibility risk: it "can break crates in practice where a type's PartialOrd and Ord impls were inconsistent with each other."

Key takeaways

• Rust 1.98.0 reaches stable on August 20, 2026, and the derive fast path for PartialOrd is its main compatibility risk.
• Types that derive one ordering trait and hand-write the other are the ones at risk, because the fast path assumes the two agree.
• c_variadic is not in Rust 1.98. The stabilization pull request targets the 1.99.0 milestone, which puts it in the release after this one.

What the derive change actually does

PartialOrd is the Rust trait for types that can be compared with <, > and partial_cmp, where some pairs may be incomparable. Ord is the stricter trait for a total order, where every pair has an answer.

Before 1.98, #[derive(PartialOrd)] generated field-by-field comparison logic that LLVM struggled to collapse, an inefficiency tracked since 2018 in rust-lang issue #49505. On types with many fields or deep struct nesting, that produced bulky comparison code in the final binary.

In 1.98, when both Ord and PartialOrd are derived on the same type, partial_cmp delegates straight to the Ord implementation. Less generated code, smaller binaries, faster comparisons. The catch is in the assumption.

Why that can break real code

The fast path is only correct if PartialOrd and Ord agree. Rust has always required that. The standard library documentation for PartialOrd states that if Ord is also implemented, it must be consistent with partial_cmp.

Requirements that are documented but unenforced drift. The common way to break this is to derive one trait and write the other by hand, then let the manual version pick up a special case the derived version never learned.

For example, a type that derives PartialOrd while implementing Ord manually to sort a priority field in reverse now silently changes behaviour. Before 1.98, < used the derived field order. From 1.98, it follows the hand-written Ord. Nothing fails to compile. Your sort order moves.

How to check your crates in ten minutes

This is a search problem, not a migration.

1. Grep your workspace for derive( lines that include PartialOrd or Ord.
2. Flag every type where one of the two is derived and the other is written by hand. Those are the only types at risk.
3. For each flagged type, assert consistency in a test: for a sample of pairs, check that a.partial_cmp(&b) == Some(a.cmp(&b)).
4. Fix by deriving both, or by making the manual implementation match, whichever matches the intent you actually want.
5. Run the suite on the beta toolchain with rustup default beta before August 20 if you want the answer early.

Consider it maintenance you were owed anyway. A type whose two ordering traits disagree has a latent bug independent of any compiler release.

What else is in Rust 1.98

The rest of the release is routine, which is the point of a six-week cadence.

Area	Change in 1.98.0
Language	Shortening the lifetime of &mut is allowed when unsize-coercing, even in invariant position
Platform	Five ARM Thumb targets promoted to Tier 2, including thumbv7a-none-eabi and thumbv8r-none-eabihf
Platform	New Tier 3 targets powerpc64-unknown-linux-gnuelfv2 and aarch64-unknown-linux-pauthtest
Config	RISC-V d, e and f target features stable in cfg(target_feature = "?")
Library	Stabilized strip_circumfix, nonzero_from_str_radix, atomic_from_mut, and UTF-16 encoding helpers
Compatibility	derive(PartialOrd) fast path when Ord is derived

The Tier 2 promotion is the quiet win for embedded teams. Tier 2 means the Rust project builds and ships those targets, so rustup target add works without a local toolchain build.

No, c_variadic is not in this release

Several write-ups have attached C variadic function definitions to Rust 1.98. That is wrong, and it is worth stating plainly, because the feature is a real migration unblocker for teams replacing C libraries.

The stabilization pull request for defining C variadic functions was merged on July 22, 2026 and carries the 1.99.0 milestone. Rust 1.98 branched from the main branch on July 3, 2026, so a July 22 merge could not reach it. On the current six-week cadence, 1.99.0 arrives around October 1, 2026.

When it does land, the rules are narrow. The function must be unsafe, must use the extern "C" or extern "C-unwind" ABI, and the ... argument must come last. Arguments are read through a VaList, and only types implementing VaArgSafe are valid, which covers c_int, c_long, c_longlong, their unsigned variants, c_double and pointers.

Should you upgrade on day one?

Yes, for most projects. Rust's stability guarantees hold, and the compatibility note here is narrow rather than sweeping.

Upgrade immediately if no type in your workspace mixes a derived and a hand-written ordering implementation. That covers the large majority of crates, and the derive fast path is a free binary-size win.

Wait a week if you maintain a widely depended-on library with custom Ord logic. Not because 1.98 is risky for you, but because your users will hit any behaviour change through your crate, and a point release is a cheaper place to fix it than an issue tracker.

If you are planning C-to-Rust migration work that needs variadic callbacks, plan around 1.99 in October rather than this release.

Frequently asked questions

When is Rust 1.98 released?

Rust 1.98.0 becomes stable on August 20, 2026. It follows Rust 1.97.0, which was announced on July 9, 2026, on the project's regular six-week release cadence. Rust 1.99.0 is expected around October 1, 2026.

What breaks in Rust 1.98?

The compatibility risk is the new fast path for derive(PartialOrd) when Ord is derived on the same type. The draft release notes state it can break crates where a type's PartialOrd and Ord implementations were inconsistent with each other. Code that derives both traits, or writes both consistently, is unaffected.

How do I know if my type is affected by the PartialOrd change?

Look for types where one of PartialOrd and Ord is derived and the other is implemented by hand. Then test that a.partial_cmp(&b) equals Some(a.cmp(&b)) for representative pairs. If that assertion holds, the fast path changes nothing for you.

Does Rust 1.98 include c_variadic?

No. The pull request stabilizing C variadic function definitions was merged on July 22, 2026 with the 1.99.0 milestone, after Rust 1.98 had already branched on July 3, 2026. Expect it in Rust 1.99.0, around October 1, 2026.

What are the new Tier 2 targets in Rust 1.98?

Five ARM Thumb targets move to Tier 2: thumbv7a-none-eabi, thumbv7a-none-eabihf, thumbv7r-none-eabi, thumbv7r-none-eabihf and thumbv8r-none-eabihf. Two Tier 3 targets are also added, powerpc64-unknown-linux-gnuelfv2 and aarch64-unknown-linux-pauthtest.