1.96.0 预发布版本已准备好进行测试。该版本计划于5月28日发布。发布说明可在此处查看。

您可以通过运行以下命令在本地尝试：

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

索引位于 https://dev-static.rust-lang.org/dist/2026-05-26/index.html。

您可以在 内部讨论帖中提供反馈。

发布团队还在考虑对我们的预发布流程进行更改：我们非常希望您在这个 GitHub议题 上提供反馈。

由 mimo-v2.5 模型翻译，花费 977 tokens

项目管理日程

Nurzhan和Tomáš已确定我们的会议安排。简而言之，我们轮流参加每次会议，并已设置为减少连续会议和漫长夜晚的数量。我们还会有一些无需通话的周五，这总是很棒的。

日历可公开访问，我们已保持其最新状态。

2026年RustWeek / 全体会议

在5月18日这一周，乌得勒支将短暂成为人均Rustacean浓度最高的城市。与去年一样，它将同时举办RustWeek和Rust全体会议！

预注册和研讨会将于周一开始，实际的RustWeek会议在周二和周三举行，随后是三天的全体会议。

请查看演讲者、日程，在网站上了解更多信息，如果您计划参加，别忘了购票。

我们两人都计划出席。欢迎打招呼！

项目目标

2026年项目目标RFC已被接受！这比我们计划的时间晚了大约一个月。我们会记住这一点以备明年，由于大多数项目目标团队成员将出席全体会议，我们计划在那里进行复盘。

所有新的跟踪议题已创建，延续的议题也已更新。未续期至2026年的目标现已关闭。

如果您是某个目标的联系人，您将开始收到机器人消息，提醒您在跟踪议题上发布更新。这些提醒大约每月发生两次，如果您最近已发布更新则不会触发。

既然RFC已合并，我们将发布最后一篇2025年下半年项目目标更新博客文章。然后（可能再次在全体会议上启动），我们将规划如何进行未来的更新。人们提出了关于当前帖子格式、显示信息以及是否有用的几个问题。

Outreachy

整个4月期间，Outreachy实习申请者正在设置并开始提交他们的贡献。几天前，组织者选择了四名实习生。

以下是我们的实习生报名参与的项目：

• 从Rust调用重载的C++函数。
• 大规模Rust编译器的代码覆盖率。
• 对a-mir-formality类型系统实现进行模糊测试。
• 提高Rust项目GitHub Actions的安全性。

您可以在Jack Huey的博文中阅读更多关于项目和Outreachy的信息。

实习生将在接下来的三个月里致力于这些项目。祝贺被选中的实习生，并非常感谢Jack、导师们以及其他所有参与者。

激动人心的时刻即将到来！

C++互操作性更新

2026年2月，基金会聘请了teor以加快互操作问题空间的映射工作，他们的工作进展迅速。

teor一直在C++互操作项目目标跟踪器上发布月度更新，并在Zulip上发布每周更新。

我们现在在interop-initiative仓库中列出了大约30个互操作问题陈述和用例。如果您对此感兴趣，请务必查看。问题陈述描述得非常详细，包含示例代码并链接到先前研究。

这是一个字符串互操作示例。

作为贡献环节的一部分，Outreachy申请者提供了可执行代码示例，例如从Rust调用重载的C++函数。

teor还启动了一项语言实验来实现splat功能。这将提供一种在Rust中定义函数重载和可变参数的方法。最初的重点是改善与C++的互操作性，因为C++允许这两者。

除了这项工作显示出直接影响外，Joel Marcey还发布了一篇关于Rust基金会互操作计划更新的文章。文章回顾了该计划的成就。这些成就包括与ISO WG21（负责C++标准化的委员会）的合作。对于为C++提供内存安全机制似乎有很强的共识，但这将需要数年时间。

因此，基金会现在更关注那些拥有大型C++代码库并希望（或已开始）采用Rust的项目的直接需求。这就是teor所做所有工作的切入点。

内容团队

过去几个月里，团队难以投入时间为每个人制作有用的内容。我们发布了几次访谈（Daniel Almeida谈Linux中的Rust GPU驱动程序和Tyler Mandry谈C++/Rust互操作性），以及Rust 1.95更新日志概述，但我们还有九个录制积压工作正在进行中。

许多人员也将参加全体会议，我们计划在那里进行更多访谈。

很明显，对于代码、文档等有效的志愿贡献模式，在录制和编辑视频等方面效果不佳。我们能够做到这一点（正如我们已发布的内容所证明的），但所需的时间投入与专业人员即使以最低努力水平所做的相比要高得多。

为此，TC向委员会提出了2026年资金请求。我们要求15,000美元用于雇佣一名编辑来处理我们现有的积压工作，以及为我们将进行大部分未来访谈的活动（全体会议和RustConf）雇佣摄像师。

委员会已批准此请求，我们正在与可能雇佣的人员进行洽谈。

这将使我们能够专注于利用我们的知识和人脉采访优秀人士，并与社区其他人分享他们的想法。

Linux中的Rust

许多Linux for Linux的参与者将参加RustWeek和/或全体会议。Rust项目还向内核开发者发出了邀请，其中一些人也将出席。

该项目将在全体会议上举办几次会议：原地初始化、字段投影、CoccinelleForRust、将Rust编译为BPF和办公时间。

我们继续定期举行双周会议；以下是4月讨论的内容：

std中的zerocopy功能

鉴于将zerocopy纳入Linux的计划，团队提出了稳定标准库中一些zerocopy最终重新实现的不稳定部分的可能性。

这些是ptr_metadata和Freeze。将这些纳入将有助于zerocopy维护。

Freeze现在有一个开放的RFC作为core::marker::NoCell，而ptr_metadata则受阻于Sized层级。

null-ptr-deref

团队希望有一种（可选的）保证，即编译器永远不会删除原始指针上的空值检查。在C中，解引用空指针是未定义行为，因此编译器可以优化掉对该指针的后续空值检查。然而，空值检查仍然可以作为防止其他错误的保护措施，在C中，内核现在禁用会删除它的优化。

版本迁移工具

团队希望迁移到新版本，因为它将修复一些现有错误并提供更友好的语言和库API。但是，他们担心相同代码在不同版本中具有不同语义的情况。

进行语义变更是语言明确允许的事情，虽然我们提供工具来迁移或至少突出显示这些情况以防止破坏，但这些工具无法保证捕获100%的问题。

当前方法的一个挑战是，当内核迁移到新版本时，以前的发行版将保留在旧版本上（可能不止一个），在回移植变更时，这些情况很容易被遗漏。任何改变析构顺序的事情（例如2024版本中的if let临时作用域变更）都可能导致未定义行为。

Miguel Ojeda提出了这个问题，以了解语言和工具提供了哪些保证。他们正在寻找一种方法来标记相同代码在不同版本中具有不同语义的情况，要求零漏报率（即，不会让任何东西溜走）。

TC解释说，当前的迁移工具（版本lints和cargo fix）并非旨在提供这种保证，尽管我们努力接近这一点并在迁移测试上投入了大量精力。

Benno Lossin建议编写一种工具，该工具将在两个版本下编译被评估的代码并比较MIR输出。如果它们相同，则没有发生语义变更。否则，可能会也可能不会发生变更。这会产生误报风险，但至少审查人员可以确信没有东西被默默接受。这似乎是可行的，可能是项目有兴趣采用和维护的东西，但版本团队内部没有带宽来做这件事。

有趣的是，版本迁移本身不是问题——Linux for Linux团队关注版本迁移指南并检查相关内容。主要问题在于回移植，它是半自动的。如果一个补丁被标记为回移植并且它能干净地应用，那么几乎没有人工监督。当回移植补丁（来自较新版本）使用新功能时，在旧版本上编译失败，提醒人们注意。然而，当代码在两个版本中看起来相同但行为不同时，我们可能会遇到问题。

最终，提出了几种选择，每种选择都有其权衡：

• 留在一个版本上，直到所有稳定分支都迁移到允许全面迁移到新版本的MSRV（最低支持的Rust版本）。
• 开发一个外部工具，在两个版本下编译代码并检查它们是否产生相同的MIR。
• 在内核方面开发回移植补丁的审查流程以处理这些情况。
• 在内核内部开发流程和工具，以编写所有代码，使其始终落在所有分支支持的所有版本的交集内。

这个话题我们几乎肯定会再次讨论。

项目总监选举流程更新

2025年秋天，Tomáš协助了项目总监选举。协助者职责的一部分是发布复盘、澄清文档并提出选举流程的变更（如果相关）。

这是2025年PD选举复盘。澄清选举流程的PR在这里。

值得关注

Rust基金会文章

• 宣布2026年Rust-Edu刷新和CFP
• 项目总监更新 — 2026年3月
• 欢迎研讨会来到Rust创新实验室
• RustConf 2026：演讲者公布，注册开放
  • 我们的一位项目经理Tomáš是演讲者之一，分享Rust in CPython倡议的进展。
• Rust基金会互操作计划更新：从研究到实施
• Rust基金会与包注册表领导者联合解决开源可持续性危机

Rust项目更新

• 提高nvptx64-nvidia-cuda目标的基线
• 宣布Google Summer of Code 2026选定项目
• 宣布Rust 1.95.0
  • 查看内容团队制作的随附发布更新日志视频（zulip）。
• docs.rs：默认构建更少的目标
• WebAssembly目标和处理未定义符号的变更
  • 警告：这将对WebAssembly目标引入一个小的破坏性变更
• crates.io：帮助测试我们新的Web前端
  • crates.io已使用Svelte 5重建其前端。您可以在这里测试：https://crates.io/svelte/
• 基础设施团队2026年Q1回顾与Q2计划

统计数据

撰写的会议记录总字数：551.3k（2025年6月–2026年4月）

参加会议数：45

撰写的会议记录总字数（4月）：80.8k

每个团队会议的平均（均值）字数：

• Cargo：1.9k
• Lang triage：3.1k
• Libs-API：4.7k
• 领导委员会：2.4k

由 mimo-v2.5 模型翻译，花费 10541 tokens

本文涵盖了2026年3月10日举行的Rust基金会董事会会议。请在基金会网站上阅读完整的3月会议纪要。要点包括：

• Futurewei的Sid Askary加入了会议，讨论在Rust基金会内部创建一个专注于AI的研究项目的提案。他分享了草案并回答了董事会的问题。随着提案的发展，董事会将在未来的会议上重新审议。
• Symposium项目申请加入RIL（Rust创新实验室），董事会投票通过了申请。董事会还借此机会建议，将一些讨论主题整理成博文，以澄清哪些类型的项目是RIL的优秀候选者，工作人员现在已经完成了这项工作！
• 董事会讨论了基金会工作人员关于如何使crates.io运营更具可持续性的初步想法，这与Rust基金会在2025年9月签署的OpenSSF声明一致。尚未就实施什么做出最终决定，工作人员将在未来几个月内继续与Rust项目的相关部分讨论和完善这些想法。
• 董事会讨论了在金级会员数量不足以获得投票席位时，如何让它们参与董事会会议的方法。
• 董事会讨论了关于Rust生态系统基金如何运作的一些初步想法，以使公司更容易支持他们使用的重要crate。除了同意这是一个值得基金会工作人员进一步调查的主题外，没有做出其他决定。
• Processing基金会被批准成为基金会的准会员。
• Teor作为承包商加入了C++互操作性倡议。
• Canonical作为金级会员加入！
• Rust基金会加入了DataDog开源计划，这为我们提供了一个可观测性平台来监控和处理基础设施事件。
• 安全和基础设施团队一直在与crates.io团队、安全响应和安全代码工作组合作，共同解决crates.io上的拼写错误模仿攻击。
• 互操作性倡议已确定了需要重点关注的高优先级用例。
• 为2026年会议重新设计RustConf网站的工作已经完成（并且已经上线）。

由 mimo-v2.5 模型翻译，花费 1843 tokens

我们一直在将 crates.io 的前端从 Ember.js 迁移到 Svelte 5（跟踪 issue），新的 Svelte 应用现在已准备好在 https://crates.io/svelte/ 接受公开测试。我们非常希望在将其设为默认之前，能得到你的帮助进行试用。

目前，Svelte 应用旨在成为 Ember.js 应用的 1:1 移植。它在外观和行为上应完全相同（我们的 UI 测试套件，包括视觉回归测试，已经在两个应用上都通过了），因此你注意到的任何显著差异都是我们想听到的 bug。为了便于比较两个应用，Ember.js 应用中的一些粗糙之处也被保留了下来。一旦我们不再同时维护两个前端，这些都会被改进。

两个应用来自同一个域，并共享会话状态和数据，因此你只需访问 https://crates.io/svelte/ 即可继续正常使用网站，无需再次登录。如果与 Ember.js 应用相比，有任何外观或行为上的不同，请通过 GitHub 或 Zulip（#t-crates-io）告知我们。

如果测试顺利，我们将在未来几周内将 Svelte 应用设为默认，并期待在此基础上构建更多功能。

我们要感谢 Ember.js 团队 提供了多年来为 crates.io 提供良好服务的框架，以及 Svelte 团队 让这次向新事物的过渡如此愉快。特别感谢 crates.io 团队的 @eth3lbert 审阅了大部分迁移 Pull 请求。

由 mimo-v2.5 模型翻译，花费 1454 tokens

以下是基础设施团队在2026年第一季度取得的成果以及我们在第二季度的重点工作。

您可以在这里找到本系列的上一篇博文。

第一季度成就

迁移到 GitHub 规则集

我们开始从分支保护规则迁移到GitHub 规则集。

规则集是 GitHub 建议保护分支和标签的新方式。它们比经典的分支保护具有更多的可配置性，并且是设置合并队列等新功能的唯一 API 方式。

我们已转换所有仓库，但rust仓库除外。我们正在处理中！

作为这项工作的一部分，我们还将所有分支保护和规则集选项配置化，通过 team 仓库管理，实现基础设施即代码。

以下是新增的配置选项：

• allowed-merge-apps
• merge-queue
• prevent-deletion
• prevent-force-push
• require-conversation-resolution
• require-linear-history

更多详情，请参见GitHub 问题。

增强 CI 安全性

我们始终努力提升安全态势。以下是本季度最重要的几个例子：

• 在team仓库中，我们启用了Renovate，这是一个自动创建拉取请求以保持 GitHub Actions 和 Rust 依赖更新的机器人。这使我们更容易保持依赖更新并及时修复安全问题。
• 在compiler-builtins CI 中，我们启用了 Renovate 并解决了zizmor 报告的安全问题，为在 CI 中以更安全的方式运行 RISC-V 自托管运行器做准备。
• 我们发布了 crates-io-auth-action v1.0.4，更新其依赖项，并在 GitHub 宣布弃用 Actions 运行器上的 Node 20 后，将其从 Node 20 迁移到 Node 24。

两个新的开发桌面

我们配置了两个新的开发桌面：dev-desktop-us-2.infra.rust-lang.org 和 dev-desktop-eu-2.infra.rust-lang.org。

我们还为开发桌面启用了 IPv6 访问，使其更容易从更多网络环境访问。详情请参见GitHub 问题。

更多信息请查阅Forge 文档。

更大的 docs.rs 实例

我们正经历着 crates.io 上发布 crates 的空前增长，这对 docs.rs 基础设施造成了巨大压力，因为它必须为更多 crates 构建文档。

为跟上这一增长，我们将 docs.rs 实例升级到了更强大的版本，RAM 和 CPU 核心数都翻了一番。

通过 SAML SSO 改进 Rust 基础设施的访问控制

我们引入了 Google SSO 作为 Rust 基础设施服务的一部分。我们为基础设施团队启用了 Google Workspace 帐户，并验证了一些关键基础设施提供商（如 Datadog 和 Fastly）的 SAML 设置。

更多详情请参见GitHub 问题。

Triagebot 增强功能

Triagebot 是我们可靠的机器人，在 GitHub 和 Zulip 聊天中持续处理工作流。

我们在 2026 年第一季度实施了多项重要更改。

GitHub issue 评论查看器

我们为 Triagebot 添加了GitHub issues 和 PR 查看器。它主要针对 GitHub 对长 issues 和 PR 的“加载更多”按钮无能为力的情况而设计。

可通过长 issues 和 PR 顶部的查看所有评论链接访问。

例如 triagebot#2251：

虽然它起步时目标较小，但在过去一个季度中有了很大发展，包括：

• 一个独立的“导出”按钮（在 #2274 中实现）
• 一个用于审查线程的目录（在 #2360 中实现）
• 展开/折叠线程的按钮（在 #2355 中实现）
• 以及其他小改进

组织范围的默认配置

Triagebot 有许多功能和配置，虽然在仓库中启用功能并不难（需要一个拉取请求），但这无法扩展到 rust-lang 组织及其超过 200 个仓库的规模。

为了解决所有仓库中功能可用性不均的问题，我们在 Triagebot 代码库中添加了组织范围默认配置的支持，并开始在组织范围内启用一些功能。

即将启用的组织范围功能的公告在 Zulip 的 #t-infra/announcements>Triagebot Organization-Wide Defaults 中发布。

user-info 命令

这个新的 Zulip 命令最初是作为comments 命令出现的，用于查看最近的用户评论，但后来扩展为更通用的 user-info 命令，显示给定 GitHub 用户帐户的最近活动（PR、仓库）和帐户创建日期。

这是我们帮助审查者和维护者处理草率的 AI 生成 PR 的努力的一部分。

每团队轮换模式

Triagebot 在多个仓库中处理审查者的自动分配。直到二月份，还不能设置每团队轮换模式。

现在可以通过 Zulip 命令 work set-team-rotation-mode <team> off/on 实现，由 @Kobzol 在 #2273 中实现。

每仓库审查偏好

继续审查者分配的主题，以前只能为 rust-lang/rust 设置审查偏好，尽管 Triagebot 处理多个仓库。

@Kobzol 在 #2286 中解决了这个问题。现在可以设置每仓库审查偏好。

向 Zulip 主持人流报告被封禁用户

作为支持不同团队需求的一部分，我们实施了一个自动报告系统，用于在 Zulip 上报告我们 GitHub 组织中被封禁的用户（在 #2269 中实现）。

此功能的目标是通过自动检索该信息并将其发布到主持人的 Zulip 频道，来减轻主持人截图和手动归档不当评论及用户操作的负担。

Clippy 的 Zulip lint 提名主题

类似于上一个主题，我们还帮助 T-clippy 在 Zulip 上设置了自动 FCP 主题，当他们想要提名一个 lint 进行讨论时。

作为这项工作的一部分，我们还添加了在 GitHub 上添加回复评论的功能，其中包含指向已创建 Zulip 主题的链接。

用于处理反向移植和分配问题优先级的新 Zulip 命令

项目成员现在可以使用两个新的 Zulip 命令来为 rust-lang/rust 的 issues 和拉取请求应用标签：

• backport [stable | beta ] [approve | decline ] <pr #>：接受或拒绝用于反向移植修复回归的补丁
• assign-prio <issue #> [ critical | high | medium | low | <empty>]：为问题分配优先级标签（虽然主要由编译器团队使用，但对所有人均可用）

更多详情，请参见文档。

第二季度计划

完成第一季度目标

在第一季度，我们未能完成所有目标，因此将在第二季度继续努力：

• docs.rs 基础设施现代化：尽管我们在第一季度对 docs.rs 进行了一些改进，例如使用 GitHub OIDC 将容器镜像发布到 AWS ECR，但我们仍然希望从单个 EC2 实例迁移到现代化、托管的部署。
• 外部硬件 CI 策略：发布在外部硬件上运行 Rust CI 的要求。
• 迁移到 GitHub 规则集：将 rust 仓库迁移到 GitHub 规则集。
• SAML SSO：
  • 从 team 仓库启用配置 Google Workspace 帐户。
  • 引导所有需要基础设施访问的用户，并为其他服务提供商（如 AWS）添加 SAML 设置。

改进 CI 安全性和开发者体验

我们希望使 Rust 项目的 CI 更安全、更易于使用。

我们有许多想法，但尚不确定优先处理哪些，以下是一些示例：

• 使 Rust 项目成员更容易采用 Renovate 等工具来保持依赖更新和安全。
• 检查依赖的 CVE。
• 添加更多静态分析工具，如zizmor，以保护更多 CI 工作流。
• 通过创建围绕 CI 作业持续时间和失败率等指标的仪表板来提高 CI 可观测性。由于 Rust Foundation 加入了 Datadog 的开源计划，我们计划为此使用 Datadog。
• 提高 CI 作业测试覆盖率的可见性。

用于关键基础设施访问的硬件安全密钥

我们希望通过使用硬件安全密钥进一步保护对关键 Rust 基础设施的访问。Rust Foundation 与Yubico 合作，我们希望向有权访问关键基础设施的 Rust 团队提供 YubiKeys。

我们的计划是在五月的Rust All Hands期间分发硬件密钥。详情请参见GitHub 问题。

加入我们！

如果您有兴趣为 Rust 的基础设施做贡献，请查看infra-team 仓库以了解更多关于我们的信息，并在Zulip 上联系我们。

我们始终在寻找新的贡献者！

由 mimo-v2.5 模型翻译，花费 10325 tokens

大家好，如果你所在的地区正值春季，祝你春日愉快！

团队会议

入职后，Nurzhan 已经能够（并且感到舒适地）独立参加会议。这让我们可以平均分担工作，同时保持同样的项目管理覆盖。我们可以相互补位，总体上，个人的会议负担已经减半。

这太棒了！尽管能够参与决策过程、帮助他人并记录讨论以供后人参考是一件美妙的事，但这也是一项消耗精力的工作——尤其是在一天内连续参加6到7小时会议的日子里。

我们仍在调整会议日程，但我们已经做出一个明确的选择，即不进行专门化。我们都参与每个团队的讨论，认识团队成员，也让团队成员认识我们。这使我们更容易分享知识和背景信息，也能在对方缺席时顶替工作。

当然，我们都会定期沟通，阅读未参会的会议记录，如果有任何事项需要跟踪或在会议间交接，我们也会处理。

这解放了我们，让我们有更多时间处理其他所有工作！

关于会议，发生了两项变化。首先，Josh Triplett 提议暂停 Style 团队的会议。在过去的几个月里（更早之前则是零星召开），只有两名 Style 团队成员参会。

该团队需要更多成员（rustfmt 也是如此），并且最好有一位 rustfmt 联络员参会。我们正在寻找解决方案，但目前，紧急问题可以通过异步方式处理。

另一个消息是，两个 Libs-API 会议合并为了一个。我们以前有一次会议处理被提名到团队的事项（问题、PR 等），另一次会议则处理待定的 API 变更提案 (ACP)。这两次会议都在周二举行，中间相隔一小时。

但这两次会议之间的界限并不明确（如果我们清空了提名积压事项，就会在第一次会议中开始查看 ACP），并且大家通常更希望能连续开会。

现在他们可以了！两次会议合并了，这让大家可以连续开会，并且还能提前一小时结束。如果讨论特别耗时，甚至能提前更多。

项目管理看板

我们现在已经为 Rust 项目管理看板填充了内容，以便你了解我们的工作动态。

这让我们能够更好地跟踪和协调工作，也使工作更加透明。

项目目标

2026 年项目目标 RFC 现已开放！这是目标团队过去几个月工作的成果。

你可以查看一下，如果有任何问题，请访问 project-goals/2026-workshop 频道。

如果你是团队负责人，请审核该 RFC 并提出顾虑或勾选你的同意框！

2025 年下半年的目标期也即将结束。我们正在准备最后的更新（我们希望在 2026 年 RFC 合并后发布），然后将全力推进 2026 年的工作。

相当数量的 2025 年目标将延续至 2026 年，对于这些目标，不会有太大变化。我们将复用跟踪问题、Zulip 频道以及其他一切。

新目标将会创建跟踪问题。任何目标更新都应发布在那里，并会自动发布到相应的 Zulip 频道，我们可以在那里进行讨论。

我们每月还会发送两次提醒，要求发布更新（如果有近期更新，将不会发送提醒）。

FLS 发布说明

FLS 是用于安全关键环境（如汽车）的 Rust 规范，最初由 Ferrous Systems 开发。它已捐赠给 Rust 项目，现在由 FLS 团队 维护。

作为他们稳定 FLS 发布 目标的一部分，他们计划在 Rust 任何给定版本发布六周后发布新版 FLS。

到目前为止，他们一直在追赶进度：等待发布，然后查阅发布说明，寻找需要在文档中反映的任何更改（特别是语言变更）。他们希望更早开始，但在发布说明全部编写完成之前，他们需要一份包含在给定版本中的问题列表。

因此，Pete LeVasseur联系了发布团队，并同意尝试参与发布问题的初始分类流程。这样，他们能更好地理解流程，提供帮助，并尽早获得所需的问题列表！

这是一个很好的提醒：该流程是完全公开的。始终欢迎更多贡献者，这也可以作为进入更广泛贡献的易入门点。

镜像 crates.io 和 Rust 发布

3 月初，我们启动了实现可验证镜像原型项目目标。这是先前签名探索工作的延续，但焦点更窄。计划是为 Rust crate 和发布提供镜像，以帮助 GitHub Actions 等高流量环境。

该原型将让我们验证所提出的方法（例如使用更新框架 (TUF) 来验证镜像更新）和密钥轮换，同时提供有助于减少带宽使用和成本的功能（通过 GitHub Actions 访问 Azure 上托管的镜像）。

此功能将在不稳定特性标志后实现，但如果经过验证，我们可以用它来构建更通用的镜像支持。

在此目标的跟踪问题创建之前，更新将发布到 Zulip 的 tbd-signing 频道。

Rust 基金会维护者基金 (RFMF) RFC

2025 年 12 月，我们提到了维护者基金 以及 RFMF 设计委员会的成立。他们采访了几个有类似计划的开源组织（Python 软件基金会、Scala 中心、Django 和 Zig 软件基金会），并提出了一个 RFC。

该 RFC 提议设立一个“驻场维护者”角色：

驻场维护者计划致力于雇佣长期维护者并全额资助他们的维护工作。驻场维护者的时间分配在由他们支持的团队指导的优先事项和项目内自选的优先事项之间。

这些维护者预计是项目成员，在社区中有良好声誉，能够长期致力于保持项目的健康和发展。

它还提议组建一个资助团队，该团队将与领导委员会一起选拔候选人，并确保计划的整体成功。

这与提议的资助计划 是互补的，后者为已经为项目做出有价值工作的人提供十二个月的财务支持。他们不是被雇佣或签约，但我们要认可他们的出色工作，并让他们更容易继续下去。

Outreachy 实习

Rust 项目正在参与 Outreachy！这是一个为科技领域代表性不足人群提供的带薪开源实习计划。

委员会已为 2026 年 5 月至 8 月实习轮次分配了三个实习名额的资金。

我们已提出五个项目（将 Rust 添加到现有的 C/C++ 构建系统、从 Rust 调用重载的 C++ 函数、大规模 Rust 编译器代码覆盖率、对 a-mir-formality 类型系统实现进行模糊测试，以及改善我们的 GitHub Actions 安全性）。目前，我们处于贡献期。这是申请人为项目做出贡献的阶段，这些贡献将有助于选拔实习生。

就个人而言，我（Tomas）对此感到非常高兴。我热爱 Outreachy 所做和所代表的事情。我认识并曾与几个参与该计划的人共事，他们都是非常出色的人和同事。

非常感谢 Jack Huey 组织了这件事！也感谢 Niko、Rémy、tiif、teor、Joel Marcey 和 Ethan Smith 作为导师和联合导师报名！

Rust for Linux

Boxy 负责常量泛型，他想了解哪些领域对 Rust for Linux 团队最为相关。常量泛型涵盖了许多功能，因此确定优先级很重要。

以下是团队提出的内容：

1. 在常量泛型类型上进行算术运算的能力：例如，内核有一个类型 Bounded，它有一个值和一个最大大小（以位为单位）。位宽和值都是常量值。他们希望能够对这些类型进行算术运算（从位移开始），这将保证结果在编译时适合指定大小。

3. 参数位置的常量泛型：目前，常量泛型类型必须在类型绑定部分（尖括号内）指定。因此，例如，你必须写：Bounded::<u8, 4>::new::<7>()，而不是更自然的 Bounded::<u8, 4>::new(7)。当涉及常量时间计算而不仅仅是数值常量时，这会变得更复杂——在这种情况下，还需要用花括号包装：{ ... }。

5. 对非数字类型进行泛型化：指针对 asm_const_ptr 会有用。字符串字面量也会有用——即使它们只是被传递而不被处理或操作。如果从传递字符串扩展到可以传递任何类型，这将帮助团队用 enum 替换他们正在使用的一些类型状态模式。

在其他更新中，Gary 添加了一个通过宏提供指针投影的基础设施。

dma_read!/dma_write! 宏已切换到此。请注意，这完全通过宏完成，不使用任何字段投影语言特性。字段投影语法和 trait 应该会使其更符合人体工学，并集成借用检查器，以便我们可以接受更多代码。

关于这一点，语言团队举行了一次设计会议，讨论了 Benno Lossin、Nadrieril 和 Tyler Mandry 提出的最新提案“通过虚拟位置实现字段投影”。你可以在此处阅读提案和会议记录。

最后，作为 rustfmt use 讨论的后续，Tomas 创建了一个问题，以便在不使用尾随 // 变通方法的情况下，保持 Rust for Linux 所需的逐行导入格式。

Rust for CPython

我们三月份与 CPython 的人开了一次会议。

带上下文的 Drop

Python 对象是引用计数指针。在任何给定时间，它们要么连接到 Python 解释器，要么没有。当连接时，它们的引用计数可以增加或减少，但它们必须在进行任何原生调用时断开连接。这些指针不能是 Clone 或 Drop，因为 trait 实现不知道它们是否连接到解释器状态。

如何在 Rust 中建模此问题以使其既安全又符合人体工学，是一个悬而未决的问题。

David Hewitt 询问了“带上下文的 Drop”功能，这将要求将关联的上下文（例如指向 Python 解释器状态的指针）隐式传递给 drop 函数。

项目组一直在思考这个问题（参见 Tyler Mandry 2021 年的文章、Nadrieril 最近的 “如果 Trait 携带值会怎样” 文章 以及相关的 2026 年字典传递风格目标提案）。David、Josh Triplett 和 Jack Huey 计划在 Zulip 以及 2026 年 All Hands 上继续讨论这个问题。

Sanitizers

CPython 在 CI 中运行 sanitizers（AddressSanitizer 或 ASan、MemorySanitizer 或 MemSan、UndefinedBehaviorSanitizer 或 UBSan 和 ThreadSanitizer 或 TSan），以提供对 C 代码的额外检查。这些对于 Python 的内存安全很重要。

Emma Smith 想确认 LLVM 和基于 GCC 的 sanitizers 是否可以混合使用——答案是不能。当使用 Rust 时，Python 解释器的 C 部分将必须使用 Clang 构建，并且这些部分将需要使用自己的 sanitizers。我们需要确保这些覆盖相同的范围。

团队还询问了 LLVM 版本之间的兼容性，因为 Rust 使用自己的 LLVM 分支。答案是虽然 LLVM 的主要版本不兼容，但 Rust 的分支和对应的上游版本应该是兼容的。Rust 包含向后移植的上游错误修复，并支持使用原版 LLVM 构建。

还有正在进行的由 Rust for Linux 推动的稳定 MemorySanitizer 和 ThreadSanitizer 的工作。

未来的会议

自本月初以来，我们没有收到任何新话题，因此我们暂时搁置了会议。当新话题出现时，我们会再次讨论，但目前有很多工作要做。Rust 和 CPython 的人员确实计划在 2026 年 All Hands 上举行一次联合会议。

同时，Emma Smith 从他们的角度发布了进展更新。团队已经完成了构建系统工作，并通过了 CPython CI。在未来几个月里，他们将计划内部 Rust API 设计，之后编写 PEP（Python 增强提案——类似于我们的 RFC），目标是 Python 3.16。

值得关注

Rust 基金会文章

• Canonical 加入 Rust 基金会成为金牌会员
• Rust 创新实验室的下一步？

Rust 项目更新

• 发布 Rust 1.94.0 和 1.94.1
• Cargo 安全公告
• 对 WebAssembly 目标和未定义符号处理的更改
  • WebAssembly 构建的破坏性变更提醒
• docs.rs：默认构建更少的目标
  • docs.rs 将在 2026-05-01 进行的破坏性变更提醒
• 我们从 Rust 挑战中听到了什么
• 发布 rustup 1.29.0
• 2025 年 Rust 现状调查结果
• 测试呼吁：构建目录布局 v2
  • 自 Cargo 1.91 以来，可以将中间构建产物（build-dir）和最终产物（target-dir）的位置分离到不同的目录中。
  • 现在，Cargo 正在更改 build-dir 的布局。目标目录的布局保持不变。
  • 他们呼吁测试此功能，以帮助发现诸如构建脚本使用它来推断 target_dir 或可执行路径等问题。
  • 请考虑测试此功能并报告遇到的任何问题。
• 2026 年 1 月和 2 月项目总监更新
• 领导委员会更新——2026 年 3 月
  • Rémy Rakic 作为编译器团队代表加入
  • Josh Triplett 作为 libs 团队代表加入

统计

撰写的会议纪要总字数：470.5k（2025 年 6 月–2026 年 3 月）

参加会议次数：35

撰写的会议纪要总字数（3 月）：73.8k

每次团队会议的平均（算术）字数：

• Cargo：1.9k
• Lang 分类：3.3k
• Libs-API：4.3k
• 领导委员会：2.4k

由 mimo-v2.5 模型翻译，花费 12015 tokens

大家好，Rust 领导委员会再次与您见面！我们希望分享一下自上次更新以来委员会的工作进展。

迄今取得的成果

欢迎 Rémy Rakic 和 Josh Triplett 加入委员会

三月的代表选举已经完成。委员会发生了几项变动：

• Mara Bos 卸任库团队代表，转而担任启动平台代表。
• Josh Triplett 加入，接替 Mara 成为库团队代表。
• Rémy Rakic 加入，担任编译器团队代表。
• Eric Huss 继续担任开发工具团队代表。

我们要感谢即将离任的代表 James Munns 和 Josh Stone 在委员会的付出。我们非常感谢他们的支持！

感谢所有参与此次过程的人员！下一次代表选举将于2026年9月举行，届时将选举委员会的另一半成员。

欢迎 Nurzhan Saken 加入担任我们的第二位项目经理

二月，我们欢迎 Nurzhan Saken 加入，与 Tomas Sedovic 共同担任我们的项目经理。这将有助于使我们的项目经理项目更具可持续性，并加强其提供的支持。您可以在最近的项目经理更新中了解更多关于 Nurzhan 的信息。

项目优先事项预算

自2024年以来，项目一直在管理一个项目优先事项预算。委员会使用此预算资金支持项目的相关活动。2026年初，基金会向该预算拨付了30.6万美元新资金，并从项目资助计划中转入了10.6万美元剩余资金。过去几个月，委员会一直致力于将资金分配到各项优先事项。以下项目已获批准：

• 将我们的旅行补助上限提高到10万美元（#254）。请注意，除此之外，基金会还为 RustConf 旅行额外提供5万美元。
• 为项目经理项目额外拨款16万美元，加上2025年的剩余预算，我们今年的起始余额约为34.4万美元。（#255）
• 为Outreachy 导师计划拨款2.5万美元（#264）。
• 为编译器运营合同拨款5.5万美元（#244）。

除了这些已分配资金，我们正在讨论是否将剩余资金预留用于以下用途：

• 为内容团队提供1.5万美元资金，以协助制作视频内容（#279）。
• 投入10万美元重启资助计划，以支持现有维护者（RFC#3919）。
• 考虑为crates.io的网页设计支持提供一笔未指定的金额（#278）。

其他事项

• 最终确定了一项校友政策，该政策涉及每年通知成员，告知其所属团队，并核实他们是否仍然活跃。#218
• 更新了项目董事的职责，以更好地定义和澄清期望。#250
• 明确表示导师团队无需请求委员会即可参与GSoC 2026。#253
• 基金会已更新了旅行补助的申请流程。#259
• 批准了一项关于委托全员大会嘉宾邀请的提案。#252

正在进行的工作

Rust 基金会维护者基金

去年十二月，我们成立了一个委员会（#248），以制定一项提案，来定义如何使用Rust 基金会维护者基金的资金。该基金是专门用于支持 Rust 项目维护者的专项资金。

团队一直在努力制定提案，该提案目前已开放评论，地址为 RFC#3931。

贡献政策

围绕 AI 贡献政策展开了一场热烈的讨论，起因是项目提交的“垃圾”内容有所增加。一项临时提案已在 #273 中提交，旨在解决 rust-lang/rust 仓库中的一些直接问题。另一项提案也已提交，侧重于期望的贡献类型，随后已移至 RFC#3936 以收集项目的评论。这对项目来说是一个重要问题，我们预计在不久的将来，在继续讨论和考虑不同提案的过程中，这仍将是焦点。

其他事项

• James Munns 继续推进 Rust 社会提案，正在召集一群感兴趣的人士来协助管理该计划。#260

跟踪我们的工作

正如您从上面的许多链接中看到的，委员会的工作主要在 我们的 GitHub 仓库 中公开进行。我们的会议议程事项均源于此。在讨论某项议题后，我们会在该 issue 上总结讨论内容以及任何共享的理由。当我们做出决定时，会在 issue 上提议一个“最终评论期”（FCP），与项目中的所有 FCP 一样，我们感兴趣并会审查人们在最终评论期之前或期间提供的任何反馈。

要实时跟踪我们的工作，请关注我们的仓库。您也可以在 Zulip 的 #council > Meeting minutes & summaries 频道查看会议摘要。

会议纪要

我们将所有委员会会议的纪要发布到领导委员会仓库。自上次更新以来的纪要链接如下：

• 2025年12月5日
• 2025年12月19日
• 2026年1月16日
• 2026年1月30日
• 2026年2月13日
• 2026年2月27日
• 2026年3月13日
• 2026年3月27日

由 mimo-v2.5 模型翻译，花费 6742 tokens

项目管理更新 —— 2026年2月

大家好！本次更新由 Tomas Sedovic 和 Nurzhan Saken 为您带来 \o/。

来自 Nurzhan 的问候

我在2022年发现了 Rust 项目，并迅速为之着迷。这门语言、其文档、跟踪的议题、变更日志、博客、演讲以及用户/贡献者讨论——这些都满足了我的需求，并在我人生艰难时期给了我慰藉。作为一个极度内向的人，我大部分时间只是观察而未参与，因此项目经理的职位招聘信息对我来说就像是一个警钟。Tomas 在他的首次更新中说得很贴切：尽管对能否真正做好工作有许多疑虑，但我必须申请；如果不去争取，那种遗憾将是毁灭性的。

TC 和 Joel Marcey 在2025年3-4月面试了我，并考虑雇用我。这让我感到惊讶，因为我觉得自己当时一团糟！唉，您可能从之前的更新中得知，事情并未按计划进行，我最终未能获得这个职位。不过，已经没有回头路了，所以我开始通过稳定多个我感兴趣的功能来参与 Rust 社区。最终，更多的资金被分配下来，我被雇用了。

第一个月感觉如梦似幻。突然之间，那道想象中的屏障消失了，我发现自己与那些我一直仰慕其工作的人们共享空间（甚至互动）。Tomas 已经留下了许多令人印象深刻的足迹，似乎难以企及。很容易让人觉得这是个错误，觉得自己不属于这里。然而，每个人都如此热情友好。Tomas 特意花时间与我交谈、支持我，并让我了解项目中发生的一切。多亏了这一点，我已经基本融入，装备齐全，并且真的很幸运事情能有这样圆满的结果。

项目目标

二月份的重点是审核拟议的目标并让各团队审阅。目前我们没有未解决的拉取请求（这很大程度上得益于 Nurzhan 的帮助），并且我们吸收了审阅目标的团队关于规模和负责人的反馈意见。

每个目标通常对项目团队（如语言团队、编译器团队、库团队）有一个或多个诉求，因此他们审阅所有诉求，看清其表述是否清晰，并确定拟议的更改在项目中是否合理，这一点很重要。

在三月，我们将对各个目标进行最终审核，以确保它们有合适的负责人和规模。之后，我们将开放一个包含所有拟议目标的 RFC，并征求团队的意见。

这是一个重要的时间点，因为在此之前，目标大多被孤立地考虑。但通过 RFC，我们将全面审视，各团队也将考虑其全年的整体能力。

我们计划在三月完成 RFC 审阅，并在四月初正式开始新的目标周期。

我们还讨论了进行项目目标更新的方式。目前自动生成的博客文章不尽如人意，我们很想听取您的反馈！

如果您之前读过，特别是如果您没读过，我们很乐意听听您的意见！什么内容有帮助？什么没有？您希望看到什么？什么可能会分散注意力？

我们正在与内容团队讨论如何通过单独的文章或采访来突出特定目标。我们也希望让更新更有意义。听到您的看法会很有价值！您可以在 Zulip 上的博客文章主题中告诉我们，或者直接私信 T-program 别名。

以下是我们近期发布的一些博客文章：

• 2025年12月
• 2025年11月
• 2025年10月

项目管理追踪

鉴于现在有两个人全职承担项目管理工作，我们创建了专门用于此工作的平台。

首先，我们有一个 待办事项看板 来追踪我们的工作。任何 rust-lang 仓库的问题都可以添加到那里。

由于有些主题不适合放入现有任何仓库（例如安排签名与镜像会议或撰写每月项目管理更新），我们还创建了 program-team 仓库。它也可以存放与该工作相关的任何文档和工具。

最后，您现在可以在 Zulip 上使用 T-program 别名来与我们交谈，在讨论串中标记我们，或提出请求。

我们希望这能让人们更清楚如何联系项目管理，提供更高的透明度（展示我们实际在做什么），当然，也能帮助我们（项目经理们）更好地协调工作。

截至撰写本文时，仓库和看板都是空的。在其他仓库中有几个问题我们可以链接过去，但主要的是，Tomas 需要将他 Rust 项目的 org-mode 文件内容迁移过来。

C++/Rust 互操作性

基金会聘请了 teor 进行短期合同工作，以加速互操作问题空间的绘图，他们进展迅速。

teor 阅读了我们已有的所有文档，为每个议题/问题陈述（例如异常与展开，或不兼容的分配器）创建了 模板，立即开始记录已知问题，并为集成这两种语言的各种 用例 提交议题。

他们在 Zulip 上发布每周更新，在 项目目标跟踪议题中发布每月更新。

这些更新以及专注于梳理技术层面的工作，源于项目成员和更广泛社区向基金会提供的反馈（直接反馈，以及通过项目董事和项目经理等间接反馈）。

如果您对此领域感兴趣，请查看 interop-initiative 和 t-lang/interop Zulip 频道。

签名与镜像

继 一月份 之后，Walter Pearce 提出了一份项目目标草案。其重点是构建一个 MVP，为 Rustup 目标设置镜像。这将完全在后端进行（因此对用户应完全透明），以研究带宽和日志记录成本的削减、建立安全基础设施，并获取实践信息以构建最终解决方案。

我们已经为该小组增加了一些人员（例如 Rustup 的成员），草案正在积极讨论中。技术和沟通方面仍有一些问题需要解决，但该提案似乎处于一个稳固的状态，我们希望很快能开放一个拉取请求。

代码风格

过去几个月，许多会议最终都被取消了。一月底，我安排了一个新的双周会议时间，此后我们已经开了两次会。

在第一次会议中，我们分类整理了所有提名的议题。考虑到能力问题（风格团队有三名成员，其中一人近来无法投入大量时间），TC 建议我们专注于解决问题，同时寻求他人的帮助。

因此，当一个问题提交进来时，风格团队会评估它，弄清楚它适合现有指南的哪个部分，然后要求提交者提供一个具体的方案，而不是自己全部写出来。

这种做法类似于语言团队的运作方式。

最近的两次会议这样处理感觉效率高了很多，但能力问题依然存在。我们需要帮助！

如果您对语言如何格式化感兴趣——即就 rustfmt 应该做什么提供意见——我们很希望有您加入！您可以加入 t-style 频道 或 参加我们的一次会议。

Rust for Linux

我们讨论了 Rust for Linux 路线图，并审视了该项目跟踪的所有其他不属于特定目标的不稳定功能。这些功能将在路线图中被跟踪，我们将在合适的地方启动相应的目标。

Rust for Linux 有一个重要的里程碑：即将到来的 Debian 14 稳定版发布（代号：Forky）。Debian 稳定版发布的 Rust 工具链版本是 Rust for Linux 目前用于决定支持的最低版本的依据。例如，假设 Debian Forky 在2027年夏季发布，其 Rust 版本为1.104.0，那么在 Debian 发布后一段时间内内核的 MSRV（最低支持的 Rust 版本）提升时，Rust for Linux 就可以使用该版本中的新（也可能是不稳定的）功能。

Rust for Linux 支持一系列稳定的工具链，每个工具链都能访问一部分不稳定功能（其中一些是项目所依赖的）。每当同一功能在不同支持的工具链中以不同形式出现时，就会产生兼容性问题。例如，一个功能可能在最旧的版本中不可用，在较新的版本中不稳定，在后来的版本中稳定。其中一些问题可以在构建时处理（例如，当一个标志从 -Z... 改为 -C... 时），但其他的则需要非局部的条件编译（这意味着需要维护并行代码路径）。前者通常可以在不提升 MSRV 的情况下处理，但后者要困难得多，在那些情况下提升 MSRV 有可能消除大量的兼容性负担。为了避免特别繁重的维护成本，团队可能会选择等待下一个 MSRV 再采用新功能。

考虑到这一点，我们审视了那些影响最大且 Rust for Linux 希望在下一个 MSRV 升级后尽快开始使用的功能。其中最值得注意的有：

• 任意自引用类型
• 字段投影
• 不可移动类型与有保证的析构函数
• ADT 常量参数
• rustdoc --output-format=doctest
• 放宽 Rust 的孤儿规则 —— 今年晚些时候，团队希望将庞大的 kernel crate 拆分为子 crate，届时他们将需要处理孤儿规则。一种方法是在一组 crate（一个一致性域）内放宽孤儿规则。这个想法在2022年非正式地提出，并在 最近重新讨论。我们希望通过持续讨论来正式化这种方法（或考虑另一种）。

总的来说，Rust for Linux 希望在 MSRV 允许时尽快开始使用新的语言功能（尤其是那些具有新语法的功能），因为跨工具链同时支持新旧形式可能会变得负担沉重，延迟采用也可能导致未来大规模重构。如果新语法可以通过宏来隐藏，那通常是可以接受的。同样，使用不稳定功能也是可以接受的，只要能合理预期它将以大致相同的形式稳定下来，或者至少不会被移除。例如，不可移动类型可能会取代 Pin，从而导致巨大的语法变化。一个特殊情况是 原地初始化：团队已经对基础问题有一个可行的解决方案，并有潜在路径与最终的语言功能集成，因此它的缺失不像 字段投影 那样具有阻碍性，后者目前尚无任何形式的实现。

Rust for CPython

二月初，我们邀请了 Miguel Ojeda（Rust for Linux 的负责人）分享他的团队在将 Rust 引入 Linux 内核方面的经验见解。

Miguel 回顾了 Rust for Linux 的大致时间线：该工作在2020年底开始引起关注，导致了2021年初的 RFC。最小的实验性支持在2022年底合并到主线，实验于2025年底结束。与 Rust 项目的合作始于2021年左右，并在2024年初过渡到定期会议。

项目启动时，对于将 Rust 引入成熟的 C 代码库存在怀疑。C 长期以来一直是内核的主要语言，并且曾有抵制采用额外语言的情况（例如，1993年曾短暂试验过 C++ 后被放弃）。人们担心转向双语言代码库的弊端，以及开发者学习一种新的、益处尚不明确的语言和工具链的必要性。

该团队花费了大量时间在邮件列表和会议上与维护者和贡献者讨论这些问题，同时关注公开讨论和新闻，以便更好地进行沟通。2025年，Miguel 在 当年的 FOSDEM 活动 上做了一个主题演讲，展示了内核维护者、团队成员、利益相关者和公司对 Rust for Linux 的看法。

在 Miguel 提出的 RFC 中，他们坦诚地谈到了 Rust 的优点和缺点。许多内核专家认为内存安全性是主要吸引力，但 RFC 强调了超越此点的益处：安全代码与不安全代码的清晰分离（前者没有未定义行为、内存安全违规或数据竞争）、有用的语言特性（丰富的枚举、模式匹配、模块、卫生宏）以及强大的集成工具（rustfmt、rustdoc、lints）。RFC 将 将 Android Binder IPC 机制移植到 Rust 作为其初始用例，由此产生的反馈导致了第一个用 Rust 编写的硬件驱动程序（例如一个 GPIO 驱动程序的翻译，并与 C 实现进行了 逐行比较）。

团队优先提高 Rust 代码和文档的质量，例如，要求在每个 unsafe 代码块周围添加 SAFETY 注释、保持一致的代码格式以及完整记录所有公共 API。随着时间的推移，Rust 经验也使 C 方面受益。例如，审查 C 代码以设计 Rust 抽象时，有时会发现一些未被注意到的更深层次问题。更普遍地说，团队观察到 Rust 概念开始渗透到 C 侧的讨论和设计中；最近的一个例子是围绕 Revocable for C 的讨论。

这一切强烈引起了 CPython 开发者的共鸣，他们看到了与他们的提案非常相似的反应，并面临着类似的技术挑战。与 Kirill Podoprigora 一起领导这项工作的 Emma Smith 提到，Rust for Linux 的提案是他们为 CPython 启动这项工作的巨大灵感来源。

Rust 项目很高兴看到这一领域的交叉授粉，我们很乐意看到（并帮助！）更多项目在现有代码中添加 Rust。

除此之外，我们继续讨论构建系统和链接。与我们开始时相比，我们已经处理了许多眼前紧迫的主题。因此，现在只有在有足够内容可谈时才开会。目前这大约是每两周一次。

值得关注

Rust 基金会文章

• FOSDEM 2026 —— Rust 开发室回顾

Rust 项目更新

• 与 Daniel Almeida 一起用 Rust 编写 Linux GPU 内核驱动
  • 来自 Kangrejos 2025 的采访
• 发布 Rust 1.94.0
• 2025年 Rust 现状调查结果
• Rust 参与 Google Summer of Code 2026

统计

撰写的会议纪要总字数：396.7k（2025年6月 – 2026年2月）

参加会议次数：45

撰写的会议纪要总字数（二月）：73.7k

每次团队会议的平均（均值）字数：

• Cargo：1.6k
• 语言团队分类讨论：2.5k
• Libs-API：4.8k
• 领导力委员会：2.4k

由 mimo-v2.5 模型翻译，花费 10847 tokens

本月，我们将分享一份合并的董事会会议更新，涵盖Rust基金会2026年1月和2月会议的内容。感谢您的耐心等待！

提醒一下，项目主任是由选举产生的群体，代表Rust项目在Rust基金会董事会，并负责管理Rust项目与基金会的关系。

一月

在基金会网站上阅读一月会议的完整纪要。

从今年开始，董事会会议的格式已改为侧重讨论，效果很好！作为这一变化的一部分，我们的定期更新在单独的执行简报中提供，但请放心，即使会议纪要中未包含，我们也会在此包含这些更新：

• 在主权技术基金资助下，一名新的基础设施工程师于1月19日入职。通过这篇博客文章了解更多关于Ubiratan Soares的信息。

• 基金会工作人员参加了欧盟开源周的多项活动，包括：代码与合规、欧盟开源奖、欧盟政策峰会、FOSDEM、Google基金会聚会和OFE欧盟圆桌会议。这些活动是工作人员与其他基金会的同行就影响开源项目和开发者的政策变化进行合作的好机会。

• RustConf的提案征集已于2月16日截止。网站上也提供了赞助机会（该网站正在进行品牌重塑，将于第一季度末重新上线）。

• 东京Rust Global活动吸引了大量参与者并获得了良好反响，目前正与东京Rust组织者就探索该地区的其他机会进行持续讨论。活动录像现已发布。

• 基金会工程团队在其项目上取得了大量进展：

  • 已开发cargo-capslock以对Rust二进制文件执行静态和运行时能力分析。

  • 将漏洞信息呈现到crates.io的RFC已被正式接受。

  • 安全标签页的实现工作仍在继续审查和反馈，在上线前将提供更多改进。

  • crates.io的前端正从EmberJS迁移到Svelte。

  • 正在制定2026年互操作性倡议的行动计划，部分内容将继续为C++寻求内存安全子集，以在长期互操作性方面取得成果，即实现两种语言之间的端到端内存安全。

  • 同时，作为已确定项目目标的一部分，我们将认真梳理互操作性问题空间，这可能涉及Rust、C++或两种语言的问题。

  • 基础设施团队支持docs-rs团队将其所有指标、仪表板和警报从已弃用的自托管监控解决方案迁移到Datadog，该方案更可靠、更安全并提供更好的开发体验。

  • 正在准备关于TUF和签名工作的年终回顾。

  • 作为STF资助目标的一部分，对docs.rs环境进行了重大更改，以更充分地利用实物基础设施。

  • AWS慷慨捐赠了积分给Rust项目，为我们2026年提供了缓冲空间。

  • 创建了一个新的差旅补助申请表，以简化项目成员的流程。

• 董事会讨论了Rust创新实验室的资格要求，同意异步工作以在下次会议前制定具体的指导方针。

• 董事会审查了基金会内一个尚未命名的最终用户小组的拟议结构大纲。其目标是加强Rust行业/商业用户、Rust基金会和项目之间的互惠关系；帮助Rust的采用；并推动工业用户工具的创新。

二月

以下部分涵盖了2026年2月10日举行的Rust基金会董事会会议。在基金会网站上阅读二月会议的完整纪要。重点包括：

• Alexandru Radovici再次当选为银牌成员董事会代表。恭喜，Alexandru！
• 董事会讨论了关于什么将使一个项目非常适合被Rust创新实验室接受的澄清。该讨论通过电子邮件继续进行，并对RIL仓库中的文档进行了改进，我们计划很快发布一篇专门的博文！
• 基金会工程团队在他们的工作中取得了进展：
  • 雇佣了一名新承包商与项目合作处理C++互操作。欢迎，Teor！
  • 漏洞信息呈现标签页的实现已被接受、合并，现已上线。
    • 正在添加CVSS评分信息的工作。
  • 发布了来自crates.io团队的六个月更新。
  • 工程人员在FOSDEM 2026上进行了两次演讲 - 关于针对Rust生态系统的钓鱼攻击案例研究和使用Capslock分析为Rust和其他服务开发Seccomp过滤器。
• 基金会与项目团队负责人进行了面谈，以了解他们的关切和需求。
  • 在Zulip上查看总结的结论。
• RustConf早鸟注册、网站重新上线以及演讲者公告将于三月晚些时候推出！计划委员会正在努力审查和选择演讲。

我们很快会带来3月会议（于2026年3月10日举行）的更新！

由 mimo-v2.5 模型翻译，花费 3918 tokens

Cargo 1.94 开发周期动态

本文总结了过去约六周（即 Rust 1.94 合并窗口期）Cargo 开发中的主要进展。

• 本周期精选插件
• 功能实现
  • 构建目录布局
  • 目标目录锁定
  • 结构化日志
  • TOML 1.1
  • cargo-cargofmt
  • lockfile-path
• 设计讨论
  • 工作区与配置发现
• 其他动态
• 无进展的重点领域

本周期精选插件

Cargo 无法满足所有用户的需求，至少出于它必须维护的兼容性保证考虑。插件在 Cargo 生态系统中扮演着重要角色，我们希望在此表彰它们。

本周期的精选插件是 cargo-edit，它提供了编辑 Cargo.toml 文件的命令。cargo add 和 cargo rm 已被合并到 cargo 中。该插件还提供 cargo upgrade 用于更改版本要求（在 Cargo 中的跟踪 issue 为 #12425）以及 cargo set-version 用于更改 package.version（目前没有将其合并到 cargo 的请求）。

感谢 kpreid 的建议！

请为下一篇文章提交您的建议。

功能实现

构建目录布局

更新自 1.93

ranger-ross 发布了 #16502， 以更新 Cargo 关于构建目录布局的内部文档。该文档为审查此变更提供了另一个视角，从而促成了进一步的完善，如 #16514、#16515 和 #16519。

在一个不相关的变更中， epage 此前曾提议使 CARGO_BIN_EXE_* 在运行时可用，而不仅仅是编译时（Zulip），但在发现不需要后放弃了该提议。在查看 第一次 crater 运行 的结果后，他们决定推进此变更以减少对生态系统的影响，并可能带来其他益处，发布了 #16421。

epage 还尝试在新的构建目录布局上运行 Cargo 的所有测试套件（#16375），这导致了 #16348。

一次 新的 crater 运行 已经启动，结果分析正在进行中。

目标目录锁定

更新自 1.93

除了自上次更新以来面临的挑战，另一个问题是读取指纹以决定是否需要修改缓存条目时必须持有锁。锁的升级和降级存在死锁风险。

上次更新结束时提出的想法是，顶层构建操作拥有所有锁，并且被独占获取。这可以帮助解决指纹问题：我们在读取指纹之前获取锁，就知道它是安全的。但这确实意味着两个相同的构建会竞争锁。至少 cargo check（来自 rust-analyzer）和 cargo test（包装了 cargo build）或 cargo clippy 不会竞争。除了在一些容易忽略但重要的情况下。对于 cargo check 和 cargo clippy，cargo clippy 只为工作区成员获取唯一的缓存条目，因此非工作区成员将竞争锁。对于 cargo check 和 cargo test，缓存条目是唯一的（至少目前如此，参见 #3501），除了涉及过程宏和构建脚本的情况。我们决定暂时搁置此问题，以合并一个可以进一步迭代的最小设计。

我们还搁置了 动态资源限制、 阻塞消息通知用户、 以及当被阻塞时复用构建线程与另一个构建单元而不是空闲的想法。在那个阶段，我们得以合并 #16155。我们正在 #4282 中跟踪这些被推迟项目的进展。

结构化日志

更新自 1.93

weihanglo 继续在此方面取得进展，包括：

• 重构（#16485）
• 文档（#16476）
• 为 cargo report timings 添加缺失功能（#16414、#16441）
• 添加 cargo report rebuild（#16456、#16408、#16448）以查看重建原因
• 添加 cargo report sessions（#16428）以获取用于 cargo report timings 和 cargo report rebuild 的 ID
• 为 cargo report * 命令提供 man 页面（#16432、#16430）
• 移除不稳定的 --timings=FMT，因为它与 cargo report timings 功能重复（#16420）

在项目目标跟踪 issue 上，weihanglo 发布了总结、 朝向稳定化的剩余步骤，以及人们如何提供帮助。

TOML 1.1

12月18日，TOML v1.1 规范 发布。此版本的主要变更是现在允许在内联表中使用换行符。同一天，toml v0.9.10 发布以 支持解析 TOML 1.1 文件。

在 Zulip 上，我们讨论了 Cargo 的过渡问题。用户可能会无意中使用 TOML v1.1 的特性，并因此提高解析其清单所需的 Cargo 版本。这是 我们鼓励那些设置 rust-version 的人在 CI 中进行验证 的众多原因之一。然而，影响将是有限的，因为 cargo package 会重写发布的 Cargo.toml，包括仅使用 TOML v0.5 或更早的特性。这主要在使用 git patch 指向原始仓库时会感受到影响。

这里有一个注意事项： toml 目前不保留 时间中秒数或纳秒数是被省略还是为 0，它假设秒数从不被省略，而 0 纳秒总是被省略。如果 toml 开始保留此信息 并且 一个 Cargo.toml 字段使用了时间（可能仅在 [*.metadata] 字段中）并且 用户使用新语法格式化其时间，那么 cargo package 将生成一个需要新版本 Cargo 才能解析的重写后的 Cargo.toml。

Cargo 可以检测是否使用了 TOML v1.1 特性，并在 package.rust-version 字段过旧时发出警告，但我们认为这不构成阻碍，因为这与我们今天可以使用的任何其他字段情况相同，这些字段都会提高您的最低支持 Rust 版本。

Cargo 对 TOML v1.1 的支持于12月28日合并（#16415）。

cargo-cargofmt

人们一直期望 cargo fmt 也能格式化 Cargo.toml 文件（rustfmt#4091）。这项工作的一个主要障碍是 官方 Cargo.toml 文件风格指南 与现有或预期的 Cargo.toml 文件使用方式不一致。关于风格指南的提案想法曾在 Zulip 上讨论过，但对话停滞了。

epage 创建了 cargo-cargofmt 作为风格指南想法及其实现的测试平台。这包括 总结过去的对话 以及 比较现有格式化器。

iepathos 介入并扩展了格式化规则，包括调整单行和多行数组之间转换的一些棘手工作（cargo-cargofmt#37）。将内联表格式化为多行被推迟了，因为它可能需要一个新的 风格版本 以确保包的 MSRV 足够高以支持它。

有关当前支持的内容，请参见 cargo-cargofmt#25，以及正在考虑的内容，请参见 issue 列表。

lockfile-path

更新自 1.82

之前，已添加了不稳定的 --lockfile-path ../Cargo.lock 支持（#14326）。在 #15510 中，我们收到一个请求，要求也通过环境变量来设置它。在讨论中，我们认为应该将实现从 CLI 标志转向配置字段，因为这样既可以支持环境变量，也可以通过 --config 支持 CLI。特别是，我们试图记住的一个要点是，用户查看 cargo <cmd> --help 时能多容易找到他们需要的内容。存在的标志越多，用户越可能找不到他们需要的标志，用户从所有标志中获得的价值就越低，因为人们会转而绕开他们认为缺乏支持的功能。这在之前关于 --out-dir / --artifact-dir 的讨论中也出现过（#6100）。在权衡此功能的范围时，“隐藏”在配置中似乎是最佳方案。

weihanglo 在 #16510 中添加了 resolver.lockfile-path。我们将在另一个开发周期中移除 --lockfile-path，以便调用者有时间过渡。

设计讨论

工作区与配置发现

如果您不小心将一个 Cargo.toml 文件复制到您的主目录，它将导致您所有未显式声明 [workspace] 的包构建失败。对于任何恰好在父目录中的损坏或仅限于 nightly 的 Cargo.toml 或 .cargo/config.toml 文件也是如此（例如 #6646、#6706）。对于 Cargo.toml，Cargo 会检查当前清单是否是工作区的一部分。

我们至少可以改进错误信息，我们正在 #6706 中跟踪此项。如果能阻止新用户意外地在主目录中创建包也会有所帮助（#16562）。

对于 nightly 清单的情况，Cargo 可以检查父 Cargo.toml 是否有一个 [workspace] 表，并通过延迟 nightly 特性检查来跳过它。但是，nightly 特性可能会影响工作区发现。

对于清单，一个解决方法是在您的包中添加一个空的 [workspace]。但是，如果您在子目录中运行 cargo new，它将自动被添加为成员。我们可以扩展 package.workspace = "<path>"，使用 package.workspace = <bool> 来选择加入或退出工作区的自动发现。对于这种情况，您可以插入 package.workspace = false 以避免向上遍历目录树。Cargo 脚本开始时禁用了工作区自动发现，这可能是我们允许启用它的方法。此想法正在 #16563 中跟踪。

我们希望更广泛地改进工作区和配置发现行为，我们正在 #7871 中跟踪此项。

其他动态

• osiewicz 在 #16264 中加快了 cargo clean -p 和 cargo clean --workspace 的速度。
• （更新自 1.93） ranger-ross 添加了不稳定的构建脚本在没有 package.links 清单键的情况下使用 cargo::metadata 的支持（#16436）。

无进展的重点领域

这些是 Cargo 团队成员感兴趣的领域，在本开发周期内没有可报告的进展。

需要负责人的项目目标：

• 稳定化公共/私有依赖项
• 原型化一套新的 Cargo "管道" 命令
• 完成 libtest JSON 输出实验

可开发状态：

• 开放命名空间
• 自动生成补全
  • 参见 clap-rs/clap#3166

规划中：

• 禁用默认特性
• RFC #3416: features 元数据
  • RFC #3487: 可见性（visibility）
  • RFC #3486: 弃用
  • 不稳定的特性
• Pre-RFC: 全局互斥特性
• RFC #3553: Cargo 软件物料清单 (SBOM) 片段
• 操作系统原生的配置/缓存目录（即 XDG 支持）

您如何提供帮助

如果您有改进 Cargo 的想法，我们建议首先检查 我们的待办事项列表，然后在 Internals 上探讨该想法。

如果您希望解决某个在此处未讨论过的特定问题，您可以采取一些步骤来推动其进展，包括：

• 总结现有对话（例如：更好地支持 Docker 层缓存、Cargo.lock 策略的变更、感知最低支持 Rust 版本的解析器）
• 记录其他生态系统中的先例，以便我们可以在他人工作的基础上构建，并在合理的情况下为用户提供熟悉的功能
• 记录 Cargo 内部的相关问题和解决方案，以便我们了解是否在正确的抽象层上解决问题
• 基于这些帖子，提出一个考虑上述信息和 Cargo 兼容性要求的解决方案（示例）

我们可以在 zulip 上帮助指导 S-accepted 状态的 issue，并且您可以在 贡献者办公时间 期间实时与我们交谈。如果您希望帮助解决此处提到的某个较大项目并且刚刚开始，修复一些 issue 将帮助您熟悉流程和期望，使事情进展更顺利。如果您想解决一些 没有导师 的问题，对您自己需要做的事情的期望会更高。

由 mimo-v2.5 模型翻译，花费 16239 tokens

在本文中，我们想介绍Tiffany Pek Yuan（@tiif）。Tiffany 两年前才开始为 Rust 做贡献，当时是 Google Summer of Code （GSoC）贡献者。从那时起，她已经成为编译器和Formality团队的成员，并对多个项目做出了重要贡献，包括编译器、Miri和a-mir-formality。她也从一名受指导者转变为导师，因为现在她在Outreachy项目中指导另一位贡献者。

目前，她正在完成大学学位，同时作为RustNL 维护者团队的 Rust 维护者实习生从事 Rust 编译器工作。

我认识 Tiffany 时，她还是一名 GSoC 学生，正在为 Miri 添加检查 tokio 中 unsafe 代码的支持。指导她是一件乐事，随后看到她留下来并自行学习 formality 和 rustc，更是令人欣喜。

Oli Scherer，Rust 编译器团队成员，Tiffany 的 GSoC 导师

我们采访了 Tiffany，了解她加入 Rust 项目和为 Rust 做贡献的经历。请继续阅读下文！

请简要介绍一下自己。

嗨，我叫 Tiffany Pek。我目前正在新加坡国立大学攻读计算机科学学士学位。希望几个月后就能毕业！我为 Rust 的各个部分做出过贡献，现在主要专注于修复一个新的 trait solver 错误，该错误与隐式绑定有关，并在a-mir-formality项目中建模借用检查器的语义，该项目试图定义一个类型系统模型。

你是如何开始接触 Rust 的？是在课程中学习的，还是出于爱好？

我后来确实上过一门关于 Rust 的课程，但在那之前我就已经自学了。我大约在 2022 年听说了 Rust，因为当时在寻找一门系统编程语言。我在一个研究项目中尝试了它，并且非常喜欢。在那之前我尝试过很多编程语言，比如 Java、Python 或 C++。它们都不错，但 Rust 似乎更有趣。让我着迷的是它非常友好的错误消息。

你是如何参与到 Rust 项目中的？

我记得在大学时告诉朋友，如果能为 Rust 项目做贡献会非常酷。然后，仅仅一个月后，我得知 Rust 参与了 Google Summer of Code (GSoC)，我立刻想“我必须参加这个项目”！我们大学里都知道 GSoC，但不知为何尝试申请的人不多。我申请了 GSoC 并被录取了。

我觉得即使没有 GSoC，我最终也会为 Rust 做贡献，但这次实习让我有机会几乎全职地参与 Rust 工作，而不用担心找另一份工作。这非常有帮助。

你的 GSoC 经历如何？

我觉得非常顺利！这段经历非常愉快，因为还有其他几位实习生在同时进行不同的项目。而且我们都是“新手”，所以并不是只有我一个人在某些事情上挣扎。例如，当我搞砸了一个 pull request 的 rebase 时，我看到另一位 GSoC 贡献者也遇到了同样的情况，于是我想“哦，是的，我们是一样的！”，这样我就感觉好多了。另外，Oli 也是一位非常好的导师，和他们交谈非常开心。

Jakub 也是一位非常好的组织者，这使得项目取得了巨大成功。让我印象深刻的是我们甚至在实习开始之前就已经讨论了倦怠问题。

总的来说，这是一次很棒的入门体验，它激励我留了下来，因为我真的很喜欢这个社区。

你的 GSoC 项目是关于什么的？

我从事的是Miri的工作，它是 Rust 的未定义行为检测工具。当时，要将 Miri 运行在使用tokio crate 的非平凡异步 Rust 程序上基本上是不可能的。我添加了对各种非阻塞 I/O 系统调用（如 epoll）的支持，以扩大 Miri 可以处理的程序范围。然后我们与 Tokio 维护者合作，在他们的 CI 中对大多数 Tokio 测试运行 Miri，这相当令人兴奋。

你的第一次贡献是什么？

我为 Miri 添加了两个测试。在此过程中，我发现贡献文档中有些指令不清楚，因此我在同一个 PR 中也改进了文档。

你会推荐新贡献者采用这种方法吗？

是的，我认为改进文档是开始为 Rust 做贡献的好方法。首先找到你感兴趣的领域也很重要，因为 Rust 项目非常庞大，有 Miri、编译器、rustfmt、rustdoc、rust-analyzer、Cargo 以及许多其他需要贡献的领域。在进行较大的更改之前，最好先与相应的维护者讨论，然后再提交 PR。

如果你刚开始接触 Rust，请务必阅读错误消息，因为它们非常友好。如果你觉得错误消息难以理解，那可能是个 bug，那就去提个 issue 吧！

是什么让你在 GSoC 之后仍然留在 Rust 社区？

我留下来是因为社区。在 GSoC 期间，我开始与其他 Rust GSoC 贡献者交流。最终我在北京的一次会议上遇到了他们中的两位以及其他 Rust 项目成员。随后，我在Rust All Hands上结识了许多很棒的朋友，这使得 Rust 不再仅仅是一个纯技术项目，也成为了我和许多朋友热爱和关心的兴趣爱好。

你是如何加入编译器团队的？

我从 2024 年 3 月开始为 Rust 做贡献。在 GSoC 项目期间，我主要在 Miri 上工作，但后来我转而从事编译器工作。2025 年 11 月，我被邀请加入编译器团队。我完全没想到会收到邀请，所以感到很惊喜。

那时我已经与 Rust 社区有了很多互动，所以加入团队感觉变化不大，但得到正式认可确实感觉非常好。我也认为成为 Rust 团队成员可能有助于我找工作。

你对加入 Rust 项目感到高兴吗？

我非常高兴！项目里的人们都非常友善，我们经常彼此交流，这很棒。

我能够参加 2025 年和 2026 年的RustWeek会议和 Rust All Hands，这非常好。我感激 Rust 项目和基金会提供的旅行资助，让我能够参加这些活动。我在那里交到了很多朋友，这也是我仍然留在 Rust 项目的一部分原因。我所有的 Rust 朋友都在那里！

在 Rust 编译器上工作有什么让你兴奋的地方？

我觉得编译器非常令人兴奋！它就像一个神秘的黑匣子。如果你不了解它的工作原理，可能会觉得它很可怕，但一旦你开始学习，它实际上相当精巧。

我发现新的 trait solver 和 Polonius 工作（新的借用检查实现）非常令人兴奋，因为它们是语言的核心部分。一旦新的 trait solver 完成，我们将能够解锁许多特性并修复许多健全性 bug。而 Polonius 将使编译器能够接受许多以前被拒绝的正确程序，这可以使语言更具表达力。

在一个庞大且备受关注的编译器团队工作是什么感觉？

编译器团队之所以如此庞大¹，仅仅是因为代码库非常庞大，所以每个人专精于编译器的不同部分。我通常只审查我熟悉的那部分编译器。我从不知道编译器另一部分发生了什么，因为每天都有太多事情在发生。

在项目中，谁是你最大的导师？

是多个人，而不仅仅是一个。最初肯定是oli，因为他是我的 GSoC 导师，我们（现在仍然）经常交谈。后来我开始从事类型系统相关的工作，我帮助lcnr处理新的 trait solver。我也经常与Boxy交流，他现在是编译器团队的联合负责人。

你是否也曾尝试指导他人？

我尽量为其他人留下简单的改进任务，比如为他们开设包含贡献指令的 issue，并尝试在那些 issue 上回答潜在贡献者的问题。最近，我还在Outreachy项目中开始指导一位贡献者，这很令人兴奋。

你是否希望在 Rust 项目中做出一些改变？

我认识很多人，如果他们有机会全职参与 Rust 工作，就能创造出很棒的东西。但如果没有资金支持，他们只能断断续续地工作，这对他们来说效率不高，也不利于知识传递。我希望更多的 Rust 贡助者能获得资助。

你是否为自己的 Rust 贡助找到了资金支持？

我开始为 Rust 做贡献时，得到了 GSoC 项目的资助，这很好。后来我加入了苏黎世联邦理工学院的一个实习项目，这也提供了资金来源。在那些时候，我的产出相当高。但类似的资助来源通常只是暂时的。我还是个学生，所以我必须处理学业，同时还需要一份额外的工作来养活自己，这有时会有点困难。

找一份远程工作可能很棘手，因为我住在新加坡，时差问题不大。如果我要和美国的人安排会议，通常必须在晚上进行。幸运的是我睡得没那么早 :-) 但在与欧洲或美国的人和公司打交道时，这可能会是个问题。

我希望很快能完成学业，之后我就得找一份全职工作。我认为即使在那种情况下，我仍然会想为 Rust 做贡献，但我不确定该如何做到。也许我需要牺牲一些周末时间之类的。这可能会有点困难，但并非不可能。

目前，我在 RustNL 维护者团队有一个实习机会。如果我能找到一份允许我从事 Rust 工作的全职工作，那将是极好的，因为我真的很喜欢我现在所做的事情。

我认为即将推出的资金计划，如 RustNL 维护者团队和 Rust 基金会维护者基金，将能够为更多的 Rust 项目贡献者提供经济支持。不过我稍微担心公司资助维护工作的动机。公司的利益并不总是与社区的利益一致，这可能会产生一点利益冲突。但我相信有办法来缓解这一点。

我们感谢 Tiffany 与我们分享她的想法，以及她为改进 Rust 所做的一切工作！

1. 目前，该团队拥有超过 70 名成员。↩

由 mimo-v2.5 模型翻译，花费 7290 tokens