Rust 1.97.0がリリースされた — ちょうどそのcargoでKubernetesオペレーターをビルドしていたところだった

はじめに — リリースノートと自分のターミナルが重なった日
1.97で実際に変わった三つ
正直に言うと — オペレーターにはツールチェーンのバージョンよりkube-rsが重要だった
では、誰が今アップグレードすべきか
おわりに
参考資料

はじめに — リリースノートと自分のターミナルが重なった日

2026年7月9日、Rust 1.97.0がstableになりました。偶然にも私はその数日前から、ホームラボのサーバー（Ubuntu、rustupで導入）で cargo 1.97 を使ってKubernetes GPUオペレーターを書いていました。ですからこの記事は二層です。(1) リリースノートで 実際に変わったもの をそのまま読み、(2) まさにそのツールチェーンで実作業をした者の視点から「それが自分の作業を何を変えたのか」を正直に問います。結論から言えば、興奮するようなリリースではありません。そして、それは悪い意味ではありません。

1.97で実際に変わった三つ

リリースノートのヘッドラインは三つです。どれも言語の文法ではなく ツールチェーンの挙動 に関するものです。

1. v0シンボルマングリングがstableのデフォルトになりました。 これまでrustcはC++のItanium ABIマングリングを流用しており、この方式はジェネリック引数をハッシュの裏に隠して情報を失っていました。新しいv0スキームはRust専用で、リリースノートの表現どおり「ジェネリックパラメーターのインスタンス化がハッシュの裏だけで追跡されるのではなく、その値を保存する」ようになります。2025年11月からnightlyのデフォルトで、1.97でstableに昇格しました。目に見える効果は、バックトレースや perf のようなプロファイラー、デバッガーのシンボルが読みやすくなることです — 普段は見えず、問題を掘るときにありがたい類の変化です。

2. Cargoが警告を「拒否（deny）」できるようになりました。 新しい build.warnings 設定（環境変数 CARGO_BUILD_WARNINGS）が三段階を与えます — allow（無視）、warn（ビルドは通過、デフォルト）、deny（警告でビルド失敗）。

# .cargo/config.toml
[build]
warnings = "deny"

核心的な利点は、リリースノートの表現どおり「この機能を使ってもビルドキャッシュが無効化されない」ことです。これまでCIでよく使われた RUSTFLAGS="-D warnings" はフラグが変わると全体の再ビルドを誘発しましたが、これはそうではないので、一時的にオンオフしやすいのです。CIで --keep-going と組み合わせれば、止まる前にすべてのエラーを集めて見ることもできます。

3. リンカー出力がもう隠れません。 これまでrustcはリンクが成功するとリンカー出力を静かに飲み込んでいました。1.97からはリンカーメッセージを警告レベルのlintとしてデフォルトで表示し、Cargo.toml の [lints.rust] で調整します。nightlyでこれをオンにしたところ、実際に隠れていた欠陥がいくつか露見して修正されたそうです。

そして細かな安定化APIです。

Default for RepeatN
Copy   for ffi::FromBytesUntilNulError
Send   for std::fs::File (UEFI)
<{integer}>::isolate_highest_one / isolate_lowest_one / highest_one / lowest_one
<{uN}>::bit_width
NonZero<{integer}>:: 上記メソッドの対応版
const昇格: char::is_control

ビットを直接触るコードなら嬉しい整数メソッドですが、大半のアプリコードには今日すぐの影響はありません。

正直に言うと — オペレーターにはツールチェーンのバージョンよりkube-rsが重要だった

ここがこの記事の本当の要点です。私は cargo 1.97 で実際のオペレーターをビルドして動かしました。実測環境です。

ビルド    cargo 1.97, リリース初回16.7秒（依存込み）、増分2.6秒
クレート  kube 0.96 (client+runtime+derive+rustls-tls), k8s-openapi 0.23 (v1_31)
実行      out-of-cluster、~/.kube/configで実際のAPIサーバーに接続
対象      Kubernetes v1.32.5

しかし率直に言うと、 上記の三つの1.97ヘッドラインのどれも、このオペレーターの書き方を変えませんでした。 オペレーターを可能にしたのは言語やツールチェーンの今回のバージョンではなく、kube-rs 0.96という生態系でした — #[derive(CustomResource)] で構造体をCRDに変え、controllerランタイムがリコンサイルループを回し、rustls-tls でopensslの依存なしにどこでもビルドできるようにすること。このレバレッジはすべてクレート側にあります。

16.7秒/2.6秒というビルド速度も、1.97の功績というより単にcargoがcargoである恩恵です。つまりRustの 言語・ツールチェーンはすでに退屈なほど安定 しており（褒め言葉です）、実際の生産性の差は生態系で生まれます。そのオペレーターが実際に何を見つけたのか — 私のGPUノード4個が全部死んでいたという診断 — は、実測ログとともにRustでKubernetes GPUオペレーターを作るに別途まとめました。

では、誰が今アップグレードすべきか

淡々と整理するとこうです。

大半の人：ただ rustup update stable して忘れればよいです。コードを変える理由はありません。
デバッグ・プロファイリングをよくする人：v0マングリングのおかげでバックトレースと perf のシンボルが良くなります。静かですが実質的な利得です。
CIを管理する人：build.warnings = "deny" はキャッシュを壊さずに警告を失敗に変えるので、RUSTFLAGS="-D warnings" の代替になりえます。
クロスコンパイル・カスタムリンカーと格闘する人：ようやくリンカーが言っていたことが見えます。掘っていた人には嬉しい変化です。

$ rustup update stable

急ぐ理由はありません。6週周期の静かなリリースらしく、上げればおおむね少し良くなり、上げなくても今日すぐには壊れません。

おわりに

正直な感想はこうです。Rust 1.97は文法を揺らすリリースではなく、シンボル・警告・リンカーといった ツールチェーンの衛生 を手入れするリリースです。派手ではありませんが、こういうものが積み重なって「動けばだいたい正しい」という言語への信頼が作られます。そして、まさにその数日間の実測が私に教えてくれたのは少し違う角度でした — 実際の仕事を回す力は、ツールチェーンのバージョン番号ではなく、その上で成熟した生態系（kube-rs）にあるということ。ですから1.97は静かに上げて、エネルギーはクレートを選ぶことに使うほうがよいのです。