Rust Enables Polonius Alpha Borrow Checker on Nightly, Targeting Stabilization by Year's End
Rust's next-generation borrow checker, Polonius Alpha, is now live on nightly for testing, with the project aiming to stabilize it before 2026 ends.
Overview
The Rust project has enabled Polonius Alpha, the next iteration of its borrow checker, on nightly builds for testing, according to the Rust Blog. The change, announced August 4, is a preview step ahead of a planned stabilization before the end of 2026, as InfoWorld also reported: “The Rust team has announced that it is enabling the Polonius Alpha borrow checker on nightly releases for testing. The team expects to fully stabilize Polonius Alpha later in the year.”
What We Know
The borrow checker is the part of the Rust compiler that enforces the language’s core memory-safety rules on references. Polonius is not a new project — it “spun out of the NLL effort in 2018,” according to the Rust Blog, referring to Non-Lexical Lifetimes, the borrow-checking model that replaced Rust’s original, more limited “AST borrowck” in 2019. That original Polonius formulation could accept sound code that NLL rejected, but it came with a catch: “performance was a critically-limiting factor; generally borrow check was slower than NLL, but certain programs were considerably slower than NLL to the extent that using that implementation/formulation of Polonius was a non-starter,” the Rust Blog said.
A breakthrough came in 2023. The Rust Blog explained that “a new formulation of a Polonius-style borrow checker was imagined that required minimal rearchitecture of the existing NLL implementation and could be extended to allow more code to compile.” InfoWorld independently confirmed the same origin story, reporting that “a new formulation of a the Polonius borrow checker was proposed that required a minimal re-architecture of the existing NLL (non-lexical lifetime) implementation and could be extended to allow more sound code to compile, according to Huey.” An initial 2024 stabilization target slipped, but the team now says the alpha subset is ready for wider exposure: “At this point, there are no known remaining issues with the subset coined Polonius Alpha that we intend to stabilize. And, performance is generally acceptable for stabilization,” the Rust Blog wrote.
The official tracking issue on GitHub, titled “Stabilize and model Polonius Alpha,” frames the remaining work as “fixing the remaining known soundness issue, expanding test coverage, building a formal model in a-mir-formality and upstreaming it into the Rust reference, validating performance, and preparing a stabilization report.” The issue is tagged as a “Flagship Goal” for the Rust project’s 2026 roadmap and is owned by the Rust “types” team. The corresponding goal document lists task owners Amanda Stjerna, Rémy Rakic, Niko Matsakis, and tiif, and names Rémy Rakic as point of contact and Jack Huey — the Rust Blog post’s author — as “types champion.” The goal document also spells out the one soundness gap still standing between alpha and stable: an issue “related to dead regions outlived by opaque types.”
Technically, the headline capability is flow-sensitive analysis. “The key thing that Polonius Alpha enables that NLL does not is flow-sensitive borrow checking of lifetime outlives relationships,” the Rust Blog said. The post’s canonical example is a get_mut_or_default function that looks up a key in a HashMap, returning the existing value if present or inserting and returning a default otherwise. Under current NLL, the compiler conservatively assumes the borrow returned by the initial lookup lives for the entire function, which blocks the later mutable access needed to insert a default — even though, as the Rust Blog put it, “that borrow isn’t live in the None branch.” Polonius Alpha’s flow-sensitive analysis recognizes this and accepts the pattern. The goal document separately notes that a similar case applies to lending iterators, where “the filtering lending iterator pattern, where next() reborrows self in a loop” is “code that NLLs incorrectly rejects today,” a limitation the tracking issue calls “the NLL problem case #3.”
Polonius Alpha is not a strict superset of the older, slower Polonius implementation. The Rust Blog acknowledged that “some programs that would compile under legacy Polonius (the slow original implementation) don’t compile with Polonius Alpha,” while also noting the reverse is true for some other programs — “it’s not really a full subset” in either direction.
On performance, the team tested the top 10,000 most-downloaded crates on crates.io and reported that “we have seen relatively few ‘significant’ regressions, and even crates that have a ‘significant’ regression are typically relatively minimal,” according to the Rust Blog. Outside that sample, focusing on crates with heavy borrow usage, “the worst case we’ve seen is a 2-3x regression,” the Rust Blog said. The project’s separate goal document sets an explicit tolerance for the rollout: “We are willing to accept a performance cost in the range of 10–20% for the benefits polonius provides. We are aware of worst-case scenarios that could be larger, but do not yet know whether these occur in practice — the preview period will help answer this.”
Developers who want to opt out can do so with the -Zpolonius=off flag, matching syntax confirmed by both the Rust Blog and InfoWorld: passing the flag directly to rustc, setting RUSTFLAGS=-Zpolonius=off, or adding rustflags = ["-Zpolonius=off"] under a target in .cargo/config.toml. The Rust Blog asked that anyone who opts out explain why, via GitHub or Zulip, the same channels used to collect bug reports during the preview period.
What We Don’t Know
The Rust Blog post does not give a specific calendar date for stabilization beyond “prior to the end of the year,” and the project has not published a fixed date for when Polonius Alpha will land on stable or beta channels. Neither the Rust Blog nor the tracking issue commits to further Polonius feature work after this stabilization; the Rust Blog said only that “we don’t currently have any concrete plans to continue active feature work on the Polonius implementation after the stabilization of Polonius Alpha,” beyond continued optimization and addressing performance regressions. The sources reviewed do not quantify how many crates in the wider ecosystem, beyond the sampled 10,000, might see compile-time regressions once Polonius Alpha reaches general nightly use.