Rust 1.100がリリース、never型とアロケーター、Cargoのリントを搭載

Rust Projectは2026年11月12日、Rust 1.100.0をリリースした。never型を安定化し、カスタムアロケーターAPIの中核を開放し、Cargoが未使用の依存関係を警告するようにした。never型の変更は破壊的変更でもあり、リリースノートでは"Compatibility Notes"(互換性に関する注記)の項目に載っている。どのエディションのプロジェクトでも、以前はコンパイルできていた箇所でビルドが失敗するようになりうる。

Rust Blogの発表によると、never型は安定版になるまでに10年と、5回の失敗した試みを要した。LWN.netも同じ3つの変更を冒頭に挙げた。never型、Allocator APIの中核、そしてCargoの未使用依存関係レポートだ。Rustのユーザーはrustup update stableで更新できる。

Rust 1.100の新機能

never型は!と書き、panic!や無限ループのように、決して終わらないコードの型だ。これまでは関数の戻り値の型としてしか使えなかった。Rustのnever型に関する当サイトの解説で詳しく説明しており、8月の記事では、これを安定版にしたプルリクエストを取り上げた。

下の表は、ブログ記事、GitHubのリリースノート、Cargoの変更履歴をもとに作成した。

変更点	何をするか	影響を受けるもの
never型!	Result<T, !>のようにどこでも使える。Infallibleは!の別名になる	古いフォールバックに頼っていたコード
型フォールバック	発散する分岐の不明な型が、すべてのエディションで()ではなく!になる	エディション2024に移行していない古いクレート
Allocator API	Allocator、Global、System、およびVec::new_in、Box::new_inなどのメソッド	自前でメモリを管理するコード
cargo::unused_dependencies	Cargo.tomlの依存関係が一度も使われないと警告する	すべてのCargoプロジェクト
公開からの最小経過期間	設定した期間より新しいクレートのバージョンを、Cargoが飛ばせる	サプライチェーン攻撃を懸念するチーム
ビルドディレクトリの構成	中間ビルドファイルの置き場所が変わる	Cargoのtargetフォルダーを直接読むスクリプト
i686-pc-windows-gnu	ホストツールなしのTier 2になった	32ビットWindowsのユーザー

32ビットWindowsの変更は10月に発表されていた。i686ターゲットに関する当サイトの記事で説明したとおりだ。今回のリリースでは、bool::toggle、Vec::from_fn、str::trim_prefixなどの小さな補助機能も安定化された。

Tech AI Wireのテスト: Rust 1.99.1と1.100.0の比較

macOS 26.6.2で行ったTech AI Wireのテストでは、同じ小さなプロジェクトを公式のrust:1.99-slimとrust:1.100-slimのDockerイメージで動かした。どちらもarm64上のDebian 13だ。イメージはrustc 1.99.1とrustc 1.100.0を報告した。

最初のプロジェクトはエディション2021で、次のコードを使った。

fn make<T: Default>() -> Result<T, ()> {
    Ok(T::default())
}

fn main() -> Result<(), ()> {
    make()?;
    Ok(())
}

Tが何かをコンパイラーに伝えるものがないため、コンパイラーは既定の型にフォールバックする。各バージョンの結果は次のとおりだ。

コード	Rust 1.99.1	Rust 1.100.0
書いたまま	リントdependency_on_unit_never_type_fallbackによるエラー	エラーE0277: "the trait bound !: Default is not satisfied"(トレイト境界!: Defaultが満たされていない)
#![allow(dependency_on_unit_never_type_fallback)]付き	ビルドでき、実行できる	依然としてエラーE0277。リントは"has been removed"(削除された)
make::<()>()?の場合	ビルドでき、実行できる	ビルドでき、実行できる

真ん中の行が落とし穴だ。1.99で警告を黙らせたクレートは、そこではビルドできるが、1.100では失敗する。Rust 1.100は、リントを削除した理由を"the code warned by this lint no longer compiles"(このリントが警告したコードは、もうコンパイルできない)と説明する。直す方法は、型を明示することだけだ。

カスタムアロケーターのテストでは、グローバルアロケーターをラップして要求の回数を数えた。1.99.1ではエラーE0658、"use of unstable library feature allocator_api"(不安定なライブラリ機能allocator_apiの使用)で失敗した。1.100.0ではstable(安定版)で動いた。1,000個の数値を持つVecとBox1つで、割り当て呼び出しは10回、合計16,356バイトだった。

Tech AI Wireのテスト: Cargoの2つの新しい安全チェック

あるクレート(Rustのパッケージ)は、itoaとmemchrを依存関係に挙げていたが、使っていたのはitoaだけだった。1.100では、cargo buildが"warning: unused dependency memchr"(未使用の依存関係memchr)と表示した。[lints.cargo]の下でunused_dependencies = "deny"を設定すると、これがエラーになり、ビルドが止まった。一度も使われないdev-dependencyには警告が出なかった。単一のターゲットをチェックするcargo check --bin unusedでも出なかった。どちらも、ブログ記事が挙げる例外に当てはまる。Rust 1.99.1は[lints.cargo]テーブルを無視し、"unused manifest key"という警告を出した。

公開からの最小経過期間は、出たばかりのクレートのバージョンの採用を遅らせる。ブログ記事はこれを"dependency cooldowns"(依存関係のクールダウン)と呼ぶ。待つ間に、自分のビルドが取り込む前に、ほかの人が悪いリリースを見つける時間ができる。[registry]の下でglobal-min-publish-age = "3 days"を設定すると、Cargoはccを1.11.1に固定した。表示は"available: v1.11.2, published 2 hours ago"(v1.11.2が利用可能、2時間前に公開)だった。設定を外すと、Cargoは1.11.2を選んだ。30日にすると、解決に失敗した。cargo addがすでに1.11.1を最小バージョンとして書き込んでいたためだ。Cargoは、要件を"1.8.0"に下げるか、CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allowを設定するよう提案した。

開発者にとっての意味

• CIを更新する前に、すべてのクレートを1.100でビルドする。 古いエディションのコードが最も壊れやすい。allow(dependency_on_unit_never_type_fallback)を検索しよう。そのコードは1.100で失敗するからだ。
• フォールバックのエラーは、型を明示して直す。 make::<()>()のようなコンパイラー自身の提案は、テストでは両方のバージョンで動いた。
• 公開からの最小経過期間を今すぐ有効にする。 .cargo/config.tomlでglobal-min-publish-ageを3日にしても、コストはほとんどない。cargo addを実行する前に設定しておくこと。このコマンドは、選んだバージョンをCargo.tomlに書き込むからだ。
• denyにする前に、未使用の依存関係を整理する。 既定のwarnから始め、見つかったものを取り除いてから、CIでdenyに切り替える。
• Compatibility Notesを読む。 削除されたboxパターン、Unicode 18.0.0、ARMのtarget-featureチェックの厳格化も載っている。
• Cargoのビルドフォルダーを直接読むのをやめる。 その構成は1.100で変わった。Cargoの変更履歴は、ツールは代わりにCargoのJSONメッセージを使うべきだとしている。