What Is New in Rust 1.97
| Category | Highlights |
|---|---|
| New Features |
|
| Improvements |
|
| Bug Fixes | Several linker defects were uncovered and fixed as a result of no longer suppressing linker output on nightly builds |
| Breaking Changes | None expected for typical projects; the legacy symbol mangling scheme is no longer available on stable |
| Deprecations | The legacy (Itanium-based) symbol mangling scheme is being phased out and can now only be enabled via nightly, with full removal planned |
Why did Rust switch to symbol mangling v0 by default?
Rust 1.97 enables the v0 mangling scheme by default on stable because it fixes long-standing inconsistencies in how symbols were named in compiled binaries. Historically, rustc used a mangling scheme derived from the Itanium ABI, the same one used by C++, but this scheme was never a perfect fit for Rust semantics such as generics.
In practice, the old scheme buried generic parameter instantiations behind a hash, which made demangled symbol names hard to interpret when debugging or profiling. The v0 scheme preserves those values directly. It also unifies mangling behavior across the compiler, since previously not every code path consistently followed the Itanium ABI, forcing tools to implement custom demangling logic.
This matters if your team relies on symbol names for profiling, crash reporting, or binary analysis tooling. You may notice different (and more informative) symbol names in stack traces, debuggers, and profilers after upgrading. The change has been running on nightly since November 2025, so most rough edges have already been ironed out. The legacy scheme still exists but is now nightly-only, and the Rust team's stated plan is to remove it entirely, so tooling that parses raw Itanium-mangled names should migrate.
How do I deny warnings in CI with Cargo 1.97 instead of RUSTFLAGS?
Cargo 1.97 lets you control warning behavior directly through configuration rather than environment-variable hacks. Previously, most teams denied warnings in CI using RUSTFLAGS=-Dwarnings, which has a history of subtle problems, including invalidating build caches and interacting poorly with build.rs scripts.
The new build.warnings setting supports three levels:
allow- silence warnings entirelywarn(default) - render warnings without failing the builddeny- fail the build if any warnings are emitted
Because this is controlled through Cargo configuration rather than compiler flags baked into the build fingerprint, toggling it does not force a full rebuild. This makes it practical to flip warnings on and off locally. For example:
CARGO_BUILD_WARNINGS=allow cargo check
is handy while working through a refactor with a lot of expected noise. In CI, set:
CARGO_BUILD_WARNINGS=deny cargo build --keep-going
Watch out for the --keep-going flag here; it lets Cargo collect every error and warning across all packages in a workspace instead of stopping at the first failing crate, which is particularly useful in CI logs.
Will Rust 1.97 make my builds noisier because of linker warnings?
Yes, by default Rust 1.97 now surfaces linker output as a compiler warning instead of hiding it. Historically, rustc suppressed the linker's own stderr output whenever a link step succeeded, which occasionally masked real configuration problems.
These messages now appear as a dedicated linker_messages lint, for example:
warning: linker stderr: ignoring deprecated linker optimization setting '1'
|
= note: `#[warn(linker_messages)]` on by default
Most teams won't see much extra noise, since known false positives and platform-specific quirks are already filtered by rustc, and this change has been active on nightly for a while, catching several real linker defects along the way. Note that linker_messages is deliberately excluded from the general warnings lint group, since linker behavior varies significantly across platforms and toolchains.
If the new warning is noisy for your setup, you can silence it explicitly in Cargo.toml:
[lints.rust]
linker_messages = "allow"
What standard library APIs were stabilized in Rust 1.97?
Rust 1.97 stabilizes a focused set of small but useful APIs, mostly centered on integer bit manipulation. Highlights include:
Defaultforiter::RepeatNCopyforffi::FromBytesUntilNulErrorSendforstd::fs::Fileon UEFI targetsisolate_highest_oneandisolate_lowest_oneon integer primitives andNonZerotypeshighest_oneandlowest_oneon integer primitives andNonZerotypesbit_widthon unsigned integer primitives andNonZerotypes
In addition, char::is_control is now usable in const contexts. These additions are most relevant for embedded, systems, and bit-twiddling-heavy code, where isolating or measuring specific bits previously required manual masking logic.
FAQ
Do I need to change my code to upgrade to Rust 1.97?
No, most existing projects will compile and run without modification since the changes in this release are additive or default-on behavior tweaks rather than language-level breaking changes.
Why are my symbol names different after upgrading to Rust 1.97?
Rust 1.97 enables the v0 symbol mangling scheme by default on stable, which produces different and more descriptive symbol names than the previous Itanium-based scheme, so tools that parse raw mangled names may need updating.
How do I deny warnings in CI without using RUSTFLAGS?
Set the environment variable CARGO_BUILD_WARNINGS=deny before your build command, for example CARGO_BUILD_WARNINGS=deny cargo build, which fails the build on any warning without invalidating your build cache.
Why is my build suddenly showing linker warnings after upgrading?
Starting in Rust 1.97, rustc no longer hides linker stderr output on successful links and instead reports it through the new linker_messages lint, which was previously suppressed by default.
Can I disable the new linker warning messages?
Yes, add a lints section to your Cargo.toml setting linker_messages to allow, which silences the warning while keeping the rest of your lint configuration intact.
Is the legacy symbol mangling scheme still available in Rust 1.97?
It is only available on the nightly channel and the Rust team has stated their intention to remove it entirely, so relying on it long-term is not recommended.