Rust 1.100 ships never type, allocators and Cargo lints

The Rust project released Rust 1.100.0 on November 12, 2026. It makes the never type stable, opens the core of the custom allocator API, and teaches Cargo to warn about unused dependencies. The never type change is also a breaking change, and the release notes list it under "Compatibility Notes". Projects on any edition can now fail to build where they compiled before.

The Rust Blog announcement says the never type took 10 years and 5 failed attempts to reach stable. LWN.net led with the same three changes: the never type, the core of the Allocator API, and Cargo's unused-dependency report. Rust users update with rustup update stable.

What is new in Rust 1.100

The never type, written !, is the type of code that never finishes, such as a panic! or an endless loop. Until now it could only appear as a function's return type. Our guide to Rust's never type explains it in full, and our August story covered the pull request that made it stable.

The table below is built from the blog post, the release notes on GitHub and the Cargo changelog.

Change	What it does	Who notices
Never type !	Usable anywhere, as in Result<T, !>; Infallible becomes an alias for !	Code that leaned on the old fallback
Type fallback	An unknown type in a diverging branch now becomes !, not (), on all editions	Older crates that never moved to edition 2024
Allocator API	Allocator, Global, System, and Vec::new_in, Box::new_in and similar methods	Code that manages its own memory
cargo::unused_dependencies	Warns when a dependency in Cargo.toml is never used	Every Cargo project
Minimum publish age	Cargo can skip crate versions newer than a set age	Teams worried about supply-chain attacks
Build directory layout	Intermediate build files move	Scripts that read Cargo's target folder directly
i686-pc-windows-gnu	Now Tier 2 without host tools	32-bit Windows users

The 32-bit Windows change was announced in October, as our story on the i686 targets explains. The release also stabilizes smaller helpers, such as bool::toggle, Vec::from_fn and str::trim_prefix.

Tech AI Wire test: Rust 1.99.1 against 1.100.0

In a Tech AI Wire test on macOS 26.6.2, the same small projects ran in the official rust:1.99-slim and rust:1.100-slim Docker images. Both are Debian 13 on arm64. The images reported rustc 1.99.1 and rustc 1.100.0.

The first project used edition 2021 and this code:

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

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

Nothing tells the compiler what T is, so it falls back to a default type. Here is what each version did:

Code	Rust 1.99.1	Rust 1.100.0
As written	Error from the lint dependency_on_unit_never_type_fallback	Error E0277: "the trait bound !: Default is not satisfied"
With #![allow(dependency_on_unit_never_type_fallback)]	Builds and runs	Still error E0277; the lint "has been removed"
With make::<()>()?	Builds and runs	Builds and runs

The middle row is the trap. A crate that silenced the warning on 1.99 builds there, then fails on 1.100. Rust 1.100 says the lint was removed because "the code warned by this lint no longer compiles". Only naming the type fixes it.

The custom allocator test wrapped the global allocator to count requests. On 1.99.1 it failed with error E0658, "use of unstable library feature allocator_api". On 1.100.0 it ran on stable. A Vec of 1,000 numbers plus one Box made 10 allocation calls for 16,356 bytes.

Tech AI Wire test: Cargo's two new safety checks

A crate (a Rust package) listed itoa and memchr as dependencies but used only itoa. On 1.100, cargo build printed "warning: unused dependency memchr". Setting unused_dependencies = "deny" under [lints.cargo] turned it into an error, and the build stopped. A dev-dependency that was never used got no warning. Neither did cargo check --bin unused, which checks a single target. Both match exemptions the blog post lists. Rust 1.99.1 ignored the [lints.cargo] table with an "unused manifest key" warning.

The minimum publish age delays brand-new crate versions, which the blog post calls "dependency cooldowns". The wait gives others time to spot a bad release before your build pulls it in. With global-min-publish-age = "3 days" set under [registry], Cargo locked cc at 1.11.1. It printed "available: v1.11.2, published 2 hours ago". With the setting removed, Cargo picked 1.11.2. With 30 days, resolution failed, because cargo add had already written 1.11.1 as the minimum version. Cargo suggested lowering the requirement to "1.8.0" or setting CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow.

What this means for developers

• Build every crate on 1.100 before you upgrade CI. Older-edition code is the most likely to break. Search for allow(dependency_on_unit_never_type_fallback), because that code fails on 1.100.
• Fix fallback errors by naming the type. The compiler's own suggestion, such as make::<()>(), worked on both versions in the test.
• Turn on the publish age now. Three days of global-min-publish-age in .cargo/config.toml costs little. Set it before running cargo add, since that command writes the version it picks into Cargo.toml.
• Clean up unused dependencies before you deny them. Start at the default warn, remove what it finds, then switch to deny in CI.
• Read the Compatibility Notes. They also list removed box patterns, Unicode 18.0.0 and stricter ARM target-feature checks.
• Stop reading Cargo's build folders directly. Their layout changed in 1.100, and the Cargo changelog says tools should use Cargo's JSON messages instead.