株式会社オブライト

Rust 1.100 リリース — never型の安定化・Allocator API・Cargoの新機能と移行手順

2026/11/14に公開約13分で読めます

2026年11月12日公開の Rust 1.100.0 を公式ブログで整理。never型 ! の安定化と edition 2021 以前の fallback 変更、Allocator API、DropGuard、Cargo の未使用依存警告と min-publish-age、更新手順とチェックリストを解説する。

Rust 1.100.0 は、Rust リリースチームが2026年11月12日に公開した Rust の安定版リリースです。目玉は、約10年越しで安定化された never 型 ! と、Vec / Box で使えるようになった Allocator トレイト、そして Cargo の未使用依存の警告と依存のクールダウン設定です。

3行要点

- Rust 1.100.0 は2026年11月12日に公開。rustup update stable で更新でき、never 型 ! と Allocator API の中核が安定化された
- 破壊的変更: edition 2015 / 2018 / 2021 では never type fallback が () から ! に変わる（edition 2024 は既に変更済み）。依存クレートの更新が必要になる場合がある
- Cargo は未使用依存の警告（[lints.cargo] の unused_dependencies）と、公開から一定期間たっていないバージョンを避ける global-min-publish-age を追加

Rust 1.100.0 とは

Rust 1.100.0 は、公式ブログ「Announcing Rust 1.100.0」（2026年11月12日付）で告知された安定版です。既存のユーザーは rustup update stable で更新できます。言語機能・標準ライブラリ・Cargo の3領域にまたがる変更が入っており、とくに言語側の never 型の安定化は、公式が「約10年・5回の安定化の試みの失敗を経た」と説明する長い懸案でした。

この記事は公式ブログに書かれている内容だけを整理しています。詳細な変更一覧は、公式が示す Rust・Cargo・Clippy それぞれの変更履歴を確認してください。

主な変更点の一覧

領域	変更	影響
言語	never 型 `!` の安定化、`Infallible` を `!` のエイリアスに	`Result<T, !>` のように明示的に書けるようになる
言語（破壊的）	edition 2015/2018/2021 の never type fallback が `()` から `!` に	既存コードがコンパイルエラーになる場合がある
標準ライブラリ	`Allocator` トレイトなど `allocator_api` の中核を安定化	`Vec` / `Box` で独自アロケーターが使える
標準ライブラリ	`core::mem::DropGuard`	終了経路を問わずクロージャーを実行できる
標準ライブラリ	`std::mem::conjure_zst`	ゼロサイズ型の値を作る推奨の unsafe な方法
Cargo	未使用依存の警告	`[lints.cargo]` で制御、既定は warn
Cargo	`build-dir` のキャッシュ衝突の低減	ビルド手順の回避策が壊れる場合がある
Cargo	`global-min-publish-age`	公開から日が浅いバージョンを選ばない

never 型 `!` の安定化

never 型は、値を決して生成しない計算の型で、! と書きます。これまでも match の腕が return で終わる場合や関数の戻り値型としては暗黙に使えましたが、Result<T, !> のような他の位置には書けませんでした。1.100.0 で、! をどこにでも書けるようになります。公式ブログの例を示します。

fn mrrrow(option: Option<u32>) {
    let value = match option {
        // `x` has type `u32`
        Some(x) => x,
        // `return` has type `!`, which is then coerced to `u32`,
        // allowing the `match` to pass type checking.
        None => return,
    };
    // ...
}

上の例では、return の型 ! が u32 に型強制され、match の型検査が通ります。次の例は、これまで書けなかった Result<_, !> です。失敗しないことを型で表した Result から、パターンマッチだけで値を取り出せます。

fn infallible_unwrap<T>(res: Result<T, !>) -> T {
    // ^^ writing `Result<_, !>` was not allowed before
    let Ok(v) = res;
    v
}

同時に、Infallible が ! のエイリアスになります。公式は、Infallible を使っていた既存の API が ! でもそのまま動くようになる、と説明しています。標準ライブラリでは impl AsRef<T> for ! と impl AsMut<T> for ! も安定化APIに含まれています。

never type fallback の変更と既存コードへの影響

今回の唯一の破壊的変更です。公式によれば、edition 2015・2018・2021 で、never type fallback が () から ! に変わります。edition 2024 では既にこの変更が入っているため、edition 2024 以降のコードは挙動が変わりません。

影響を受けうるのは、ジェネリックな結果を無視しているコードです。また、コンパイラーが到達不能なコードをより多く報告するようになる場合もあります。公式は、この変更について事前に future-compatibility 警告を出していたと述べています。具体的な lint 名や cargo fix での自動修正手順は、公式ブログには書かれていません。

公式が示す対処は、この変更でビルドが失敗する依存クレートを更新することです。多くのクレートで修正版が公開済みとされています。次の流れで確認すると安全です。

1. 更新前に、現在のツールチェーンで警告が出ていないかを cargo check で確認する
2. rustup update stable で 1.100.0 に上げ、cargo check と cargo test を実行する
3. 失敗した場合、エラーに出てくる依存クレートを cargo update -p <クレート名> などで更新する
4. 自分のコードで失敗した場合は、() に頼っていた箇所に型を明示する

手順3・4は公式ブログに書かれた手順ではなく、公式の対処方針（依存の更新）を一般的なコマンドに落とした例です。

Allocator API の安定化

allocator_api の中核が安定化され、Allocator トレイトが標準で使えるようになりました。現時点で独自アロケーターを使えるのは Vec と Box です。公式はこれを「Allocators 1.0」というプロジェクトゴールの土台と位置づけ、対応するコレクションやポインター型、API の範囲は今後広げていくと述べています。

安定化されたAPIには、次のものが含まれます。

- トレイトと型: std::alloc::Allocator、std::alloc::Global、std::alloc::System
- Allocator の実装: Global、System、&A、&mut A、Box<T, A>、Rc<T, A>、Arc<T, A>
- Box: new_in、from_raw_in、from_non_null_in、into_raw_with_allocator、into_non_null_with_allocator、allocator
- Vec: new_in、with_capacity_in、from_raw_parts_in、from_parts_in、into_raw_parts_with_allocator、into_parts_with_allocator、allocator

アリーナ（まとめて確保・まとめて解放する方式）やメモリ使用量の計測など、用途別のアロケーターを標準の Vec / Box と組み合わせたい場面で役立ちます。ただし公式ブログには具体的な利用例のコードは載っていないため、ここでは API 名の紹介にとどめます。

DropGuard: どの終了経路でもクロージャーを実行

core::mem::DropGuard は、ドロップされたときにクロージャーを実行する新しいヘルパーです。値を包み、Deref と DerefMut を実装しているので、ガード越しに中の値を使い続けられます。ガードがドロップされるとクロージャーが実行され、値は消費されます。DropGuard::dismiss を呼ぶと、クロージャーを実行せずに値を取り出せます。dismiss がメソッドではなく関連関数なのは、中の型のメソッドと名前が衝突しないようにするため、と公式は説明しています。公式の例は、パースに失敗したら Vec を元の長さに戻す処理です。

use std::mem::DropGuard;
use std::num::ParseIntError;

/// Attempt to parse all `strings` and push them into `nums`.
/// If parsing any of them fails, `nums` remains unchanged.
fn parse_all(nums: &mut Vec<u32>, strings: &[&str]) -> Result<(), ParseIntError> {
    let len = nums.len();
    let mut nums = DropGuard::new(nums, move |nums| {
        nums.truncate(len);    // 1. Reset the vec on failure
    });
    for s in strings {
        nums.push(s.parse()?); // 2. If `?` returns an error, roll back
    }
    DropGuard::dismiss(nums);  // 3. Parsing successful, dismiss the guard
    Ok(())
}

? で早期リターンしても、パニックしても、ガードがドロップされた時点でロールバックが走ります。成功時だけ dismiss でガードを解除する、という書き方ができます。

conjure_zst: ゼロサイズ型の値を作る

std::mem::conjure_zst は、ゼロサイズ型の値を作るための unsafe な関数で、公式が推奨する方法です。これまでの () の transmute や MaybeUninit を使った回避策の代わりになります。unsafe なのは、型を作れないことを安全性の根拠にしている API があるためです。公式は PyO3 の Python<'py>（Python の GIL を保持していることを表すトークン）を例に挙げ、自由に作れてしまうと安全なコードから GIL の要件を回避できてしまう、と説明しています。

Cargo: 未使用依存の警告

Cargo が未使用の依存関係を警告するようになりました。[lints.cargo] の仕組みで制御し、lint 名は unused_dependencies、既定は warn です。公式の出力例は次のとおりです。

warning: unused dependency `tracing-subscriber`
  --> Cargo.toml:23:1
   |
23 | tracing-subscriber.workspace = true
   | ^^^^^^^^^^^^^^^^^^
   |
   = note: `cargo::unused_dependencies` is set to `warn` by default
help: consider removing the dependency on `tracing-subscriber`

公式が挙げる制限は2点です。1つ目は、その依存を使いうるすべてのビルドターゲットをビルドしたときだけ警告が出ることです。たとえば cargo check --bin foo では、別の bin が使っているかもしれないため [dependencies] の未使用警告は出ません。2つ目は、dev-dependencies の未使用は警告されないことです。開発用のビルドターゲットすべてがビルドされたと保証する方法がないためです。

Cargo: build-dir のキャッシュ衝突の低減

build-dir で、ビルド設定のハッシュが一貫して適用されるようになりました。ディレクトリはファイル種別ではなくビルド手順ごとに整理され、ハッシュはファイル名から親ディレクトリに移りました。これにより、余計な再ビルドと、再ビルドされるべきものが再ビルドされない問題が減ります。

ただし、以前の挙動を前提にした回避策を使っているビルド手順やテストは壊れる可能性があります。回避策が不要になる場合もあります。公式は、解決策や新しい使い方の議論先として cargo#17287 を案内しています。CI がビルド成果物のパスを直接参照している場合は、更新後に確認してください。

Cargo: min-publish-age（依存のクールダウン）

global-min-publish-age は、公開から一定期間たっていないバージョンを Cargo が選ばないようにする設定で、Rust 1.100 で安定化されました。悪意あるバージョンが公開された直後に取り込んでしまうリスクを下げる、いわゆる依存のクールダウンです。設定は .cargo/config.toml に書きます。

# .cargo/config.toml
[registry]
global-min-publish-age = "3 days"

この設定で cargo update を実行すると、期間を満たさない新しいバージョンは見送られます。公式の出力例です。

$ cargo update
    Updating crates.io index
     Locking 2 packages to highest compatible version as of min-publish-age
      Adding cc v1.11.0 (available: v1.18.0, published 3 hours ago)
      Adding clap 4.6.7 (available: 4.6.9, published 2 days ago)

一時的に最新を取り込みたいときは、環境変数 CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow で1回の更新だけ制限を外せます。

$ CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow cargo update clap --precise 4.6.9
    Updating crates.io index
    Updating clap 4.6.7 -> clap 4.6.9 (published 2 days ago, minimum age 3 days)

注意点が3つあります。第一に、この機能はレジストリが各バージョンの公開時刻を記録していることに依存します。インデックスに pubtime フィールドがないバージョンは、保留されません。第二に、cargo install は、インストール対象のクレートと依存の両方で最小公開期間を無視します。回避するには cargo install foo@1.2.3 のようにバージョンを固定します。第三に、クールダウンはサプライチェーンのリスクを一部減らすだけで完全な防御ではないため、依存更新のレビューは引き続き必要です、と公式は述べています。

サプライチェーン対策としては、.NET 11 の SDK にも公開から一定時間たっていないパッケージを使わない設定があります。比較したい場合は .NET 11 リリースの解説も参考になります。

その他の標準ライブラリの安定化

公式の安定化API一覧（47件）には、上で触れたもの以外に次が含まれます。

- bool::toggle
- Box::take、Box::map、Rc::map、Arc::map
- str::trim_prefix / str::trim_suffix、スライスの [T]::trim_prefix / [T]::trim_suffix、Path::trim_prefix
- Vec::from_fn
- UnsafeCell::replace、UnsafeCell::as_ref_unchecked、UnsafeCell::as_mut_unchecked
- impl Default for std::sync::Once
- Child::main_thread_handle、os::windows::process::CommandExt::show_window
- Vec<T, A> や &[T] と Cow<'_, [U]> の PartialEq 実装

アップデート手順

rustup でツールチェーンを更新し、バージョンを確認します。

# 更新
rustup update stable

# 確認（1.100.0 と表示されること）
rustc --version
cargo --version

更新後は、プロジェクトで cargo check と cargo test を実行します。未使用依存の警告は、更新するだけで警告として出始めるため、CI で警告をエラー扱いにしている場合は、先に手元で確認しておくと安心です。

アップグレード時のチェックリスト

- 使っている edition を確認する（2021 以前は never type fallback の変更の対象）
- rustup update stable の後、cargo check と cargo test が通るか確認する
- 失敗した場合、エラーに出てくる依存クレートの更新版が公開されていないか確認する
- CI で警告をエラー扱い（-D warnings など）にしている場合、未使用依存の警告で落ちないか確認する
- Cargo.toml の [lints.cargo] で unused_dependencies の扱いを決める
- ビルド成果物のパスや build-dir に依存した CI・スクリプトがないか確認する
- クールダウンを使うなら、.cargo/config.toml に global-min-publish-age を設定し、緊急の更新用に環境変数の上書き手順を共有する
- cargo install で入れるツールは、バージョンを固定する運用にする

FAQ

Rust 1.100.0 はいつ公開されましたか？

公式ブログの日付は2026年11月12日です。既存のユーザーは rustup update stable で更新できます。

never type fallback の変更でコードは壊れますか？

edition 2015・2018・2021 では、fallback が () から ! に変わるため、ジェネリックな結果を無視しているコードなどが影響を受ける可能性があります。edition 2024 は既に変更済みで影響はありません。公式は、失敗する依存クレートを更新するよう案内しており、多くのクレートで修正版が公開済みとされています。

`Allocator` API はどのコレクションで使えますか？

公式ブログによれば、現時点でカスタムアロケーターが使えるのは Vec と Box です。他のコレクションやポインター型への対応と API の拡大は今後の予定とされています。

global-min-publish-age を設定しても `cargo install` で最新が入るのはなぜですか？

cargo install は、インストールするクレートと依存の両方で最小公開期間を無視する仕様です。cargo install foo@1.2.3 のようにバージョンを固定してください。また、インデックスに pubtime がないバージョンは保留されません。

未使用依存の警告が出ない場合があるのはなぜですか？

依存を使いうるすべてのビルドターゲットをビルドしたときだけ警告が出るためです。cargo check --bin foo のように一部だけをビルドした場合は出ません。また、dev-dependencies は対象外です。

株式会社オブライト

株式会社オブライトは、ソフトウェア開発、デジタルサイネージ、Web開発、ネットワークシステム、IoT/AR/VRなどの技術サービスを提供する東京のIT企業です。

この記事に関連する無料ツール（登録不要・その場で結果）

ミツモリシミュレーター6つの質問で開発費用の概算レンジと期間の目安がわかる

お気軽にご相談ください

お問い合わせ