Rust 1.100 Ships: Never Type Stable After 10 Years

Rust 1.100.0 shipped on November 12, 2026, and it closes one of the longest-running stories in the language: the never type, written !, is finally stable after about ten years and five failed stabilization attempts. The release also stabilizes the core of the custom allocator API, and Cargo gains two supply-chain features that matter for anyone shipping Rust in production.

This is the language's 100th stable release, and it is more than a round number. The never type change can break a small amount of existing code, so the upgrade deserves a read of the compatibility notes before you run it in CI. This guide explains what shipped, what the never type actually does, what can break, and how to upgrade safely.

What Is the Never Type?

The never type, spelled ! in code, is the type of a computation that never produces a value. A function that always panics, an endless loop, and a call to std::process::exit all have the never type, because they never return a value to their caller.

Before Rust 1.100, you could use ! only in a few positions, such as the return type of a diverging function. Writing it anywhere else — in a generic type, in a struct field, in a type alias — produced an experimental-feature error. That limitation is now gone: the never type can appear anywhere a type can go.

The practical payoff is in generic code. You can now write Result<T, !>, and the type system understands exactly what that means: a function returning Result<T, !> cannot fail, because its error type has no possible value. The compiler can use that fact to simplify your code and to catch mistakes, such as an error branch that can never run.

The release also turns Infallible into a type alias for !. Code that used std::convert::Infallible keeps working, but new code should prefer ! directly. The alias exists so the standard library can say what it always meant: an infallible operation is one whose error type is the never type.

Why It Took Ten Years

The never type has been tracked in the Rust repository since 2016, in issue #35121. Five stabilization attempts failed along the way, and the official announcement puts it plainly: "After 10 years and 5 failed stabilization attempts, the never type is finally stable."

The difficulty was never the type itself. It was the fallback: when the compiler cannot work out the type of an expression tied to a computation that never returns, it has to pick something. For years, editions 2015, 2018, and 2021 picked (), the unit type, while edition 2024 picked !. Unifying that behaviour across editions without breaking the ecosystem took the better part of a decade.

The 1.100 release finally makes the call. The never type fallback is now ! on all editions, and the project goal behind the work is marked complete. Ten years is a long time for one type, but the care is the point: Rust's stability guarantees mean a change like this has to be right, because millions of lines of code depend on it.

What Can Break: The Never Type Fallback Change

The breaking change in Rust 1.100 is the never type fallback. In editions before 2024, the compiler used to infer () for an unconstrained never-type expression. Now it infers !, matching what edition 2024 already did. The release notes expect the change to go largely unnoticed, and for most crates it will.

But a small amount of code relied on the old fallback, and that code can now fail to compile — or worse, compile and then abort at runtime. The pattern to watch for is a type that gets its concrete type from a Default implementation or a similar bound: with ! inferred instead of (), the program can hit a code path that was never meant to run.

Two patterns behaved differently in testing with small edition 2021 crates compiled under 1.99 and 1.100. The first involves a generic function whose type parameter is inferred from a never-typed expression and then defaulted. The second involves trait methods resolved on an adjusted never type. Both are edge cases, but they are the reason the release notes carry a compatibility warning.

Before you upgrade, check the never type fallback chapter of the Rust Edition Guide, which explains the change and the cases it affects. Then upgrade in a branch, run your full test suite, and read any new errors as information rather than noise: a compile error here is the compiler telling you about an assumption your code was quietly making.

Custom Allocators Are Stable

The second headline feature is the stabilization of the core Allocator API. Library authors can now define custom allocators, and Vec and Box accept them through allocator-aware methods such as Vec::new_in and Box::new_in. The Allocator trait itself is stable, along with the Global and System allocators.

For most developers, this changes nothing today. Custom allocators matter to a specific audience: game engines, embedded systems, databases, and high-performance servers that need control over where memory comes from. If that is not your world, you can safely ignore this feature and let your dependencies use it when they are ready.

For library authors, the important detail is scope: only Vec and Box are covered for now. Other collections are still to come, and some Box implementations were generalized to arbitrary allocators, which may cause new type errors in code that relied on the old signatures. Read the compatibility notes in the 1.100.0 release notes before you adopt the API.

Cargo Cooldowns: A Supply-Chain Upgrade

The most immediately useful change for teams may be in Cargo, not the language. Rust 1.100 adds dependency cooldowns: set registry.global-min-publish-age and the resolver skips crate versions published too recently, unless they are already pinned in your Cargo.lock.

The idea is simple and aimed at a real attack. Supply-chain attacks often work by publishing a malicious version of a popular crate and hoping projects pick it up before anyone notices. A cooldown gives the ecosystem time to spot a bad release: your build simply will not take a version younger than the age you set.

Cargo also gains warnings for unused dependencies, and configurable Cargo lints, including an unused-dependency check. These are small quality-of-life improvements, but they compound: a dependency list that only contains what you actually use is easier to audit, and an audit is the other half of supply-chain defence.

This is the same month that delivered a PostgreSQL security update fixing 52 flaws and an Apache HTTP Server RCE with a CVSS score of 9.8. November 2026 has been a busy month for security teams, and Cargo cooldowns are the kind of quiet, structural fix that prevents the next incident rather than responding to one.

Rust 1.100 vs 1.99: What Actually Changed

The headline items are the never type, the allocator API, and the Cargo changes, but the release carries more. Here is the short version of what shipped, and who needs to act on each item.

The release also stabilizes compiler profile sample use and a broad set of standard-library APIs. The full list is in the official announcement of Rust 1.100.0 on the Rust blog, which is the authoritative source for this release.

How to Upgrade to Rust 1.100

If you have a previous version installed via rustup, the upgrade is one command:

$ rustup update stable

That pulls 1.100.0 and makes it your default toolchain. If you pin a toolchain per project with a rust-toolchain.toml file, update the channel there instead, and let CI pick it up from the file.

Upgrade in a branch first, not on your main line. Run your full test suite, including integration tests and doctests, and read the new errors carefully. A compile error after this upgrade is usually the fallback change surfacing an assumption, and fixing it means making the type explicit — which is better code anyway.

After the tests pass, consider the Cargo cooldown. Add a global-min-publish-age to your Cargo configuration and pick an age that fits your risk tolerance: a few days is enough to let the ecosystem spot a bad release, and a week is reasonable for production services. Existing entries in Cargo.lock are unaffected, so the cooldown only governs new versions.

If you inspect your dependency tree with cargo metadata, the output is JSON. Paste it into the JSON Formatter to read it comfortably — it runs entirely in your browser, so your dependency list never leaves your machine.

Finally, run the new unused-dependency check and clean up what it finds. Fewer dependencies means a smaller audit surface, faster builds, and fewer surprises when a transitive dependency changes. It is a small job, and this release makes it easy.

Should You Upgrade Now?

Yes, with the usual care. Rust 1.100 is a stable release, and the previous version, 1.99, is no longer supported. Staying behind means missing security fixes as well as features, and the upgrade path here is a minor version bump, not an edition migration.

The one reason to pause is a large, older-edition codebase with heavy generic code. If that describes your project, upgrade in a branch, run the suite, and budget an hour for fallback-related errors. Most projects will see none, but the ones that do will be glad the compiler caught the assumption instead of shipping it.

For new projects, there is no reason to start on anything older. Rust 1.100 gives you the never type, the allocator API, and the Cargo supply-chain features from day one, and the edition 2024 default already uses the new fallback. Start here.

Frequently Asked Questions

What is new in Rust 1.100?

Rust 1.100.0, released November 12, 2026, stabilizes the never type after ten years, stabilizes the core custom allocator API for Vec and Box, and adds Cargo dependency cooldowns plus unused-dependency warnings. It also adds bool::toggle and extern "custom", and changes the never type fallback to ! on all editions.

What is the never type in Rust?

The never type, written !, is the type of a computation that never produces a value, such as a function that always panics or an endless loop. In Rust 1.100 it can be used anywhere a type goes. A function returning Result<T, !> cannot fail, because its error type has no possible value.

Can Rust 1.100 break my code?

A small amount of code can break. The never type fallback changed from () to ! on editions 2015, 2018, and 2021, and code that relied on the old fallback can fail to compile or, in rare cases, compile and abort at runtime. Upgrade in a branch, run your full test suite, and check the compatibility notes in the release notes before deploying.

How do I upgrade to Rust 1.100?

Run rustup update stable to install 1.100.0 as your default toolchain. If you pin a toolchain with rust-toolchain.toml, update the channel in that file. Upgrade in a branch first, run your full test suite, and only then merge.

What are Cargo dependency cooldowns?

Dependency cooldowns let you tell Cargo to skip crate versions published too recently. Set registry.global-min-publish-age in your Cargo configuration, and the resolver will not pick a version younger than that age unless it is already pinned in Cargo.lock. It gives the ecosystem time to spot a malicious release before your build takes it.

Is Rust the best language for systems programming in 2026?

It depends on what you are building. Rust is the strongest choice when you need memory safety without a garbage collector, predictable performance, and a package ecosystem with supply-chain features like Cargo cooldowns. C and C++ still win for the smallest embedded targets and for existing codebases, and Go is simpler for network services where a garbage collector is acceptable. Pick the language for the constraints of the project, not for the headline.