2022 年 Rust 编译器目标

有些人一直在想 Rust 编译器团队为 2022 年计划了什么。此说明旨在让大家了解该团队今年计划关注的活动。

本文档分为三个部分：我们今年的总体主题、我们有资源推动的具体措施，以及如果我们得到更多帮助可以实现的愿景。

简介

此说明的部分动机是鼓励新的贡献者参与进来。我们有很多来自个人到大型组织的新来者，他们对 Rust 的潜力感到非常兴奋，我们想向他们展示他们可以做些什么来提供帮助。

这是一个项目列表，分为具体措施部分和愿景部分。我们在与编译器团队和编译器贡献者的讨论中积累了这些项目。具体措施已分配了负责人；每个人都为今年分配了时间来解决问题。愿景则是团队一致认为是很棒的投入领域，但我们目前缺乏足够的资源或有经验的开发人员今年取得进展的项目。

这不是我们今年将要做的所有事情的列表；至少，没有帮助就不是。

您可以将文档的愿景部分视为明确的战斗号召：如果您在那里看到任何您感兴趣的内容，请联系该部分中列出的负责人，了解您如何提供帮助。

在阅读本文档时，请记住Rust 不是一家公司：团队以及团队的领导者不会以自上而下的方式制定目标，也不会以循环的方式分配任务。相反，我们集体（并迭代地）完善我们对未来的共同愿景，并采取有望朝着该未来迈进的步骤。每位贡献者都自行决定他们能够贡献多少时间，并且贡献者之间的时间差异可能很大。我们为项目设定的目标必须与我们当前和未来的贡献者的目标保持一致；否则，它们将无法完成。我们有尝试确保一致性的流程（例如，RFC、MCP）；在某些方面，像这样的文档只是重新调整一致性的另一种工具。

总体主题

我们计划的工作有三个主题；本节描述这些主题，并为每个主题附加一个表情符号，当您查看表格概述时可能会对您有所帮助。

实现 Rust 的承诺 (🦀)

实现 Rust 的承诺是一个贯穿始终的主题；这意味着找出我们三大支柱：性能、可靠性和生产力的期望与现实之间的差距，然后解决这些差距。

开发者喜悦 (👩‍💻)

我们有机会改善编写、编译和运行 Rust 代码的体验。我们希望回答“什么会让 Rust 开发人员感到高兴？”这个问题。这不仅仅是满足他们的期望：而是超越他们。

贡献者工作流程 (🛠️)

最后，改进编译器贡献者工作流程意味着对维护和扩展 Rust 编译器本身的人员有益的技术增强。

(我们还会进行非技术增强，例如更改我们的社交流程，但本文档侧重于技术。)

工作项目

类别	具体措施	愿景
I-不健全 (🦀)	措施
异步 Rust (🦀, 👩‍💻)	措施
调试 (🦀, 👩‍💻)	措施	愿景
更快的构建 (👩‍💻, 🛠️)	措施	愿景
表达性 (👩‍💻, 🦀)	措施	愿景
库化 (🛠️)	措施	愿景
P-高优先级积压 (🦀)		愿景
团队运营 (🛠️)		愿景
后端 (🛠️, 👩‍💻)		愿景
诊断 (👩‍💻)		愿景

具体措施

本节最接近我们 2022 年的“路线图”。它是重要项目的列表，具有指定的负责人，他们已分配时间在今年就该问题取得重大进展。

I-不健全问题 (🦀)

在撰写本文时，我们有 69 个标记为 I-不健全的未解决问题，其中 44 个还标记为 T-编译器。

理论上，任何不健全问题都可能破坏 Rust 的可靠性承诺。我们希望在今年年底前，清楚地了解每个 I-不健全问题是如何产生的。我们正在研究系统地检测此类问题，以及是否可以为整个类别的问题部署缓解措施或修复程序，而不是逐个解决它们。

oli-obk 将是该领域工作的主要负责人。如果您有兴趣帮助解决这些问题，请联系 oli-obk 和 pnkfelix！

异步 Rust 措施 (🦀, 👩‍💻)

异步 Rust 与本文档的其他领域（例如调试和语言表达性）之间存在显着的重叠。

异步 trait

今天的 Rust 不允许在 trait 中使用 async fn，因此异步 Rust 代码通常最终会具有过于紧密耦合的组件；如果不使用诸如 #[async_trait] 之类的解决方法，这些解决方法会带来隐藏的成本，则无法编写可重用、通用的库。nikomatsakis 和 tmandry 正在推动 trait 中的异步 fn 措施，这将解锁在 trait 中原生编写 async 方法的功能。

异步崩溃转储剖析

michaelwoerister 正在推动 异步崩溃转储措施，这将使开发人员能够理解其异步 Rust 程序的崩溃转储中编码的控制流堆栈。

在异步 Rust 领域还有大量其他工作正在进行中。有关更多信息，请查看 异步愿景网站。

调试措施 (🦀)

wesleywiser 和 pnkfelix 正在建立一个 wg-debugging 工作组。它将至少涵盖以下子项目：提高 Rust 的调试信息质量 (michaelwoerister、wesleywiser)、支持拆分调试信息 (davidtwco)，以及与基于跟踪的调试器（如 rr）更好地集成 (pnkfelix)。

此措施的当前目标：建立工作组，确定调试问题积压的优先级，并找出调试器的活跃用户在操作 Rust 代码时最想念的是什么。

更快的构建措施 (👩‍💻, 🛠️)

众所周知，Rust 编译器的端到端延迟是一个问题。

lqd 将 2022 年的大部分时间专门用于此工作，与 Rust 的编译器性能工作组以及 nnethercote 等性能专家合作。lqd 有自己的活动文档，其中列出了正在调查的领域，并且 nnethercote 有一个正在开发的路线图。

表达性措施 (👩‍💻, 🦀)

我们经常听到的一个说法是：“我需要功能 X，但它没有在 rustc 或稳定版中实现。” 在 Rust 中，我们使用开放的请求评论 (RFC) 流程来设计新功能。目前，我们有这组批准的 RFC；以下是一些重要的功能，它们具有指定的负责人，我们希望它们能够向前发展。

泛型关联类型或 GAT 是 jackh726 拥有的一个正在进行的工作。GAT 有许多应用，例如其关联类型的生命周期与接收器类型的本地借用相关的 trait (例如 LendingIterator)。

trait 中的 async fn 是由 tmandry 拥有的一个正在进行的工作（前面已提到）。这是异步 Rust 最常要求的功能之一：为诸如 trait Foo { async fn bar(&self); } 之类的 trait 提供一流的支持

由 jswrenn 领导的 安全 transmute 项目预计将于 2022 年夏季完成。它将使一类大型类型能够进行 transmute（即零成本类型转换），而没有任何注入未定义行为的风险。

库化措施 (🛠️)

这些是专门用于编译器“库化”的措施：将 rustc 的单片代码库分解为一组可以独立开发的部分，并且理想情况下，可以将其重新用于 rustc 以外的其他类型的工具，例如 rust-analyzer。

Chalk

Chalk 是使用声明性逻辑规则（类似于 Prolog）对 Rust 的 trait 系统进行的重新实现。

Chalk 已经开发多年，并且在过去已经实验性地集成到 rustc 中。今年，jackh726 和 nikomatsakis 负责改进 Chalk 的集成，以推动其达到团队可以考虑迁移到 Chalk 作为 trait 系统实现的程度。这将解锁许多迄今为止在旧 trait 系统实现中难以实现的功能，并且其声明式结构将为人们推理 trait 系统的正确性提供适当的基础。

如果您想为此提供帮助，请联系 jackh726 和 nikomatsakis。

愿景

我们非常希望在本文档中列出的任何领域获得帮助，但本节专门列出我们知道目前缺乏资源的领域。

如果您有兴趣帮助解决这里的任何问题，请联系列出的负责人；他们会很乐意与您交谈。

P-高优先级愿景 (🦀)

作为编译器团队的负责人，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 简化工具

编译器开发人员的一项常见任务是创建 最小完整可验证示例。这项任务在很大程度上是机械性的；pnkfelix 有一篇关于 Rust 源到源转换的博客文章，介绍了如何实现这一点。但是，尽管它具有机械性，但自动化此任务的当前技术水平在于像 creduce 这样的工具，这些工具存在一些很大的限制（例如，一次只能处理一个文件）。

这是一个您完全不需要了解 rustc 源代码的领域。任何对编程语言技术感兴趣的人都可以参与其中；例如，可以考虑为某些代码简化转换添加 IDE 命令。

如果您有兴趣在此领域提供帮助，请联系 pnkfelix。

性能仪表板

perf.rust-lang.org 是一个仪表板，用于测量 rustc 在编译期间消耗的资源（时间和内存）的性能。@rust-timer 是一个机器人，用于总结给定的拉取请求是否导致性能回归或提高。

性能工作组对这些工具的改进有很多想法，但资源有限。这是一个您不需要任何编译器专业知识就可以产生巨大影响的领域；例如，我们的 Web 前端可以使用。数据科学家可能对我们的问题有有用的见解。除了衡量编译器自身的性能外，我们还对衡量生成的二进制文件的运行时性能感兴趣。

如果您想提供帮助，请联系性能工作组负责人 rylev 和 Mark-Simulacrum。

编译器后端愿景 (🛠️, 👩‍💻)

简化编写新后端

定义新的 Rust 编译器后端时，一个繁琐的来源是实现每个后端必须提供的内部函数。但是，对内部函数系统进行一个小小的更改：即允许内部函数定义一个回退 MIR 实现，可以减轻这种负担。如果您有兴趣在此处提供帮助，请联系 scottmcm。

Cranelift

Cranelift 代码生成器正在受到各方的广泛关注。 rustc 有一个 Cranelift 后端。如果您有兴趣帮助它，请联系 bjorn3。

GCC 后端

除了 LLVM 和 Cranelift 后端之外，还有一个正在开发中的新后端，它使用 GCC 的 libgccjit（正如许多人澄清的那样，它可以用于提前编译以及即时编译）。这个后端使 Rust 能够定位更多 LLVM 不支持的平台。

如果您有兴趣帮助这个项目，请联系 antoyo 和 bjorn3。

诊断愿景 (👩‍💻)

Rust 编译器具有相当好的诊断。但好消息是，对于诊断工程师来说，有一个完全就业定理，我们拥有的 1,500 多个开放诊断问题支持了这一点。

改进诊断是学习如何为 Rust 编译器做出贡献的绝佳第一步。如果您有兴趣提供帮助但不知道从哪里开始，修复诊断错误是一个很好的起点，您可以联系 estebank 以了解更多关于如何提供帮助的信息。

结论

看完这份列表，上面的项目数量似乎相当令人生畏！我们相信，这些举措将通过帮助实现 Rust 的承诺、让 Rust 开发者感到高兴、改进我们的贡献者工作流程，并与2021 年 Rust 调查的结果相一致，从而为 Rust 社区带来最大的影响。

虽然我们认为今年能够在这些举措上取得重大进展，但项目评估是一门困难且不精确的科学，特别是对于开源项目而言。我们最终能取得的成就取决于谁决定贡献力量。我们目前的目标只是愿望：美好的愿望。

这就是你们所有人，Rust 社区（包括该社区的未来成员）参与进来的地方。每个项目都列出了一到两个人；如果您感到受到鼓舞，请务必联系我们！

常见问题解答

我如何了解所有这些工作的进展？我们会很快看到另一篇类似的文章吗？

Rust 项目不断尝试不同的方法来跟踪其正在进行的举措的进展。我们还没有一个可以总结所有事项状态的单一位置，尽管我们正在努力更好地利用 Github Projects 来实现这一目标；例如，请参阅 lang 团队如何处理其举措。

编译器团队的领导计划在 6 月份发布一篇文章，总结到目前为止在此处列出的项目上的进展情况，并在 11 月份发布另一篇文章，回顾这一年的情况。

我没有看到任何关于单子卷饼（或其他非 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	否：在亚马逊云服务从事 Rust 工作
jackh726	@Jack Huey	否
jswrenn	@Jack Wrenn	否：在亚马逊云服务从事 Rust 工作
lcnr	@lcnr	是：https://lcnr.de/funding/
lqd	@lqd	否：由互联网安全研究小组赞助
Mark-Simulacrum	@simulacrum	是：GitHub Sponsors
michaelwoerister	@mw	否：在微软从事 Rust 工作
nikomatsakis	@nikomatsakis	否：在亚马逊云服务从事 Rust 工作
nnethercote	@nnethercote	否：在 Futurewei 从事 Rust 工作
oli-obk	@oli	否：在亚马逊云服务从事 Rust 工作
pnkfelix	@pnkfelix	否：在亚马逊云服务从事 Rust 工作
rylev	@rylev	否：在微软从事 Rust 工作
scottmcm	@scottmcm	否
tmandry	@tmandry	否：在 Google 从事 Rust 工作
wesleywiser	@Wesley Wiser	否：在微软从事 Rust 工作
xldenis	@Xavier Denis	否