Rust 社区在 4 月做了什么：项目管理月报解读

这份月报是什么

Rust 项目管理团队（Program team）每个月发一篇月报，记录上个月跨团队协调工作的进展。这不是技术博客，也不是某个具体功能的发布公告，而是一张快照，让社区看到 Rust 项目在治理、语言演进、社区建设这些层面实际在发生什么。

4 月是个忙月。2026 项目目标 RFC 通过了，四名 Outreachy 实习生入选了，C++ 互操作方向有了新进展，内容团队拿到了一笔资金解决积压问题，而且距离年度最大线下活动 RustWeek 只剩不到一周时间。

以下按主题逐一解读。

2026 RustWeek 与 All Hands 即将开幕

5 月 18 日这一周，荷兰乌得勒支将成为全球 Rustacean 密度最高的城市。RustWeek 和 Rust All Hands 再次联合举办。

日程安排是：周一预注册和工作坊，周二周三是 RustWeek 大会，之后三天是 All Hands 内部工作会议。

对 Rust 项目来说，All Hands 不只是一个社交活动。很多跨团队的技术决策、流程改进、甚至一些积压了很久的讨论，需要面对面才能高效推进。本月报里多次出现"计划在 All Hands 上做……"，可以感受到它在项目协调里的实际分量。

2026 项目目标 RFC 正式通过

Rust 项目每年通过"项目目标"来协调全项目范围内的重点工作。今年的 2026 项目目标 RFC 在 4 月正式获批，比计划晚了大约一个月。

RFC 通过之后，系统开始运转：

• 所有新目标的 Tracking Issue 已创建，持续中的目标也已更新，没有续签的目标已关闭
• 如果你是某个目标的负责人，系统会每隔约两周给你发一条提醒，要求在 Tracking Issue 上更新进展。如果你最近刚更新过，提醒不会重复触发
• 2025h2 目标的最后一篇总结博客即将发布
• All Hands 上计划做复盘，同时讨论进展报告的格式改进——社区对当前格式有些反馈，认为信息呈现方式可以更有用

这套机制的目的是让重要的长期工作保持对外可见，而不只是存在于某个团队的内部讨论里。

Outreachy：四名实习生入选，为期三个月

Outreachy 是一个面向代表性不足群体的开源实习项目，Rust 项目长期参与其中。

经过 4 月的贡献期，组织者从申请者中选出了四名实习生，对应四个方向：

从 Rust 调用 C++ 重载函数——直接服务于 C++ 互操作目标，实习生在贡献期内已提供了可执行的代码示例。

编译器代码覆盖率——在大规模场景下测量 Rust 编译器自身的代码覆盖率，有助于找到测试盲区。

对 a-mir-formality 类型系统进行模糊测试——a-mir-formality 是 Rust 类型系统的形式化规范实现，模糊测试可以帮助发现潜在的边界问题。

改进 GitHub Actions 的安全性——Rust 项目大量使用 GitHub Actions 做 CI/CD，安全加固的重要性不言而喻。

实习周期三个月，感谢 Jack Huey、各位导师以及所有参与其中的人。

C++ 互操作：从问题梳理到实现落地

Rust 和 C++ 之间的互操作一直是高优先级但高难度的方向。这个月有几个具体进展值得关注。

问题空间已有 30 个清晰的问题陈述

Rust 基金会于 2026 年 2 月聘请了 teor 专门负责梳理互操作问题空间。目前，interop-initiative 仓库已有约 30 个问题陈述和使用场景，每个问题陈述都包含详细描述、示例代码和已有方案的参考链接。

其中有一个字符串互操作的具体案例，直接展示了 RustString/&str和 C++std::string之间相互传递时会碰到的问题——内存模型不同、所有权语义不同、生命周期不同，每一个都是实实在在的工程障碍。

splat特性实验：为 Rust 引入函数重载

teor 启动了一个语言层面的实验，着手实现splat特性。这个特性的目标是给 Rust 增加定义函数重载和可变参数的方式，直接动机是改善与 C++ 的互操作性——C++ 允许两者，而 Rust 目前不支持。

基金会调整聚焦方向

在更宏观的视角上，Rust 基金会现在把注意力从研究性工作转向实际落地：优先服务那些有大型 C++ 代码库、正在采用 Rust 或已经开始迁移的项目。

在与 ISO WG21（C++ 标准化委员会）的合作层面，双方对于给 C++ 提供内存安全机制有比较强的共识，但这是一个多年的长期目标。近期可以落地的工作，还是 Rust-C++ 的直接互操作工具链。

内容团队：志愿者模式遇到瓶颈，Council 批了 1.5 万美元

Rust 项目有一个内容团队，负责制作访谈视频、版本解说等社区内容。过去几个月里，团队已发布了两个访谈：

• Daniel Almeida 谈 Linux 内核中的 Rust GPU 驱动
• Tyler Mandry 谈 C++/Rust 互操作

以及一期 Rust 1.95 版本更新解说视频。

但与此同时，积压了 9 个已录制但尚未剪辑发布的内容。

问题的根源在于模式本身。志愿者模式在写代码和写文档上运转良好——贡献者可以利用碎片时间，按自己的节奏推进。但视频录制和剪辑是时间块要求很高的工作，志愿者很难长期维持投入，哪怕只是最低限度的产出。

TC 向 Leadership Council 提交了一份资金申请：申请15,000 美元，用于聘请一名编辑处理现有积压内容，以及在 All Hands 和 RustConf 两次活动上聘请摄像。Council 已批准这份申请，目前正在接触候选人。

这笔钱解决的不是"要不要做内容"的问题，而是"让有知识和人脉的人专注在采访上，把后期交给专业的人"。这个分工更合理，持续性也更强。

Rust for Linux：四个技术议题的深度讨论

4 月的双周例会里，Rust for Linux 团队带来了几个值得关注的技术议题。

zerocopy 进入标准库的讨论

zerocopy 是一个在 Linux 内核里被广泛使用的库，用于零拷贝数据处理。由于 Linux 计划引入它，团队讨论了是否可以把 zerocopy 依赖的两个不稳定标准库特性稳定化：

• ptr_metadata：访问胖指针元数据，目前被 zerocopy 自行重新实现。稳定化后可减少维护负担。
• Freeze（即core::marker::NoCell）：标记一个类型不包含UnsafeCell的 trait。Freeze已有开放 RFC，正在推进；ptr_metadata的稳定化则依赖另一个更基础的"Sized 层次结构"工作。

null 指针解引用优化问题

C 里，解引用空指针是未定义行为，编译器可以据此做激进优化——如果某个指针被解引用了，之后对同一指针的 null 检查可以被编译器当作"永远为假"而直接删掉。

Linux 内核对此的解决方案是禁用这个优化（因为 null 检查有时是对其他 bug 的防御性保护，即便从语言规范角度它是"多余的"）。Rust for Linux 团队希望 Rust 编译器层面也能提供类似的可选保证，确保 null 检查不会被静默删除。

Edition 迁移与内核反向移植的兼容性难题

这是这个月技术深度最高的讨论，值得多说几句。

问题背景：Rust 的 Edition（版次）机制允许语言在新版次里做语义上的变更，同时通过工具（edition lints 和cargo fix）帮助开发者迁移。Linux 内核想迁移到新版次，以使用新的语言特性和更好的 API。

问题所在：内核有多个并行维护的发行版本（stable branches），反向移植（backport）是常规操作——把 mainline 的 patch 移植到旧版本上。反向移植通常是半自动的：如果 patch 能干净应用就自动合进去，几乎没有人工审查。

这里有一个隐患：如果一段代码在新旧两个 Edition 下的语义不同（但代码看起来完全一样），反向移植之后行为就可能悄悄改变，而没有任何编译错误提示。以 2024 Edition 里if let临时变量作用域的变化为例，在某些场景下会影响 drop 顺序，从而导致未定义行为。

Miguel Ojeda 明确提出了需求：需要一个零漏报（zero false negative rate）的工具，凡是语义有差异的情况都要被标记出来，不能有任何漏网之鱼。

TC 解释了当前工具链的局限——现有的迁移工具无法做出这种保证，尽管已经投入了大量测试工作。

Benno Lossin 提出了一个有意思的方向：写一个工具，把同一段代码分别在两个 Edition 下编译，对比生成的 MIR（Rust 的中间表示）。如果 MIR 相同，语义就相同；如果 MIR 不同，就标记出来让人工审查。这个方案可能产生误报（false positive），但至少能保证不漏报。理论上可行，但目前没有团队有带宽去做。

讨论最终提出了四个方向，各有权衡：

• 在内核的所有 stable branch 都升级到允许新 Edition 的 MSRV 之后，整体切换一次
• 开发上述的 MIR 对比工具（但没有人来做）
• 在内核侧建立针对反向移植 patch 的专门审查流程
• 把所有代码都写在所有 Edition 的交集范围内（限制性最大，但最安全）

这个问题没有快速答案，基本可以确定会在 All Hands 上继续讨论。

All Hands 已规划的 Rust for Linux 专题

以下五个议题将在 All Hands 上进行专题讨论：

• In-place Initialization（原地初始化）
• Field Projections（字段投影）
• CoccinelleForRust（语义补丁工具在 Rust 中的应用）
• Compiling Rust to BPF（Rust 编译到 BPF 字节码）
• Office Hours（开放答疑）

项目总监选举流程更新

2025 年秋季，Tomáš 主持了项目总监（Project Director）选举。按惯例，主持人需要事后发布复盘、澄清文档，并在必要时提议流程改进。

复盘文档已公开，流程说明的 PR 也已提交。这类"选举结束后的系统性复盘"在很多组织里是容易被忽略的事，但对于持续改进治理流程很重要。

近期值得关注的动态

Rust 1.95.0 正式发布，配套发布了一期版本更新解说视频。

GSoC 2026 入选项目公布，Google Summer of Code 今年继续支持 Rust 项目。

crates.io 新前端（Svelte 5）开放公测，体验地址：https://crates.io/svelte/。感兴趣的可以试用并提反馈。

WebAssembly 目标变更：对 Wasm 目标下未定义符号的处理方式有调整，会带来一处小范围 Breaking Change，Wasm 用户需要关注。

docs.rs 默认构建目标缩减：docs.rs 在为每个 crate 构建文档时，默认不再构建所有目标平台，只构建默认目标，减少资源消耗。

一组数字

原文末尾有一组统计数字，放在这里作为收尾：

• 551,300 字：2025 年 6 月至 2026 年 4 月，Program team 共写下的会议记录字数
• 45 次：这段时间内参与的会议次数
• 80,800 字：4 月单月的会议记录字数
• 各团队每次会议平均记录字数：Cargo 会议 1,900 字，Lang triage 3,100 字，Libs-API 4,700 字，Leadership Council 2,400 字

Rust 项目里有大量不直接产出代码的工作——协调、记录、跟进、推动——这些数字是对那部分工作量的一个侧面呈现。

小结

这份月报呈现的是 Rust 项目运转的一个横截面：技术讨论（C++ 互操作、Edition 迁移、标准库特性）、社区建设（Outreachy、内容团队）、治理事务（项目目标、选举复盘）同时在推进，每条线都有具体的负责人和明确的下一步。

对于关注 Rust 长期走向的人来说，几个信号值得持续跟踪：C++ 互操作从问题梳理进入了实验性实现阶段；Rust for Linux 的 Edition 兼容性问题可能会推动一些工具链层面的新工作；而 All Hands 这一周，将是很多积压讨论落地为决策的节点。

参考链接

• 原文：https://blog.rust-lang.org/inside-rust/2026/05/13/program-management-update–april-2026/
• 2026 项目目标 RFC：https://rust-lang.github.io/rfcs/3935-Project-Goals-2026.html
• C++ 互操作问题仓库：https://github.com/rustfoundation/interop-initiative/issues
• Outreachy 介绍博客：https://blog.rust-lang.org/2026/05/04/outreachy-2026-may/
• Rust 基金会互操作进展更新：https://rustfoundation.org/media/rust-foundation-interop-initiative-update-from-research-to-implementation/
• Rust 1.95.0 发布公告：https://blog.rust-lang.org/2026/04/16/Rust-1.95.0/
• RustWeek 2026：https://2026.rustweek.org/