Enabling the next-generation trait solver on nightly

在 Nightly 版本中启用下一代 Trait 解析器

Aug. 21, 2026 · lcnr on behalf of The Rustc Trait System Refactor Initiative 2026 年 8 月 21 日 · lcnr 代表 Rustc Trait 系统重构计划团队

After nearly 4 years of active development, the next-generation trait solver is close to stabilization. We are enabling it by default on nightly to surface any remaining issues and plan to stabilize it in the next months. This is the largest single change to the Rust compiler since its initial release. It completely replaces how we prove where-clauses, normalize associated types, and much more. 经过近 4 年的积极开发，下一代 Trait 解析器已接近稳定。我们正在 Nightly 版本中将其设为默认启用，以发现剩余的问题，并计划在未来几个月内将其稳定。这是自 Rust 编译器发布以来最大的一次单一变更。它彻底改变了我们证明 where 子句、规范化关联类型等诸多功能的底层逻辑。

Please try out the latest nightly and open an issue if you encounter any bugs or regressions. This is an internal component of the compiler. The main benefits of this rework will come in the future. The removal of the old implementation will unblock features such as Type Alias Impl Trait and Return Type Notation, allow us to add new implicit default trait bounds (e.g., Move and Forget), and enable us to fix the remaining type system unsoundnesses. 请尝试最新的 Nightly 版本，如果遇到任何 Bug 或回归问题，请提交 Issue。这是编译器的一个内部组件，此次重构的主要收益将在未来显现。移除旧实现将为 Type Alias Impl Trait (TAIT) 和 Return Type Notation (RTN) 等功能扫清障碍，允许我们添加新的隐式默认 Trait 约束（例如 Move 和 Forget），并使我们能够修复类型系统中剩余的不健全问题。

Even so, this already fixes a huge number of issues. As an underapproximation, we currently know of more than 200 issues on GitHub fixed by this change. This also has a significant impact on compile times; more on that later. When developing on nightly, you may accidentally rely on behavior only supported by the new trait solver. This is an incredibly big change which results in a non-trivial amount of breakage. Most of these changes are intended improvements to type inference or the removal of undesirable behavior. We are tracking the known issues and breakage in a pinned GitHub issue. 即便如此，该变更已经修复了大量问题。保守估计，我们目前已知 GitHub 上有超过 200 个问题通过此变更得到了解决。这对编译时间也有显著影响，稍后会详细说明。在 Nightly 版本上开发时，你可能会无意中依赖仅由新 Trait 解析器支持的行为。这是一个极其巨大的变更，会导致一定程度的破坏。其中大多数变更旨在改进类型推断或移除不理想的行为。我们正在一个置顶的 GitHub Issue 中跟踪已知的问题和破坏情况。

What can I do? Please update to the latest nightly version by using rustup update nightly and use it to test your existing projects and libraries. ⚠️ While the next-generation trait solver has been enabled on our main branch, this change will only be accessible on the nightly channel starting from Saturday 22nd August. You can already test it before then by providing -Znext-solver=globally as a command-line argument ⚠️ 我该怎么做？请使用 rustup update nightly 更新到最新的 Nightly 版本，并用它测试你现有的项目和库。⚠️ 虽然下一代 Trait 解析器已在我们的主分支中启用，但该变更要到 8 月 22 日（周六）起才会正式进入 Nightly 通道。在此之前，你可以通过提供命令行参数 -Znext-solver=globally 来进行测试 ⚠️

Please tell us if you encounter any breakage, compile-time performance regression, or bad diagnostics. We have not yet spent too much time on error messages for the next-generation trait solver, so we would also appreciate you using this nightly for development to find poor diagnostics and other bugs in our error handling. If you encounter any issue, take a quick look at the pinned GitHub issue to see if the affected crate is already listed, and if not, please open a new issue! 如果你遇到任何破坏、编译性能回归或糟糕的诊断信息，请告诉我们。我们尚未在下一代 Trait 解析器的错误消息上投入太多精力，因此如果你能使用此 Nightly 版本进行开发，帮助我们发现诊断信息中的不足以及错误处理中的其他 Bug，我们将不胜感激。如果你遇到问题，请先查看置顶的 GitHub Issue，确认受影响的 Crate 是否已被列出；如果没有，请提交一个新的 Issue！

To disable the next-generation trait solver on nightly, you can pass -Znext-solver=coherence to rustc, use RUSTFLAGS=-Znext-solver=coherence, or change your project’s .cargo/config.toml configuration file: 若要在 Nightly 上禁用下一代 Trait 解析器，你可以向 rustc 传递 -Znext-solver=coherence，使用 RUSTFLAGS=-Znext-solver=coherence，或者修改项目的 .cargo/config.toml 配置文件：

[build]
rustflags = ["-Znext-solver=coherence"]

What exactly does this mean? We will go into more detail about the next-generation trait solver, how we got here, and what it changes when fully stabilizing it. This is a quick summary of its main impact. 这到底意味着什么？我们将在完全稳定该功能时，详细介绍下一代 Trait 解析器、我们是如何走到这一步的，以及它带来了哪些改变。以下是其主要影响的简要总结。

impl Trait handling

impl Trait 的处理

The way opaque types — return-position impl Trait (RPIT), but also the unstable Type Alias Impl Trait (TAIT) and Return Type Notation (RTN) — are handled in the type system has nearly completely changed. This fixes a lot of bugs and edge cases with them and should make their behavior a lot more consistent in general. This change is why the next-generation trait solver is necessary to stabilize TAIT and RTN. 类型系统中处理不透明类型（Opaque Types）的方式——包括 return-position impl Trait (RPIT)，以及不稳定的 Type Alias Impl Trait (TAIT) 和 Return Type Notation (RTN)——几乎发生了彻底改变。这修复了许多相关的 Bug 和边界情况，并使它们的行为在总体上更加一致。正是因为这一变更，下一代 Trait 解析器对于稳定 TAIT 和 RTN 来说是必不可少的。

The implementation change mostly does not matter for RPIT as we special-cased impl Trait from the method signature when type checking the method body. This means the only way to observe the old behavior is via recursive function calls. The following snippet errors with the existing implementation, but compiles with -Znext-solver enabled: 对于 RPIT 而言，实现上的变更影响不大，因为我们在对方法体进行类型检查时，对方法签名中的 impl Trait 进行了特殊处理。这意味着观察到旧行为的唯一途径是通过递归函数调用。以下代码片段在现有实现中会报错，但在启用 -Znext-solver 后可以编译通过：

fn foo(b: bool) -> impl Sized {
    if b {
        // The old implementation errored here.
        // 旧实现在此处报错。
        foo(false) + 1
    } else {
        0
    }
}

Associated types in higher-ranked types

高阶类型中的关联类型

The most impactful change is way we handle associated types referencing bound variables, i.e., lifetimes from a for<'a> binder, for example, the type for<'a> fn(<T as Trait>::Assoc<'a>). While most users don’t encounter such types directly, there are widely used crates which do. This change impacts existing code by removing incorrect type inference, such as in bevy and minijinja. It also fixes a bunch of unnecessary errors like in the following example: 影响最深远的变更是我们处理引用绑定变量（即来自 for<'a> 绑定器的生命周期）的关联类型的方式，例如类型 for<'a> fn(<T as Trait>::Assoc<'a>)。虽然大多数用户不会直接遇到此类类型，但一些广泛使用的 Crate 会用到。此变更通过移除不正确的类型推断（例如在 bevy 和 minijinja 中）影响了现有代码。它还修复了许多不必要的错误，如下例所示：

trait OtherTrait { type Assoc<'a>; }
impl OtherTrait for u32 { type Assoc<'a> = &'a u32; }

trait Trait {}
impl<T: OtherTrait> Trait for (T, for<'a> fn(<T as OtherTrait>::Assoc<'a>)) {}

fn impls<T: Trait>() {}

fn main() {
    // The old implementation failed to prove
    // the where-bound of `impls`.
    // 旧实现无法证明 `impls` 的 where 约束。
    impls::<(u32, for<'a> fn(&'a u32))>();
}

Compile-time performance

编译时性能

co-authored with jana :3 与 jana 共同撰写 :3

We’ve spent a lot of time on the compile-time performance of the next-generation trait solver. There have been many cases where it performed quadratically or even exponentially slower than the old solver. Especially the last few weeks were mainly spent on improving performance. This work was shared by many people, with major contributions by Nick Nethercote, jana, Rémy Rakic, and mira. 我们在下一代 Trait 解析器的编译性能上花费了大量时间。在许多情况下，它的性能表现呈二次方甚至指数级慢于旧解析器。尤其是过去几周，我们主要致力于性能优化。这项工作由多人共同完成，其中 Nick Nethercote、jana、Rémy Rakic 和 mira 做出了重大贡献。

As part of this effort, Rémy Rakic compared the performance of both implementations for the top 20,000 crates on crates.io. Below you is a visualization of the performance changes over the last two months. On the left and the right, the major outliers can be found. Note that the sample of crates here is biased towards such crates, because those are more interesting to us. Nearly all crates we tested in the top 20k had effectively the same performance with both implementations. 作为这项工作的一部分，Rémy Rakic 对 crates.io 上排名前 20,000 的 Crate 在两种实现下的性能进行了对比。下方是过去两个月性能变化的图表。左侧和右侧可以看到主要的异常值。请注意，这里的 Crate 样本偏向于这些异常值，因为它们对我们来说更有研究价值。在测试的前 20k 个 Crate 中，几乎所有 Crate 在两种实现下的性能实际上是一样的。

This graph shows that we’ve mainly focused our efforts on the negative outliers and made significant progress there. While many of the crates that previously took more than twice as long to compile with the new solver are still slightly slower, our work has made a few of them actually compile faster than with the old solver. We will continue to improve its performance over the coming months, and there are still a lot of optimization opportunities compared to the old implementation. 该图表显示，我们主要集中精力处理了负面异常值，并取得了显著进展。虽然许多之前使用新解析器编译时间超过两倍的 Crate 现在仍然稍慢，但我们的工作已经使其中一些 Crate 的编译速度甚至超过了旧解析器。在接下来的几个月里，我们将继续提升其性能，与旧实现相比，仍有许多优化空间。