Rust 编译器 2022 年发展目标
有些人一直在想 Rust 编译器团队 2022 年有什么计划。本说明旨在让大家了解团队今年计划重点关注哪些活动。
本文档分为三个部分：今年的总体主题、我们有资源推动的具体举措，以及如果在获得更多帮助的情况下我们可以做到的愿望。
引言
本说明的部分动机是鼓励新的贡献者参与进来。我们有许多新人，从个人到大型组织，他们对 Rust 的潜力感到非常兴奋，我们希望向他们展示他们可以如何提供帮助。
这是一个列表，分为具体举措部分和愿望部分。这些项目是在与编译器团队和编译器贡献者的讨论中积累的。具体举措已分配负责人；每项都有今年分配的时间来解决问题。愿望部分列出了团队认为非常值得投入但目前我们缺乏足够的资源或经验丰富的开发人员来在今年取得进展的项目。
这 *不是* 我们今年将要做的所有事情的列表；至少，如果没有帮助，就不是。
您可以将本文档的愿望部分视为明确的号召：如果您在其中看到您感兴趣的内容，请联系该部分列出的负责人，了解您可以如何提供帮助。
在阅读本文档时，记住一点很有用：Rust 不是一家公司：团队及其领导者不会自上而下地设定目标，也不会轮流分配任务。相反，我们共同（并迭代地）完善对未来的共同愿景，并采取有望朝着该未来迈进的步骤。每位贡献者都会自行决定可以贡献多少时间，这在贡献者之间差异很大。我们为项目设定的目标必须与我们当前和未来贡献者的目标保持一致；否则，它们就不会实现。我们有流程（例如RFCs、MCPs）来确保一致性；在某些方面，像本文档这样的文档只是重新校准一致性的另一种工具。
总体主题
我们计划进行的工作有三个主题；本节描述了这些主题，并为每个主题附加了一个表情符号，这可能有助于您查看表格概览。
实现 Rust 的承诺 (🦀)
实现 Rust 的承诺是一个贯穿始终的主题；它意味着找出我们三个支柱（性能、可靠性和生产力）在期望与现实之间的差距，然后解决这些差距。
开发者愉悦度 (👩💻)
我们有机会改善 Rust 代码的编写、编译和运行体验。我们希望回答这个问题：“什么会使 Rust 开发者感到愉悦？” 这不是关于满足他们的期望：而是关于 *超越* 他们。
贡献者工作流程 (🛠️)
最后，改进编译器贡献者工作流程意味着技术增强，使维护和扩展 Rust 编译器本身的人受益。
（我们也会进行非技术性的改进，例如改变我们的社交流程，但本文档侧重于技术。）
工作项目
| 类别 | 具体举措 | 愿望 |
|---|---|---|
| I-unsound (🦀) | 举措 | |
| Async Rust (异步 Rust) (🦀, 👩💻) | 举措 | |
| 调试 (🦀, 👩💻) | 举措 | 愿望 |
| 更快构建 (👩💻, 🛠️) | 举措 | 愿望 |
| 表达力 (👩💻, 🦀) | 举措 | 愿望 |
| 库化 (🛠️) | 举措 | 愿望 |
| P-high 积压 (🦀) | 愿望 | |
| 团队运营 (🛠️) | 愿望 | |
| 后端 (🛠️, 👩💻) | 愿望 | |
| 诊断 (👩💻) | 愿望 |
具体举措
本节是我们 2022 年“路线图”中最接近的部分。它列出了一些重要的项目，这些项目有专门的负责人，并且分配了时间，以便今年在问题上取得重大进展。
I-unsound 问题 (🦀)
截至撰写本文时，我们有 69 个标记为 I-unsound 的开放问题，其中 44 个也标记为 T-compiler。
理论上，任何非健全性（unsoundness）问题都可能损害 Rust 对可靠性的承诺。我们希望到今年年底，对每个 I-unsound 问题是如何产生的有一个清晰的理解。我们正在研究系统性地检测此类问题，以及是否可以部署缓解措施或修复整个类别的问题，而不是逐案处理。
oli-obk 将是该领域工作的主要负责人。如果您有兴趣帮助解决这些问题，请联系oli-obk 和 pnkfelix！
Async Rust (异步 Rust) 举措 (🦀, 👩💻)
Async Rust 与本文档的其他领域（例如调试和语言表达力）之间存在显著的重叠。
async trait
Rust 目前不允许在 trait 中使用 async fn，因此 Async Rust 代码通常会导致组件耦合过于紧密；如果不使用 #[async_trait] 等带有隐藏成本的变通方法，就无法编写可重用、通用的库。nikomatsakis 和 tmandry 正在推动trait 中 async fn 举措，这将原生地解锁在 trait 中编写 async 方法的能力。
异步崩溃转储分析
michaelwoerister 正在推动异步崩溃转储举措，这将使开发者能够理解其异步 Rust 程序崩溃转储中编码的控制流栈。
Async Rust 领域还有大量其他工作正在进行。请查看异步愿景网站了解更多信息。
调试举措 (🦀)
wesleywiser 和 pnkfelix 正在启动一个 wg-debugging 工作组。它至少将涵盖以下子项：改进 Rust 的调试信息质量（michaelwoerister，wesleywiser），支持分离调试信息（davidtwco），以及更好地集成基于跟踪的调试器，例如 rr（pnkfelix）。
这项举措的近期目标是：建立工作组，确定调试问题积压事项的优先级，并找出活跃的调试器用户在操作 Rust 代码时最缺少什么。
更快构建举措 (👩💻, 🛠️)
Rust 编译器的端到端延迟众所周知是一个问题。
lqd 将把 2022 年的大部分时间投入到这项工作中，与 Rust 的编译器性能工作组以及nnethercote 等性能专家合作。lqd 有自己的实时文档列出了正在调查的领域，而nnethercote 有一份正在制定中的路线图。
表达力举措 (👩💻, 🦀)
我们经常听到的一句抱怨是：“我需要功能 X，但它尚未在 rustc 或稳定版中实现。” 在 Rust 中，我们使用开放的征求意见稿 (RFC) 流程来设计新功能。目前，我们有这套已批准的 RFCs；以下是一些重要的、有专门负责人且我们预期会取得进展的功能。
泛型关联类型（Generic Associated Types），或简称 GATs，是 jackh726 负责的一项持续努力。GATs 有许多应用，例如其关联类型具有与接收者类型的局部借用绑定的生命周期（例如 LendingIterator）。
trait 中的 async fn 是一个持续努力（如上所述），由tmandry 负责。这是异步 Rust 最常被请求的功能之一：为诸如 trait Foo { async fn bar(&self); } 这样的 trait 提供一流支持。
由jswrenn 领导的安全 transmute 项目预计在 2022 年夏季完成功能。它将使得一大类类型能够进行 transmute（即零成本类型转换），而没有任何引入未定义行为的风险。
库化举措 (🛠️)
这些举措致力于编译器的“库化”（librarification）：将 rustc 的单体代码库分解为一组解耦的部分，这些部分可以独立开发，并且理想情况下可以重新用于除了 rustc 之外的其他工具，例如 rust-analyzer。
Chalk
Chalk 是 Rust trait 系统的重新实现，使用声明性逻辑规则，类似于 Prolog。
Chalk 已开发多年，并在过去实验性地集成到 rustc 中。今年，jackh726 和 nikomatsakis 负责改进 chalk 集成，使其达到团队可以考虑迁移到 chalk 作为 trait 系统实现的地步。这将解锁许多到目前为止在旧的 trait 系统实现中难以实现的功能，其声明性结构将为人们推理 trait 系统的 *正确性* 提供一个适当的基础。
如果您想在这方面提供帮助，请联系jackh726 和 nikomatsakis。
愿望
我们非常欢迎在本文档列出的任何领域提供帮助，但本节专门列出了我们目前知道缺乏资源的领域。
如果您有兴趣帮助完成这里的任何项目，请务必联系列出的负责人；他们会很高兴与您交谈。
P-high 愿望 (🦀)
pnkfelix 和 wesleywiser 作为编译器团队领导者，正在部署流程来帮助我们处理编译器积累的那些“优先级高但 *非关键*”的问题。我们将逐步为每个问题确定负责人，他们将推动进展，并总体上努力更好地跟踪整个集合。
如果您想帮助审查或解决此类问题，请联系 WG-prioritization 的联合负责人wesleywiser 和 apiraino。
调试愿望 (👩💻)
我们希望与至少是流行的调试器有更好的集成。设置理想调试体验的命令序列过于晦涩，因此未被使用。
我们希望改进表达式求值支持：目前，大多数形式的方法调用不起作用，因为调试器不知道 Rust 的方法解析规则。
我们希望重新审视用于渲染 Rust 数据结构的调试器扩展架构，目前这主要是一组独立的 Python 脚本。
如果您想在这里提供帮助，请联系pnkfelix 和 wesleywiser。
更快构建愿望 (👩💻, 🛠️)
并行编译
并行编译是提高编译器性能的一个途径。它也是一个非常复杂的领域，尤其是在如何权衡单核构建的性能损失以实现更多并行计算方面。我们已经并行化了 LLVM 调用，但编译器其余部分的并行化仍处于实验阶段。这是一个我们认为需要与编译器团队长期协作努力的领域。我们预计今年不会在此处交付解决方案。
如果您想与我们讨论过去尝试和未来的想法，请联系pnkfelix 和 wesleywiser。
增量编译愿望
增量编译的性能和稳定性都是团队持续关注的问题。我们 *知道* 在提高增量编译的有效性方面有很大的提升空间，即减少连续 rustc 调用所做的冗余工作量。
此外，还可以做大量工作来改进我们的增量编译测试基础设施，这不需要深入了解编译器。我们不得不在稳定版上禁用后又重新启用增量编译；我们希望扩展我们的验证策略，以便在增量编译问题接近稳定通道之前就收到警报。
如果您想了解更多信息，请联系cjgillot 和 Aaron Hill。
Crate 间共享愿望
nnethercote 指出，通过识别可以在不同 crate 构建之间共享的冗余活动，可能有机会缩短多 crate 构建的端到端编译时间。（例如，每次 crate 编译时都会读取和解码 libstd 的元数据。）
如果您有兴趣进一步探讨这个想法，请联系nnethercote 和 lqd。
表达力愿望 (🦀, 👩💻)
const generics 和 const eval 正在稳步进展。有很多功能标志，这意味着有很多可以打开和关闭的开关。
我们最需要的帮助可能在于确定我们应该努力稳定哪个子集的功能，以便为 Rust 开发者解锁特定的用例。
所以，如果您或您的团队热切期待 const generics 或 const eval，请联系lcnr 和 oli-obk。
库化愿望 (🛠️)
MIR 工具链
各种利益相关者，特别是在形式化方法领域，正在基于分析 MIR（编译器使用的中间表示）来扩展 Rust。我们是否应该尝试将其稳定为一个某种类型的互操作格式？
例如，Kani 是 Amazon Web Services 正在开发的 Rust 位精确模型检查器。它作为 rustc 的另一个后端实现；但如果 rustc 可以只生成 MIR，而他们的编译器可以消费 MIR，那会更清晰。Prusti 和 Creusot 同样可以从稳定的 MIR 互操作中受益。
如果您有兴趣在这里提供帮助，请联系巴黎萨克雷大学 LMF 的xldenis（以及 Rust 形式化方法工作组的联合负责人）和pnkfelix。
编译器团队运营愿望 (🛠️)
MCVE 缩减工具链
编译器开发者的一项常见任务是创建一个最小完整可验证示例（minimal complete verifiable example）。这项任务很大程度上是机械性的；pnkfelix 有一篇关于实现这一点的 Rust 源代码到源代码转换的博客文章。但尽管其机械性，目前自动化这项任务的最新技术是像 creduce 这样的工具，它们有一些很大的局限性（例如一次只能处理一个文件）。
这是一个您完全不需要任何 rustc 源代码知识的领域。任何对编程语言技术感兴趣的人都可以参与；例如，可以考虑为某些代码缩减转换添加 IDE 命令。
如果您有兴趣在此领域提供帮助，请联系pnkfelix。
性能看板
perf.rust-lang.org 是一个衡量 rustc 性能的看板，它测量编译过程中消耗的资源（时间和内存）。@rust-timer 是一个机器人，它总结了给定 Pull Request 是降低还是提高了性能。
性能工作组对改进这些工具有很多想法，但资源有限。这是一个您不需要任何编译器专业知识就能产生巨大影响的领域；例如，我们的 Web 前端需要一些工作。数据科学家也可以对我们的问题提供有用的见解。除了衡量编译器本身的性能，我们还有兴趣衡量生成二进制文件的运行时性能。
如果您想提供帮助，请联系性能工作组负责人rylev 和 Mark-Simulacrum。
编译器后端愿望 (🛠️, 👩💻)
简化编写新后端
定义新的 Rust 编译器后端时的一个麻烦来源是实现每个后端必须提供的 intrinsic。但对 intrinsic 系统进行一个小改动：即允许 intrinsic 定义备用 MIR 实现，可以减轻这一负担。如果您有兴趣在这里提供帮助，请联系scottmcm。
Cranelift
由 Cranelift 代码生成器 正受到各方的广泛关注。rustc 有一个Cranelift 后端。如果您有兴趣帮助它，请联系bjorn3。
GCC 后端
除了 LLVM 和 Cranelift 后端之外，还有一个正在开发的新后端，它使用 GCC 的 libgccjit（正如许多人澄清的那样，它既可用于提前编译 (ahead-of-time) 也可用于即时编译 (just-in-time)）。此后端使 Rust 能够面向 LLVM 不支持的更多平台。
如果您有兴趣帮助这个项目，请联系antoyo 和 bjorn3。
诊断愿望 (👩💻)
Rust 编译器有相当不错的诊断功能。但好消息是，诊断工程师有一个充分就业定理（full employment theorem），我们有 1,500 多个开放诊断问题来支持这一点。
诊断改进是学习如何为 Rust 编译器做贡献的绝佳第一步。如果您有兴趣提供帮助但不知道从哪里开始，修复诊断错误是一个很好的起点，您可以联系estebank 了解更多关于如何提供帮助的信息。
结论
阅读这份列表，上面的项目数量似乎相当艰巨！我们相信这些举措将通过帮助实现 Rust 的承诺、让 Rust 开发者感到愉悦以及改进我们的贡献者工作流程，对 Rust 社区产生最大的影响，这与2021 年 Rust 调查的结果非常吻合。
虽然我们认为今年能够在这些举措上取得重大进展，但项目估算是一门困难且不精确的科学，特别是对于开源项目。我们将取得什么最终取决于谁决定贡献。我们设定的目标目前只是：愿望。
这就是你们所有人，Rust 社区（包括该社区的 *未来成员*）发挥作用的地方。每个项目都列出了一到两个联系人；如果您感到受到启发，请务必联系我们！
常见问题
如何了解所有这些工作的进展？我们会很快看到另一篇这样的文章吗？
Rust 项目不断尝试不同的方法来跟踪正在进行的举措的进展。我们还没有一个地方可以总结所有事情的状态，尽管正在努力更好地利用 Github 项目来做这件事；例如，参见语言团队在其举措方面的工作。
编译器团队领导者计划在六月份发布一篇总结此处列出的项目进展的文章，并在十一月份发布一篇回顾今年进展的文章。
我没有看到任何关于 monadic burritos（或其他非 Rust 语言功能）的提及；为什么这不在你的计划中？
本文档的范围主要限于编译器团队的问题。语言团队计划在另一篇文章中写更多关于他们今年的举措。敬请关注！
如果我对列表中某个具体项目感兴趣，我该怎么做？
此列表中的每个项目都列出了一位或多位负责人。Rust 编译器团队主要通过 Zulip 聊天平台进行沟通。
所以：注册一个 Zulip 账户，登录 Zulip，然后加入 #new members>compiler 2022 主题。告诉小组您感兴趣的项目，并提及与该主题相关的负责人，以便他们知道加入该对话频道。
如果我对编译器开发感兴趣但没有编译器经验，我该怎么办？
这不是问题！我们社区的许多成员通过参与 rustc 的工作学习了编译器，我们鼓励其他人也这样做。您可以从阅读Rustc 开发指南并加入我们的Zulip 开始。您也可以观看 estebank 在 RustConf 2021 上的关于为编译器做贡献的演讲，这将对您有帮助。
此外，本项目中还有一些领域即使没有编译器专业知识的人也能产生影响。例如，正如性能看板部分提到的，我们的一些内部工具需要一些 Web 前端工作。
如何联系项目的负责人或赞助他们在 Rust 上的工作？
下表列出了上面提到的项目负责人、他们的 Zulip 用户名以及他们是否接受赞助来帮助他们从事 Rust 工作
| 负责人 | Zulip 用户名 | 接受赞助吗？ |
|---|---|---|
| Aaron Hill | @Aaron Hill | 否 |
| antoyo | @antoyo | 是: GitHub Sponsors |
| apiraino | @apiraino | 否 |
| bjorn3 | @bjorn3 | 是: Liberapay |
| cjgillot | @cjgillot | 否 |
| davidtwco | @davidtwco | 否: 在华为英国研发部从事 Rust 工作 |
| estebank | @Esteban Küber | 否: 在 Amazon Web Services 从事 Rust 工作 |
| jackh726 | @Jack Huey | 否 |
| jswrenn | @Jack Wrenn | 否: 在 Amazon Web Services 从事 Rust 工作 |
| lcnr | @lcnr | 是: https://lcnr.de/funding/ |
| lqd | @lqd | 否: 由 Internet Security Research Group 赞助 |
| Mark-Simulacrum | @simulacrum | 是, GitHub Sponsors |
| michaelwoerister | @mw | 否: 在 Microsoft 从事 Rust 工作 |
| nikomatsakis | @nikomatsakis | 否: 在 Amazon Web Services 从事 Rust 工作 |
| nnethercote | @nnethercote | 否: 在 Futurewei 从事 Rust 工作 |
| oli-obk | @oli | 否: 在 Amazon Web Services 从事 Rust 工作 |
| pnkfelix | @pnkfelix | 否: 在 Amazon Web Services 从事 Rust 工作 |
| rylev | @rylev | 否: 在 Microsoft 从事 Rust 工作 |
| scottmcm | @scottmcm | 否 |
| tmandry | @tmandry | 否: 在 Google 从事 Rust 工作 |
| wesleywiser | @Wesley Wiser | 否: 在 Microsoft 从事 Rust 工作 |
| xldenis | @Xavier Denis | 否 |