プログラミング

Rust 1.100リリース — never型が10年越しで安定化、Cargoに依存クールダウンと未使用依存の警告

RustCargoサプライチェーンプログラミング言語

はじめに

2026年11月12日、Rust 1.100.0 がリリースされました。Hacker News では 850 ポイントを超え、300 件以上のコメントが付いています。

バージョン番号が3桁になったこと自体について、公式ブログは何も触れていません。ただ中身は、ここ数年で最も大きいリリースの一つです。10年間で5回安定化に失敗してきた never 型（!）がついに安定し、カスタムアロケータの API も入りました。Cargo には、公開から日の浅いバージョンを避ける「依存クールダウン」と、未使用の依存を知らせる警告が加わっています。

この記事では、アップデートで既存コードが壊れうる箇所と、Cargo の新機能を実務でどう使うかを整理します。

Rust 1.100 の主な変更点

分野変更
言語never 型 ! を型として書けるようになった。Infallible は ! の別名に
互換性2015/2018/2021 エディションでも never 型のフォールバックが () から ! に変わる
標準ライブラリAllocator トレイトと Vec::new_in / Box::new_in などが安定化
標準ライブラリDropGuard、conjure_zst、bool::toggle、Box::map、str::trim_prefix など
Cargoglobal-min-publish-age で、公開から一定期間たっていないバージョンを避ける
Cargo未使用の依存を cargo::unused_dependencies として警告（既定で warn）
Cargoビルドディレクトリの構成を変更。キャッシュの衝突を減らす

never 型の安定化 — 「値を返さない」を型で書ける

何ができるようになったのか

never 型 ! は「この式は決して値を返さない」ことを表す型です。これまでも fn exit() -> ! のような戻り値の位置や、match の腕で return や panic!() を書いたときに、暗黙には使われていました。1.100 からは、任意の場所で型として書けます。

公式ブログの例では、Result<T, !> を受け取る関数を書いています。

fn infallible_unwrap<T>(res: Result<T, !>) -> T {
    let Ok(v) = res;
    v
}

エラー型が ! なので、Err は決して起こりません。そのためコンパイラは let Ok(v) = res; を網羅的なパターンとして受け入れます。unwrap() も match の Err 腕も要りません。

これまで同じ目的には std::convert::Infallible という空の enum が使われてきました。1.100 では Infallible が ! の別名になったので、Infallible を使って書かれた既存の API もそのまま ! と組み合わせられます。TryFrom の失敗しない実装などで、エラー型を意味のある形で書けるようになります。

既存コードが壊れる可能性 — フォールバックの変更

注意が必要なのは、2024 より前のエディションでも never 型のフォールバックが変わった点です。

フォールバックとは、型推論で決まらなかった発散式（return や panic!() など）の型を何にするかという規則です。これまでは () に、エディション 2024 では ! に倒していました。1.100 では 2015/2018/2021 のエディションもエディション 2024 と同じ ! に揃います。

公式ブログによると、影響はほとんど目に見えません。ただし、まれなケースとして型パラメータを返す関数の戻り値を捨てているコードが挙げられています。たとえば fn make<T: Default>() -> Result<T, E> のような関数を make()?; と呼び、結果の型をどこにも書いていない場合です。これまでは T が () に決まって通っていましたが、! になると !: Default を満たさずエラーになります（この例は筆者による説明用のもの）。また、到達不能と判定されるコードが増え、警告が出ることもあります。

このための将来互換性の警告は以前から出ていて、影響を受けるクレートには修正版が公開済みです。アップデートで依存クレートのビルドが通らなくなったら、まずそのクレートを更新してみるのが公式の推奨です。

標準ライブラリ — アロケータと DropGuard

Allocator API

allocator_api の中核部分が安定しました。中心は Allocator トレイトで、Vec::new_in や Box::new_in のように、コンテナごとにアロケータを指定できます。現時点で対応しているのは Vec と Box です。公式ブログはこれを Allocators 1.0 というプロジェクト目標の土台と位置づけ、今後も拡張するとしています。

アリーナアロケータで短命なオブジェクトをまとめて確保・解放したい場面や、組み込み・ゲームのようにメモリの使い方を細かく制御したい場面で、nightly に頼らずに書けるようになります。

DropGuard

core::mem::DropGuard は、スコープを抜けるときにクロージャを実行する型です。公式ブログでは、文字列をすべて数値に変換して Vec に追加し、途中で失敗したら追加分を巻き戻す例が紹介されています。

let len = nums.len();
let mut nums = DropGuard::new(nums, move |nums| {
    nums.truncate(len); // 失敗時に元の長さへ戻す
});
for s in strings {
    nums.push(s.parse()?); // ? でエラーが返ると巻き戻る
}
DropGuard::dismiss(nums); // 成功したらガードを解除

? による早期リターンでも巻き戻しが確実に走るのが利点です。HN では Go の defer と比べる声がありました。違いは、成功時に dismiss で取り消せる点です。なお dismiss がメソッドではなく関連関数になっているのは、DerefMut 経由で中身のメソッドを呼ぶときに名前が衝突しないようにするためです。

Cargo — 依存のクールダウンと未使用依存の警告

min-publish-age

実務への影響が最も大きいのはこの機能です。.cargo/config.toml に次のように書くと、公開から3日たっていないバージョンを依存解決で選ばなくなります。

[registry]
global-min-publish-age = "3 days"

cargo update を実行すると、「新しい版があるが公開から日が浅いので見送った」ことが表示されます。急ぎで新しい版が必要なときは、CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow を付けて --precise で個別に上げられます。上げた版は Cargo.lock に記録され、次に依存を解決し直すまで維持されます。

狙いはサプライチェーン攻撃への対策です。乗っ取られたアカウントから悪意のある版が公開されても、多くの場合は数時間〜数日で発見され、取り下げられます。その間に取り込まないようにするのがクールダウンの考え方です。

ただし公式ブログは、これで完全には防げないと明言しています。注意点は次の3つです。

  • レジストリのインデックスに公開日時（pubtime）が記録されていない版は、見送りの対象にならない
  • cargo install は設定を無視する。バージョンを固定したいなら cargo install foo@1.2.3 のように指定する
  • 脆弱性の修正版も、同じように3日間は入ってこない

3つ目について HN では、「通常の更新は寝かせ、セキュリティアドバイザリが出た修正だけはすぐ入れるべき」という意見が出ていました。設定するなら、アドバイザリを監視して個別に上げる運用（cargo audit など）とセットにするのが現実的です。

未使用依存の警告

Cargo が未使用の依存を警告するようになりました。これまで rustc の unused_crate_dependencies は、ビルド対象（lib / bin / test など）の間で依存を共有する Cargo の構成では誤検知が多く、実質的に cargo-udeps や cargo-machete のような外部ツールに頼っていました。HN では、Cargo チームの epage 氏が、この機能は cargo-udeps のメンテナの仕事を土台にしていると書き、外部ツールを置き換えられるかという質問に「おそらく」と答えています。

制限もあります。警告が出るのは、その依存を使う可能性のあるビルド対象をすべてビルドしたときだけです。cargo check --bin foo のように一部だけビルドしても警告は出ません。dev-dependencies の未使用も検出されません。

設定は Cargo.toml の [lints.cargo] で行います。CI で失敗扱いにしたいなら、ここで unused_dependencies を deny にできます。

エンジニアへの影響 — アップデート時の確認順

  1. ビルドが通るか確認する: never 型のフォールバック変更で依存クレートが壊れたら、まず依存を更新する。自分のコードで壊れたら、推論に任せていた型を明示する
  2. ビルドスクリプトや CI を確認する: build-dir の構成が変わり、ハッシュがファイル名から親ディレクトリに移った。target/ 配下のパスを決め打ちしているスクリプトやテストは壊れる可能性がある
  3. min-publish-age を検討する: チームで設定するなら、リポジトリの .cargo/config.toml に置いて全員と CI に効かせる。脆弱性対応の手順も同時に決めておく
  4. 未使用依存を掃除する: 警告に従って消すだけでビルド時間と依存の攻撃面が減る。HN では、Claude に 1.100 へ上げさせたら警告を見て未使用依存をまとめて消してくれた、という報告もあった

min-publish-age と未使用依存の警告は、どちらも「依存を減らし、取り込む版を慎重に選ぶ」ための機能です。npm や PyPI でサプライチェーン攻撃が続いている中で、Rust はそれをパッケージマネージャ本体に組み込んだ形になります。

まとめ

  • Rust 1.100.0 が2026年11月12日にリリースされた
  • never 型 ! が安定化し、Result<T, !> のように型として書けるようになった。2024 より前のエディションでもフォールバックが ! に変わるため、まれに既存コードが壊れる
  • Allocator トレイトと DropGuard が安定化し、nightly なしでアロケータの指定や確実な後始末を書ける
  • Cargo に、公開直後のバージョンを避ける global-min-publish-age と、未使用依存の警告が入った

公式ブログによると、crates.io では今後、疑わしい版の隔離や自動検出も進める計画です。クールダウンはその第一歩なので、今のうちに設定と脆弱性対応の運用を決めておくと、次の機能が来たときにも乗りやすくなります。

ソース

Back to articles