2026 is an exciting year for the Rust compiler (and me)

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

You might have already noticed that 2026 seems to be a bit special year for Rust compiler. It seems like there’s just a lot of stuff going on. Some things were already announced since I started writing this, but there’s still a bunch more that’s not as visible. I’ll share some things that I personally find interesting. To explain a bit of context, what happened this year is that multiple different initiatives are reaching final steps at the same time. In other words, 2026 is not that special with the amount of work being done, but it’s a year when we see several long-term investments starting to pay dividends.

你可能已经注意到，2026 年对于 Rust 编译器来说似乎是一个相当特殊的年份。看起来有很多事情正在发生。在我开始写这篇文章时，有些事情已经公布了，但还有更多不太显眼的内容。我将分享一些我个人觉得有趣的事情。简单说明一下背景，今年发生的情况是多个不同的计划同时进入了最后阶段。换句话说，2026 年在工作量上并没有那么特别，但这是我们看到几项长期投资开始产生回报的一年。

Next solver 🔗 Probably the biggest thing is the next generation trait solver. This is a reimplementation of a big part of the type system, and it has been in the works for a very long time - Almost 10 years in various forms. It fixes a bunch of soundness bugs and unblocks a lot of features and fixes for long-standing issues. It’s easy to understate how big of a deal this is for the compiler. This work resolves a major piece of technical debt that a lot of compiler developers dreamed about for years. It also frees up a bunch of people with a fresh and deep understanding of the type system to work on new things. The queue of things that get unblocked includes many common pain points of the language, even things that might seem benign or unrelated. It contains solutions to big problems in async Rust, or various limitations of impl Trait.

下一代求解器 🔗 最重要的事情可能就是下一代 trait 求解器。这是对类型系统很大一部分的重新实现，并且已经酝酿了很长时间——以各种形式存在了近 10 年。它修复了一堆健全性错误，并解锁了许多功能以及对长期存在问题的修复。很容易低估这对编译器来说有多重要。这项工作解决了一大块许多编译器开发者梦想多年要解决的技术债务。它还解放了一批对类型系统有深入了解的人，让他们可以去研究新事物。被解锁的功能队列包括许多语言常见的痛点，甚至包括那些看起来无关紧要或不相关的事情。它包含了异步 Rust 中重大问题的解决方案，或 impl Trait 的各种限制。

Polonius 🔗 Another big thing is Polonius, a new borrow checker implementation, long time in the making as well. It enables more code to compile and unblocks several related features - including (hopefully one day) internal references. The compiler impact of this is not as big as with the new solver, but it’s still a pretty big deal.

Polonius 🔗 另一件大事是 Polonius，这是一个新的借用检查器实现，也已经筹备了很长时间。它使更多的代码能够编译，并解锁了几个相关功能——包括（希望有一天能实现）内部引用。这对编译器的影响不如新求解器那么大，但仍然是一件相当重要的事情。

Perf 🔗 My main area of interest is compiler performance, and here we have quite a few things going on. After 1-2 years of a sort of stagnation (at least in terms of results), we suddenly have a lot of things going on at once. So much so that I have a hard time remembering everything, but from the top of my head:

性能 🔗 我主要关注的领域是编译器性能，这里有很多事情正在发生。在经历了 1-2 年的某种停滞（至少在结果方面）之后，我们突然同时有了很多进展。以至于我很难记住所有事情，但凭记忆来说：

Parallel frontend is close to stabilization 🔗 Very old initiative that was put a few years on hiatus with many unclear blockers. The development restarted again a few years ago with a new contributor @SparrowLi, and over time a number of other people contributed to the effort. Over the years, this turned out to be a massive can of worms. I get the feeling that almost nobody is really happy with the design. However, there doesn’t seem to be a better alternative for the foreseeable future, and parallel frontend is highly desirable, so the solution ended up being just grinding through a number of annoying and hairy problems until there’s nothing left. The current project goal is driven by @petrochenkov and is getting close to stabilization.

并行前端接近稳定 🔗 这是一个非常古老的计划，曾因许多不明确的阻碍而搁置了几年。几年前，随着新贡献者 @SparrowLi 的加入，开发工作重新启动，随着时间的推移，许多其他人也为这项工作做出了贡献。多年来，这被证明是一个巨大的麻烦。我感觉几乎没有人真正对这个设计感到满意。然而，在可预见的未来似乎没有更好的替代方案，而且并行前端非常令人向往，所以最终的解决方案就是硬着头皮解决掉一堆烦人且棘手的问题，直到没有问题为止。当前的项目目标由 @petrochenkov 推动，并且正接近稳定。

LLVM is getting faster 🔗 LLVM 23 was unambiguous and unexpectedly large positive change in performance. For a long time, LLVM upgrades were not particularly great for rustc performance. This changed after LLVM 10 upgrade, which introduced a massive 10% regression, and @nikic, current lead developer of LLVM, called it out in his blog post, Make LLVM fast again. In the post he also introduced a system for tracking LLVM performance over time, inspired by the one we use for rustc. Since then, LLVM started catching performance regressions earlier, and results for upgrades in rustc went from “less bad”, to “somewhat mixed”, to “mostly positive with caveats.” The last one of those was LLVM 22, which was green on icount benchmarks, but almost universally red on wall time. LLVM 23 is pretty much entirely positive. I don’t follow LLVM development that much, but my understanding is that this is because there’s now more work on actually optimizing it, as opposed to working on features without trying to regress performance. These days the improvements come both from new optimizations (those help optimize the compiler during bootstrap) and from LLVM itself getting faster.

LLVM 正在变快 🔗 LLVM 23 在性能方面带来了明确且出乎意料的巨大积极变化。长期以来，LLVM 的升级对 rustc 的性能并没有特别大的帮助。这种情况在 LLVM 10 升级后发生了变化，当时引入了高达 10% 的性能倒退，LLVM 的现任首席开发者 @nikic 在他的博客文章《让 LLVM 再次变快》中指出了这一点。在文章中，他还引入了一个受我们用于 rustc 的系统启发，用于长期跟踪 LLVM 性能的系统。从那时起，LLVM 开始更早地发现性能倒退，rustc 升级的结果也从“没那么糟”变成了“好坏参半”，再到“基本积极但有保留”。上一次是 LLVM 22，它在 icount 基准测试中表现良好，但在实际运行时间上几乎全面飘红。LLVM 23 几乎完全是积极的。我不太关注 LLVM 的开发，但我的理解是，这是因为现在有更多的工作致力于实际优化它，而不是在不考虑性能倒退的情况下开发功能。如今，改进既来自新的优化（这些有助于在引导过程中优化编译器），也来自 LLVM 本身的提速。

Lot perf improvements landing (micro-optimizations) 🔗 Compiler performance has been on a steady streak of improvements in the past few months. There’s probably no single explanation for it, just a combination of new contributors coming in, old contributors getting to do more perf work, and tooling improvements combined with architectural cleanups unlocking new opportunities. With more people working in this area, I’ve noticed a lot of cross-pollination, where a certain idea would circle around a few people’s minds, as people get inspired by each other’s PRs and try related things. I also feel like we got a lot better at managing regressions - triaging and addressing them. This is partially a tooling investment, but also a lot about processes and social structures. A major development here is the connection between tree ops and perf triage, represented notably by @JonathanBrouwer. This means that people who manage merges often directly triage their performance impact. This is important because it shrinks the response time, but the connection is useful for other reasons as well. The perf impact informs how you group PRs into rollups, for example. Turns out that Conway’s law is still a law. I also greatly enjoy helping people interpreting the measurement results and diagnose regressions. I often find that even just a few sentences from somebody who’s been looking at the results every day for many years go a long way towards getting the regression遭到解决. All in all, I feel like the compile time concerns are integrated into the development better than they have ever been.

大量性能改进落地（微优化） 🔗 在过去的几个月里，编译器性能一直保持着稳定的提升。这可能没有单一的解释，只是新贡献者的加入、老贡献者投入更多性能工作、工具改进以及架构清理解锁了新机会的综合结果。随着更多人参与到这个领域，我注意到很多交叉影响，一个想法会在几个人的脑海中流转，因为人们受到彼此 PR 的启发并尝试相关的事情。我也觉得我们在管理性能倒退方面做得好多了——即分类和解决它们。这部分归功于工具投资，但也很大程度上归功于流程和社交结构。这里的一个重大进展是树操作（tree ops）与性能分类之间的联系，以 @JonathanBrouwer 为代表。这意味着管理合并的人通常会直接对性能影响进行分类。这很重要，因为它缩短了响应时间，但这种联系在其他方面也很有用。例如，性能影响会告知你如何将 PR 分组到汇总中。事实证明，康威定律依然有效。我也非常喜欢帮助人们解读测量结果并诊断性能倒退。我经常发现，即使是那些多年来每天都在查看结果的人所说的几句话，对于解决性能倒退也大有裨益。总而言之，我觉得编译时间问题比以往任何时候都更好地融入到了开发中。

Move elimination 🔗 This seemingly came out of nowhere earlier this year, and it’s quite interesting. @Amanieu proposed a MIR optimization pass that allows the compiler to eliminate copies that LLVM has trouble optimizing. It speeds up both compile time and runtime. This is one of those passes that makes sense to implement in MIR instead of LLVM, because

移动消除 🔗 这似乎是今年早些时候凭空出现的，而且非常有趣。@Amanieu 提出了一个 MIR 优化过程，允许编译器消除 LLVM 难以优化的拷贝。它同时加快了编译时间和运行时间。这是那些在 MIR 而不是 LLVM 中实现更有意义的过程之一，因为