Announcing Rust 1.97.0

Rust 1.97.0 发布公告

July 9, 2026 · The Rust Release Team 2026 年 7 月 9 日 · Rust 发布团队

The Rust team is happy to announce a new version of Rust, 1.97.0. Rust is a programming language empowering everyone to build reliable and efficient software. Rust 团队很高兴地宣布 Rust 1.97.0 版本正式发布。Rust 是一门旨在让每个人都能构建可靠且高效软件的编程语言。

If you have a previous version of Rust installed via rustup, you can get 1.97.0 with: $ rustup update stable 如果你之前通过 rustup 安装了 Rust，可以通过以下命令获取 1.97.0 版本：$ rustup update stable

If you don’t have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.97.0. 如果你还没有安装，可以从我们官网的相关页面获取 rustup，并查看 1.97.0 的详细发布说明。

If you’d like to help us out by testing future releases, you might consider updating locally to use the beta channel (rustup default beta) or the nightly channel (rustup default nightly). Please report any bugs you might come across! 如果你愿意通过测试未来版本来帮助我们，可以考虑在本地更新并使用 beta 通道（rustup default beta）或 nightly 通道（rustup default nightly）。如果遇到任何 Bug，请务必向我们报告！

What’s in 1.97.0 stable

1.97.0 稳定版中的新特性

Symbol mangling v0 enabled by default

默认启用 v0 符号修饰 (Symbol mangling)

When Rust is compiled into object files and binaries, each item (functions, statics, etc) must have a globally unique “symbol” identifying it. To avoid conflicts when linking together different Rust programs, Rust mangles the original name of items to include additional context such as the module path, defining crate, generics, and more. 当 Rust 代码被编译为目标文件和二进制文件时，每个项（函数、静态变量等）都必须有一个全局唯一的“符号”来标识它。为了避免在链接不同的 Rust 程序时发生冲突，Rust 会对项的原始名称进行“修饰”（mangle），加入模块路径、定义所在的 crate、泛型等额外上下文信息。

Historically, this mangling was based on the Itanium ABI, also (sometimes) used by C++. The new mangling scheme resolves a number of drawbacks from the previous one: 过去，这种修饰基于 Itanium ABI，这也是 C++（有时）所使用的标准。新的修饰方案解决了旧方案的若干缺陷：

• Generic parameter instantiations preserve their values, rather than being tracked solely behind a hash
• 泛型参数实例化保留其值，而不是仅仅通过哈希值进行追踪
• Inconsistencies: not all parts used the Itanium ABI, meaning that custom demangling was still necessary
• 不一致性：并非所有部分都使用 Itanium ABI，这意味着仍然需要自定义的去修饰（demangling）工具

Since Rust 1.59, the compiler has supported opting into a Rust-specific mangling scheme via -Csymbol-mangling-version=v0. Since November 2025, this scheme has been enabled by default on nightly, and 1.97 is now enabling it on stable Rust. The legacy mangling scheme can only be enabled on nightly, and the current plan is to fully remove it. See the previous blog post for more details. 自 Rust 1.59 起，编译器已支持通过 -Csymbol-mangling-version=v0 选项选择使用 Rust 特有的修饰方案。自 2025 年 11 月起，该方案已在 nightly 版本中默认启用，而 1.97 版本现在将其引入了稳定版 Rust。旧版修饰方案目前仅能在 nightly 版本中启用，且目前的计划是将其完全移除。更多详情请参阅之前的博客文章。

Cargo support for denying warnings

Cargo 支持拒绝警告 (Deny warnings)

It’s common practice to deny warnings in CI. Historically, doing so is typically done through RUSTFLAGS=-Dwarnings. With Rust 1.97, Cargo controls how warnings interact with build success: either silencing them (via allow level), rendering without failing (default, warn), or denying them (via deny). 在 CI 中拒绝警告是一种常见的做法。过去，这通常通过 RUSTFLAGS=-Dwarnings 来实现。在 Rust 1.97 中，Cargo 可以控制警告如何影响构建成功与否：可以选择静默警告（通过 allow 级别）、显示警告但不导致构建失败（默认，warn），或者拒绝警告（通过 deny）。

As a result of Cargo configuration determining the behavior, using this feature doesn’t invalidate the underlying build cache, meaning that it’s easy to temporarily opt-in. For example, if warnings are adding unwanted noise while working through fixing errors after a refactor, you can run CARGO_BUILD_WARNINGS=allow cargo check, temporarily silencing them. In CI, jobs can instead set CARGO_BUILD_WARNINGS=deny to deny warnings. This can be combined with --keep-going to collect all errors and warnings rather than stopping on the first failing package. See the documentation for more details. 由于行为由 Cargo 配置决定，使用此功能不会使底层的构建缓存失效，这意味着可以轻松地临时启用它。例如，如果在重构后修复错误时警告造成了不必要的干扰，你可以运行 CARGO_BUILD_WARNINGS=allow cargo check 来临时静默它们。在 CI 中，任务可以设置 CARGO_BUILD_WARNINGS=deny 来拒绝警告。这可以与 --keep-going 结合使用，以收集所有错误和警告，而不是在第一个失败的包处停止。更多详情请参阅文档。

Linker output no longer hidden by default

链接器输出不再默认隐藏

rustc invokes a linker on behalf of users. Historically, rustc has silenced linker output by default if the link completes successfully. This can mask real problems, though, so in Rust 1.97 we are enabling linker messages by default. These are emitted as a warning lint, for example: rustc 会代表用户调用链接器。过去，如果链接成功，rustc 默认会静默链接器的输出。但这可能会掩盖实际问题，因此在 Rust 1.97 中，我们默认启用了链接器消息。它们会作为警告 lint 输出，例如：

warning: linker stderr: ignoring deprecated linker optimization setting '1' | = note: #[warn(linker_messages)] on by default

Common linker messages that have been diagnosed as false positives or intentional behavior are filtered out by rustc. Several defects have already been fixed as a result of no longer hiding this output on nightly. Note that currently, linker_messages is a special lint that is not affected by the warnings lint group. This is intentional as rustc generally doesn’t control linker output as precisely, and it’s not uncommon for output to only appear on some platforms. 被诊断为误报或有意行为的常见链接器消息会被 rustc 过滤掉。由于在 nightly 版本中不再隐藏此输出，已经修复了若干缺陷。请注意，目前 linker_messages 是一个特殊的 lint，不受 warnings lint 组的影响。这是有意为之的，因为 rustc 通常无法精确控制链接器输出，且输出仅在某些平台上出现的情况并不罕见。

If you are seeing what you think is a false positive output from the linker, please file an issue. To silence the warning in the mean time, you can configure the lint level to allow. This can be done through Cargo.toml by adding a lints section like this: 如果你认为看到了来自链接器的误报输出，请提交 Issue。在此期间，若要静默该警告，可以将 lint 级别配置为 allow。这可以通过在 Cargo.toml 中添加如下 lints 部分来实现：

[lints.rust]
linker_messages = "allow"

Stabilized APIs

已稳定的 API

• Default for RepeatN
• Copy for ffi::FromBytesUntilNulError
• Send for std::fs::File on UEFI
• <{integer}>::isolate_highest_one
• <{integer}>::isolate_lowest_one
• <{integer}>::highest_one
• <{integer}>::lowest_one
• <{uN}>::bit_width
• NonZero<{integer}>::isolate_highest_one
• NonZero<{integer}>::isolate_lowest_one
• NonZero<{integer}>::highest_one
• NonZero<{integer}>::lowest_one
• NonZero<{uN}>::bit_width

These previously stable APIs are now stable in const contexts: 以下先前已稳定的 API 现在在 const 上下文中也已稳定：

• char::is_control

Other changes

其他更改

Check out everything that changed in Rust, Cargo, and Clippy. 查看 Rust、Cargo 和 Clippy 中发生的所有更改。

Contributors to 1.97.0

1.97.0 的贡献者

Many people came together to create Rust 1.97.0. We couldn’t have done it without all of you. Thanks! 许多人共同努力创造了 Rust 1.97.0。没有你们大家，我们无法做到这一点。谢谢！