Rust 1.100: Never Type Stable and Cargo Dependency Cooldowns, What to Check

Updated November 13, 2026. A news analysis built from the Rust Release Team’s announcement “Announcing Rust 1.100.0” (November 12, 2026) on the official Rust blog, our own screenshots of that page, and the Hacker News front page. We did not install Rust 1.100 and did not compile or run any code for this article; everything below describes what the announcement says. Numbers we compute are labelled as ours. This is not engineering or security consulting; test the release on your own code.

The short version

Rust 1.100.0 was announced on November 12, 2026. You update with rustup update stable. The release stabilizes several long-awaited features, and two of them matter beyond the Rust community. First, the never type, written !, which the announcement says is “finally stable” after “10 years and 5 failed stabilization attempts”. Second, Cargo’s “min-publish-age” setting, also called dependency cooldowns: a way to tell Cargo not to pick up a package version until it has been public for a chosen time, such as three days, on the theory that malicious releases are usually caught quickly.

The cooldown feature is the story for readers who do not write Rust. Supply-chain attacks, where a trusted package is replaced with a bad one, are a problem for every language ecosystem, and our recent note on GitHub Actions lockfiles quoted the same advice: use cooldowns. Rust now has that built into its package manager. The announcement is honest about the limits, and so are we.

Timeline

• November 12, 2026: the Rust Release Team publishes the 1.100.0 announcement. The post is on the Hacker News front page the same day; it showed 476 points when we last checked.
• Before this release: the never type had gone through “5 failed stabilization attempts” over 10 years, according to the announcement. Cargo’s build directory layout work began with a 2025 project goal.
• Today: the announcement says future crates.io supply-chain work is planned, including quarantine support and automated detection of suspicious releases.

What the announcement says

The “What’s in 1.100.0 stable” list has seven headline items: the never type, the allocator API, DropGuard, conjuring zero-sized types, reporting unused dependencies in Cargo, reducing Cargo cache collisions, and Cargo min-publish-age. We take them in the order that matters for a team deciding whether to upgrade.

The never type

The never type ! is the type of computations that never produce a value, such as return, break and std::process::exit. Rust already allowed you to use it in a limited way. This release allows naming it anywhere, so you can write Result<T, !>, and it changes Infallible to be an alias for ! so that older APIs stay compatible.

The price is one breaking change. The announcement says the “never type fallback” changes from () to ! in editions before 2024, meaning 2015, 2018 and 2021, as it already did in edition 2024. It says this “should largely be unnoticeable” but can affect code in rare cases, for example when ignoring a result of a function that returns a generic parameter, and that the compiler may detect more code as unreachable. The team says it gave future-compatibility warnings far in advance and released fixes to public crates. If a dependency fails because of the never type, the advice is to update it.

Allocator API, DropGuard and zero-sized types

The core parts of the allocator API are stable, including the Allocator trait, which lets library authors use custom allocators with Vec and Box. The announcement calls this the foundation of the Allocators 1.0 project goal and says a lot remains to be done. core::mem::DropGuard runs a closure when a value is dropped and has a dismiss method, which makes all-or-nothing, roll-back style code shorter; the post shows a parser that restores a vector if any string fails to parse. std::mem::conjure_zst is an unsafe function that gives a dedicated way to create a zero-sized value, in place of tricks such as transmuting ().

Two Cargo changes that can affect your builds

Cargo now reports unused dependencies with a cargo::unused_dependencies lint set to warn by default, as part of a new [lints.cargo] system. The announcement lists limits: the warning appears only when building every target that might use a dependency, so cargo check --bin foo may not show it, and no warning is shown for unused dev-dependencies.

The build directory also changes. Cargo now applies the build-configuration hash consistently by organizing directories around the build step and moving the hash to the parent directory. The post says this is an internal change but “may break build processes and tests that had workarounds”, points to cargo issue 17287 for solutions, and says the change helps when a build directory is shared across git worktrees.

Dependency cooldowns in detail

The announcement’s reasoning is short: malicious versions of packages are often caught within hours or days of publication, by automated scanners or the community, so waiting reduces the chance of picking one up. You opt in with a registry setting in .cargo/config.toml, and Cargo then skips any version published more recently than that and tells you what it held back.

When a new version is needed right away, the post shows an environment variable override, CARGO_RESOLVER_INCOMPATIBLE_PUBLISH_AGE=allow, used with cargo update clap --precise 4.6.9; the newer version is then recorded in Cargo.lock. It lists four caveats worth repeating:

• It depends on the registry recording when each version was published. Versions without a pubtime field in the index are never held back.
• cargo install ignores the minimum publish age, for the installed crate and its dependencies. The post suggests pinning a version, such as cargo install foo@1.2.3.
• Cooldowns “reduce the risk from some supply chain attacks but are not a complete defense on their own”, and you should keep reviewing dependency updates.
• Further crates.io hardening is planned, including quarantine support and automated detection of suspicious releases.

Our own arithmetic (labelled as ours)

These figures are our own calculations from numbers in the announcement.

The point of the first three rows is that a cooldown is a trade: you accept a delay of up to three days on every new release in exchange for a chance that someone else finds a bad one first. The example shows that a security fix published two days ago would also be held back unless you use the override, so teams that want cooldowns need a plan for urgent fixes.

Claimed versus what we could verify

Who is actually affected

Teams that build Rust software and update their toolchain are affected right away. The never-type fallback change and the build-directory change are the two items that can alter existing builds, so they matter most to teams with older editions, custom build scripts or shared build directories. Projects with many dependencies may care most about the cooldown, because every automated update tool that resolves versions through Cargo can be told to wait. Readers who use other languages are affected indirectly: the announcement shows a concrete way to apply the cooldown idea that package managers elsewhere are also discussing.

Our recent note on a free embroidery tool written in Rust, ZigZag, is a reminder of how many small tools depend on this ecosystem. We have not checked whether that project or any other uses these new features.

Why this one is getting attention

Two reasons are visible on the page. A feature that took 10 years and several attempts is the kind of milestone language communities talk about. And the cooldown section answers a worry many developers have had since high-profile package compromises: how to slow down without stopping updates. The announcement treats it carefully, with an override, a list of caveats and a pointer to future work.

Checklist for Rust teams

1. Update on a branch first with rustup update stable, build everything and run your tests.
2. If you use edition 2015, 2018 or 2021, look for new compiler warnings or errors about never-type fallback, and update any dependency the compiler points to.
3. Check scripts, tests and CI steps that depend on paths inside the build directory. The announcement says workarounds may break and points to cargo issue 17287.
4. Read the new unused-dependency warnings, and remember they appear only when all targets that could use a dependency are built.
5. Decide whether to use a cooldown and for how long. The announcement’s example is three days; the right value depends on how fast you need security fixes.
6. Write down how you will bypass the cooldown for an urgent fix, using the override the post shows, and who may do it.
7. Pin exact versions when you run cargo install in scripts, because that command ignores the cooldown.
8. Do not stop reviewing dependency changes. The Rust team says cooldowns are not a complete defense.
9. If you publish crates, remember that registries must record publish times for the cooldown to apply to your versions.

What to watch next

• Reports from teams that adopt cooldowns, including how often an urgent fix has to bypass them.
• The crates.io supply-chain hardening work the announcement mentions, especially quarantine support.
• Follow-up releases that stabilize allocator support on more collections and pointer types, which the post says is expected.
• Issue reports on the build-directory change.

Frequently asked questions

How do I get Rust 1.100

The announcement says to run rustup update stable if you installed with rustup, and links to rustup for new installs. It also suggests testing beta or nightly if you want to help check future releases.

What is a dependency cooldown

A setting that makes the package manager ignore versions published more recently than a chosen age. In Cargo it is the min-publish-age setting, and the announcement’s example is three days.

Will the cooldown stop a supply-chain attack

Not on its own. The Rust team says it reduces the risk from some attacks and is not a complete defense, and that you should keep reviewing updates.

Does the never type break my code

The team says the breaking change should largely be unnoticeable and gave warnings in advance, but it can affect code in rare cases, mainly in editions before 2024. Build on a branch and update any dependency that fails.

Why does the build directory change matter

It is meant to avoid extra rebuilds and confusion when different configurations share a directory, and it prepares for future cache improvements. It can break scripts or tests that relied on the old layout.

Does it apply outside Rust

The announcement covers Cargo and crates.io. We mention other ecosystems only because the cooldown idea is the same; we did not check their tools.

Sources and method

• The Rust Release Team, “Announcing Rust 1.100.0”, blog.rust-lang.org, November 12, 2026. Read November 13, 2026.
• Hacker News front page, November 13, 2026, for discussion context.

Method: we opened the announcement in a clean browser window, read it in full, counted the entries in its “Stabilized APIs” list, and captured the three screenshots above. We quote only short phrases. We did not install Rust 1.100, run Cargo or test any build. Arithmetic rows are our own.

Risk note

This is a summary of a public announcement that can change after we read it. We have not tested the release, and we make no promise that your builds will work or that any setting will protect you from an attack. Nothing here is security, legal or professional advice. Read the official release notes and test on your own code before you change a production build.