本文基于 Rust 官方 Inside Rust 博客于 2026 年 4 月 9 日发布的《Program management update — March 2026》作者为 Tomas Sedovic 与 Nurzhan Saken代表 Program 团队发布。内容结构概览团队会议安排的新变化项目管理看板上线项目目标Project Goals最新进展FLS 发布说明流程改进crates.io 与 Rust 版本镜像Rust 基金会维护者基金RFMFRFCOutreachy 实习项目Rust for LinuxRust for CPythonDrop with contextSanitizer 兼容性未来会议安排近期值得关注的资讯数据统计一、团队会议安排的新变化随着 Nurzhan 完成入职适应他已经能够独立出席各团队会议不再需要与 Tomas 同时参加。这让两人得以平均分担会议工作量同时维持相同的 PM 覆盖水平。两人可以相互顶替缺席而各自的会议压力也降低了约一半。这是一个实质性的改善。参与决策现场、协助各方、将讨论记录留存固然有其价值但这也是高度消耗精力的工作——尤其是在连续安排了六七个小时背靠背会议的那些天。目前的会议分工仍在摸索调整之中但两人有意识地选择了不做功能分化双方都参与每个团队的讨论与各方人员建立彼此了解的关系。这样做有利于知识和上下文的共享也方便在其中一人无法出席时由另一人顶上。当然两人也保持着持续的沟通互相阅读对方参加的会议记录并确保跨会议需要跟进或移交的事项得到妥善处理。这种安排为两人腾出了更多精力去推进其他工作。会议层面还发生了两项变化其一Josh Triplett 提议暂时暂停 Style 团队的会议。过去数月以及更早之前的零散时期实际参会的 Style 团队成员只有两人。团队目前亟需补充成员rustfmt 亦然理想情况下还需要一位 rustfmt 联络人参与会议。在寻找解决方案的同时紧急事项暂时通过异步方式处理。其二两个 Libs-API 会议合并为一个。此前团队分别有一个会议用于处理被提名的 issue 和 PR另一个专门审议开放中的 API 变更提案ACP两者均在周二举行中间间隔一小时。然而两者之间的边界并不明确——如果第一个会议把提名积压清空了往往会自然地延伸到 ACP 的讨论。而与会者本来就希望直接继续。两次会议现已合并大家既能一气呵成地开完又能整体提前一小时结束——如果讨论特别耗神节省的时间还不止于此。二、项目管理看板上线Rust 项目管理看板已经填充了内容现在可以在上面看到团队正在推进的工作。这有助于更好地跟踪和协调各项工作同时也提升了透明度。看板地址https://github.com/orgs/rust-lang/projects/69/views/2三、项目目标Project Goals最新进展2026 项目目标 RFChttps://github.com/rust-lang/rfcs/pull/3935现已正式开放这是 Goals 团队过去数月工作的集中呈现。欢迎前往查看如有疑问可以访问 Zulip 上的 project-goals/2026-workshop 频道。如果你是某个团队的负责人请务必审阅 RFC并提出意见或在你负责的条目上打勾确认。与此同时2025 H2 目标周期也即将收尾。团队正在准备最后一次进展更新计划在 2026 RFC 合并后发布之后将全力投入 2026 目标周期的推进。2025 年的不少目标将延续至 2026 年周期这部分不会有太大变化原有的跟踪 issue、Zulip 频道等基础设施都将继续沿用。新增的目标将创建专属跟踪 issue所有进展更新都应发布于此并自动同步到对应的 Zulip 频道以便展开讨论。此外团队每月还会发送两次提醒督促目标负责人发布更新如果近期已有更新则不会重复发送提醒。四、FLS 发布说明流程改进FLSFerrocene Language Specification是 Rust 面向汽车等安全关键领域的语言规范文档最初由 Ferrous Systems 开发后捐赠给 Rust 项目现由 FLS 团队维护。作为稳定化 FLS 发布流程项目目标的一部分FLS 团队计划在每次 Rust 版本发布后六周内同步发布对应的 FLS 新版本。此前他们的工作方式是在 Rust 版本发布后逐条翻查发布说明找出需要反映到文档中的语言层面变更——这本质上是一种事后追赶式的流程。他们希望能提前介入但这需要在发布说明全部整理完毕之前就能拿到某次发布所包含的 issue 列表。为此Pete LeVasseur 联系了 Release 团队并达成协议尝试参与发布 issue 的早期分类流程。这样一来FLS 团队既能更深入地理解发布流程、提供帮助又能提前获取所需的 issue 列表实现双赢。这也是一个很好的提醒Rust 的发布流程是完全公开的https://forge.rust-lang.org/release/release-notes.html欢迎更多贡献者参与这也可以作为深度参与 Rust 社区贡献的一个较为友好的入口。五、crates.io 与 Rust 版本镜像三月初团队正式开放了实现可验证镜像原型https://rust-lang.github.io/rust-project-goals/2026/mirroring.html项目目标。这是此前签名探索工作的延续但聚焦范围更窄。目标是为 Rust crate 和发布版本建立镜像服务以解决 GitHub Actions 等高流量环境中的访问问题。该原型将验证所提议的技术方案例如使用 The Update Framework即 TUF来校验镜像更新以及密钥轮换机制同时提供能够实际减少带宽用量和成本的功能通过让 GitHub Actions 访问托管在 Azure 上的镜像来实现。相关功能将在不稳定特性标志unstable feature flag背后实现但一旦验证可行可以以此为基础构建更通用的镜像支持能力。在该目标的跟踪 issue 创建之前进展更新将发布在 Zulip 的 tbd-signing 频道中。六、Rust 基金会维护者基金RFMFRFC早在 2025 年 12 月团队就提及了维护者基金的计划以及 RFMF 设计委员会的成立。设计委员会随后采访了几个拥有类似项目的开源组织包括 Python Software Foundation、Scala Center、Django 和 Zig Software Foundation并在此基础上提出了一份 RFChttps://github.com/rust-lang/rfcs/pull/3931。该 RFC 提出设立常驻维护者Maintainer in Residence角色常驻维护者项目致力于雇用长期维护者并为其全职维护工作提供资金支持。常驻维护者的时间在两类优先事项之间分配一类是他们所支持的团队给出的指导性优先事项另一类是他们在项目内自主选择的优先事项。这些维护者预期是在社区中有良好声誉的项目成员能够长期致力于保持项目的健康运转与持续演进。RFC 同时提议组建一个资助团队与 Leadership Council 共同遴选候选人并确保整个项目的顺利推进。这一计划与另一个资助项目提案https://github.com/rust-lang/rfcs/pull/3919形成互补——后者面向已经在为项目做出有价值贡献的人提供为期十二个月的资金支持。他们不是被雇用或签约而是以此认可他们出色的工作并帮助他们更好地持续下去。七、Outreachy 实习项目Rust 项目正式参与 Outreachyhttps://www.outreachy.org/这是一个面向科技行业中代表性不足群体的带薪开源实习项目。Leadership Council 为 2026 年 5 月至 8 月的实习周期拨款提供三个实习名额。目前共有五个项目可供申请向现有 C/C 构建系统中添加 Rust 支持从 Rust 调用重载的 C 函数大规模对 Rust 编译器进行代码覆盖率测量对 a-mir-formality 类型系统实现进行模糊测试改进 GitHub Actions 的安全性目前处于贡献期阶段申请者需要向项目提交贡献这些贡献将作为选拔实习生的重要依据。Tomas 对此表达了个人的由衷喜悦——他对 Outreachy 所做的事情和所代表的价值观深表认同也与多位曾参与该项目的人共事过对他们印象极佳。特别感谢 Jack Huey 负责组织这一切同时感谢 Niko、Rémy、tiif、teor、Joel Marcey 和 Ethan Smith 报名担任导师和联合导师。八、Rust for Linux负责常量泛型const generics目标的 Boxy 希望了解哪些方向对 Rust for Linux 团队最为重要。常量泛型这把大伞下涵盖了大量功能点明确优先级至关重要。Rust for Linux 团队重点提出了以下三个方向1. 对常量泛型类型执行算术运算内核中存在一个类型Bounded它同时持有一个值和一个最大位宽两者均为常量值。团队希望能对这类类型进行算术运算从位移运算开始从而在编译期保证结果不超出指定的位宽范围。2. 参数位置常量泛型Argument-position const generics目前常量泛型类型必须写在尖括号内的类型约束区域例如必须写成Bounded::u8, 4::new::7()而不是更自然的Bounded::u8, 4::new(7)。当涉及编译期计算而非简单数值常量时情况会更复杂——还需要用花括号包裹{ ... }。3. 支持数值以外的类型作为泛型参数指针类型将对 asm_const_ptr 很有用字符串字面量也很实用哪怕只是作为透传参数不做任何处理或操作。如果从支持透传字符串出发进而能透传任意类型将有助于团队用枚举enum替换掉目前大量使用的类型状态typestate模式。其他进展Gary 为内核添加了一套通过宏实现指针投影的基础设施dma_read!/dma_write!宏已经切换至这套新机制。值得注意的是这完全通过宏实现并未使用任何字段投影Field projections语言特性。未来字段投影的语法和 trait 支持将使这一工作更加符合人体工学并可以借助借用检查器接受更多合法代码。在字段投影方面Lang 团队召开了一次设计会议讨论了 Benno Lossin、Nadrieril 和 Tyler Mandry 联合提出的最新方案——通过虚拟 PlaceVirtual Places实现字段投影。相关提案和会议记录可在字段投影项目目标页面查阅https://rust-lang.github.io/rust-project-goals/2026/field-projections.html。此外作为此前 rustfmtuse语句讨论的后续Tomas 提交了一个 issuehttps://github.com/rust-lang/rustfmt/issues/6829要求支持将 import 语句保持在单独行上的格式化方式以满足 Rust for Linux 的需求从而避免使用尾部//注释作为变通手段。九、Rust for CPython三月份团队与 CPython 方面进行了一次会议。Drop with context带上下文的析构Python 对象是引用计数指针。在任何给定时刻这些对象要么附着在 Python 解释器上要么处于分离状态。当处于附着状态时其引用计数可以增减但若要进行任何原生调用则必须先解除与解释器的关联。这类指针无法实现Clone或Droptrait因为 trait 的实现不知道对象当时是否附着于解释器状态。如何在 Rust 中对此进行建模同时保证安全性与易用性是一个尚未解决的开放问题。David Hewitt 就带上下文的 DropDrop with context特性展开了咨询——该特性要求在调用drop函数时隐式传入一个关联上下文例如指向 Python 解释器状态的指针。这是 Rust 项目一直在思考的方向可参见 Tyler Mandry 2021 年的博客文章、Nadrieril 近期发布的《What If Traits Carried Values》以及相关的 2026 年字典传递风格实验目标提案。David、Josh Triplett 和 Jack Huey 计划在 Zulip 上以及 2026 年 All Hands 期间继续深入讨论这一议题。Sanitizer 兼容性CPython 在 CI 中运行多种 sanitizer包括 AddressSanitizer/ASan、MemorySanitizer/MemSan、UndefinedBehaviorSanitizer/UBSan 和 ThreadSanitizer/TSan以对 C 代码进行额外的合规性检查这对 Python 的内存安全至关重要。Emma Smith 希望确认 LLVM 和 GCC 的 sanitizer 是否可以混用——答案是否定的。引入 Rust 后Python 解释器中的 C 代码部分将不得不使用 Clang 进行编译并使用 Clang 自带的 sanitizer同时需要确保这些 sanitizer 与原有的覆盖范围一致。团队还询问了 LLVM 各版本间的兼容性问题因为 Rust 使用了自己维护的 LLVM fork。结论是LLVM 主版本之间互不兼容但 Rust 的 fork 与对应的上游版本应当是兼容的Rust 会向自己的 fork 中移植上游的 bug 修复也支持使用原版 LLVM 进行构建。此外由 Rust for Linux 推动的稳定化 MemorySanitizer 和 ThreadSanitizerhttps://rust-lang.github.io/rust-project-goals/2026/stabilization-of-sanitizer-support.html工作也在持续推进中。未来会议安排本月初之后双方暂时没有新议题会议因此暂时搁置。有新话题出现时将重新开始但目前阶段双方各自都有大量的实际工作要推进。Rust 和 CPython 两侧的团队计划在 2026 年 All Hands 期间举行一次联合会议。与此同时Emma Smith 从 CPython 视角发布了一篇进展更新https://blog.python.org/2026/04/rust-for-cpython-2026-04/。团队已完成构建系统的相关工作并通过了 CPython 的 CI 验证。接下来数月他们将规划内部 Rust API 的设计之后撰写 PEPPython Enhancement Proposal类似于 Rust 的 RFC目标版本为 Python 3.16。十、近期值得关注的资讯Rust 基金会文章Canonical 以黄金会员身份加入 Rust 基金会https://rustfoundation.org/media/canonical-joins-the-rust-foundation-as-a-gold-member/Rust 创新实验室的下一步计划https://rustfoundation.org/media/whats-next-for-the-rust-innovation-lab/Rust 项目动态Rust 1.94.0 正式发布https://blog.rust-lang.org/2026/03/05/Rust-1.94.0/以及 1.94.1https://blog.rust-lang.org/2026/03/26/1.94.1-release/Cargo 安全公告https://blog.rust-lang.org/2026/03/21/cve-2026-33056/WebAssembly 目标与未定义符号处理变更https://blog.rust-lang.org/2026/04/04/changes-to-webassembly-targets-and-handling-undefined-symbols/破坏性变更预警影响 WebAssembly 构建docs.rs默认构建目标减少https://blog.rust-lang.org/2026/04/04/docsrs-only-default-targets/破坏性变更预警将于 2026 年 5 月 1 日生效我们听到了哪些关于 Rust 挑战的声音https://blog.rust-lang.org/2026/03/20/rust-challenges/rustup 1.29.0 正式发布https://blog.rust-lang.org/2026/03/12/Rustup-1.29.0/2025 年 Rust 状态调查结果https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/测试征集构建目录布局 v2https://blog.rust-lang.org/2026/03/13/call-for-testing-build-dir-layout-v2/自 Cargo 1.91 起中间构建产物build-dir和最终产物target-dir可以分离存放。Cargo 正在调整build-dir的目录结构target 目录布局不变征集用户测试以发现诸如构建脚本依赖目录结构来推断 target_dir 或可执行文件路径等问题欢迎参与测试并反馈2026 年 1 月 2 月项目董事更新https://blog.rust-lang.org/inside-rust/2026/03/25/project-director-update/Leadership Council 更新 — 2026 年 3 月https://blog.rust-lang.org/inside-rust/2026/04/06/leadership-council-update/Rémy Rakic 担任编译器团队代表Josh Triplett 担任 Libs 团队代表十一、数据统计以下数据反映了 Program 团队 3 月份的工作量会议记录总字数2025 年 6 月 — 2026 年 3 月470,500 字参加会议总场次3 月35 场3 月份会议记录字数73,800 字各团队单次会议平均字数Cargo1,900 字Lang triage3,300 字Libs-API4,300 字Leadership Council2,400 字原文地址https://blog.rust-lang.org/inside-rust/2026/04/09/program-management-update-2026-03/作者Tomas Sedovic、Nurzhan Saken代表 Program 团队
Rust 项目管理动态 — 2026 年 3 月
发布时间：2026/6/12 13:40:14
本文基于 Rust 官方 Inside Rust 博客于 2026 年 4 月 9 日发布的《Program management update — March 2026》作者为 Tomas Sedovic 与 Nurzhan Saken代表 Program 团队发布。内容结构概览团队会议安排的新变化项目管理看板上线项目目标Project Goals最新进展FLS 发布说明流程改进crates.io 与 Rust 版本镜像Rust 基金会维护者基金RFMFRFCOutreachy 实习项目Rust for LinuxRust for CPythonDrop with contextSanitizer 兼容性未来会议安排近期值得关注的资讯数据统计一、团队会议安排的新变化随着 Nurzhan 完成入职适应他已经能够独立出席各团队会议不再需要与 Tomas 同时参加。这让两人得以平均分担会议工作量同时维持相同的 PM 覆盖水平。两人可以相互顶替缺席而各自的会议压力也降低了约一半。这是一个实质性的改善。参与决策现场、协助各方、将讨论记录留存固然有其价值但这也是高度消耗精力的工作——尤其是在连续安排了六七个小时背靠背会议的那些天。目前的会议分工仍在摸索调整之中但两人有意识地选择了不做功能分化双方都参与每个团队的讨论与各方人员建立彼此了解的关系。这样做有利于知识和上下文的共享也方便在其中一人无法出席时由另一人顶上。当然两人也保持着持续的沟通互相阅读对方参加的会议记录并确保跨会议需要跟进或移交的事项得到妥善处理。这种安排为两人腾出了更多精力去推进其他工作。会议层面还发生了两项变化其一Josh Triplett 提议暂时暂停 Style 团队的会议。过去数月以及更早之前的零散时期实际参会的 Style 团队成员只有两人。团队目前亟需补充成员rustfmt 亦然理想情况下还需要一位 rustfmt 联络人参与会议。在寻找解决方案的同时紧急事项暂时通过异步方式处理。其二两个 Libs-API 会议合并为一个。此前团队分别有一个会议用于处理被提名的 issue 和 PR另一个专门审议开放中的 API 变更提案ACP两者均在周二举行中间间隔一小时。然而两者之间的边界并不明确——如果第一个会议把提名积压清空了往往会自然地延伸到 ACP 的讨论。而与会者本来就希望直接继续。两次会议现已合并大家既能一气呵成地开完又能整体提前一小时结束——如果讨论特别耗神节省的时间还不止于此。二、项目管理看板上线Rust 项目管理看板已经填充了内容现在可以在上面看到团队正在推进的工作。这有助于更好地跟踪和协调各项工作同时也提升了透明度。看板地址https://github.com/orgs/rust-lang/projects/69/views/2三、项目目标Project Goals最新进展2026 项目目标 RFChttps://github.com/rust-lang/rfcs/pull/3935现已正式开放这是 Goals 团队过去数月工作的集中呈现。欢迎前往查看如有疑问可以访问 Zulip 上的 project-goals/2026-workshop 频道。如果你是某个团队的负责人请务必审阅 RFC并提出意见或在你负责的条目上打勾确认。与此同时2025 H2 目标周期也即将收尾。团队正在准备最后一次进展更新计划在 2026 RFC 合并后发布之后将全力投入 2026 目标周期的推进。2025 年的不少目标将延续至 2026 年周期这部分不会有太大变化原有的跟踪 issue、Zulip 频道等基础设施都将继续沿用。新增的目标将创建专属跟踪 issue所有进展更新都应发布于此并自动同步到对应的 Zulip 频道以便展开讨论。此外团队每月还会发送两次提醒督促目标负责人发布更新如果近期已有更新则不会重复发送提醒。四、FLS 发布说明流程改进FLSFerrocene Language Specification是 Rust 面向汽车等安全关键领域的语言规范文档最初由 Ferrous Systems 开发后捐赠给 Rust 项目现由 FLS 团队维护。作为稳定化 FLS 发布流程项目目标的一部分FLS 团队计划在每次 Rust 版本发布后六周内同步发布对应的 FLS 新版本。此前他们的工作方式是在 Rust 版本发布后逐条翻查发布说明找出需要反映到文档中的语言层面变更——这本质上是一种事后追赶式的流程。他们希望能提前介入但这需要在发布说明全部整理完毕之前就能拿到某次发布所包含的 issue 列表。为此Pete LeVasseur 联系了 Release 团队并达成协议尝试参与发布 issue 的早期分类流程。这样一来FLS 团队既能更深入地理解发布流程、提供帮助又能提前获取所需的 issue 列表实现双赢。这也是一个很好的提醒Rust 的发布流程是完全公开的https://forge.rust-lang.org/release/release-notes.html欢迎更多贡献者参与这也可以作为深度参与 Rust 社区贡献的一个较为友好的入口。五、crates.io 与 Rust 版本镜像三月初团队正式开放了实现可验证镜像原型https://rust-lang.github.io/rust-project-goals/2026/mirroring.html项目目标。这是此前签名探索工作的延续但聚焦范围更窄。目标是为 Rust crate 和发布版本建立镜像服务以解决 GitHub Actions 等高流量环境中的访问问题。该原型将验证所提议的技术方案例如使用 The Update Framework即 TUF来校验镜像更新以及密钥轮换机制同时提供能够实际减少带宽用量和成本的功能通过让 GitHub Actions 访问托管在 Azure 上的镜像来实现。相关功能将在不稳定特性标志unstable feature flag背后实现但一旦验证可行可以以此为基础构建更通用的镜像支持能力。在该目标的跟踪 issue 创建之前进展更新将发布在 Zulip 的 tbd-signing 频道中。六、Rust 基金会维护者基金RFMFRFC早在 2025 年 12 月团队就提及了维护者基金的计划以及 RFMF 设计委员会的成立。设计委员会随后采访了几个拥有类似项目的开源组织包括 Python Software Foundation、Scala Center、Django 和 Zig Software Foundation并在此基础上提出了一份 RFChttps://github.com/rust-lang/rfcs/pull/3931。该 RFC 提出设立常驻维护者Maintainer in Residence角色常驻维护者项目致力于雇用长期维护者并为其全职维护工作提供资金支持。常驻维护者的时间在两类优先事项之间分配一类是他们所支持的团队给出的指导性优先事项另一类是他们在项目内自主选择的优先事项。这些维护者预期是在社区中有良好声誉的项目成员能够长期致力于保持项目的健康运转与持续演进。RFC 同时提议组建一个资助团队与 Leadership Council 共同遴选候选人并确保整个项目的顺利推进。这一计划与另一个资助项目提案https://github.com/rust-lang/rfcs/pull/3919形成互补——后者面向已经在为项目做出有价值贡献的人提供为期十二个月的资金支持。他们不是被雇用或签约而是以此认可他们出色的工作并帮助他们更好地持续下去。七、Outreachy 实习项目Rust 项目正式参与 Outreachyhttps://www.outreachy.org/这是一个面向科技行业中代表性不足群体的带薪开源实习项目。Leadership Council 为 2026 年 5 月至 8 月的实习周期拨款提供三个实习名额。目前共有五个项目可供申请向现有 C/C 构建系统中添加 Rust 支持从 Rust 调用重载的 C 函数大规模对 Rust 编译器进行代码覆盖率测量对 a-mir-formality 类型系统实现进行模糊测试改进 GitHub Actions 的安全性目前处于贡献期阶段申请者需要向项目提交贡献这些贡献将作为选拔实习生的重要依据。Tomas 对此表达了个人的由衷喜悦——他对 Outreachy 所做的事情和所代表的价值观深表认同也与多位曾参与该项目的人共事过对他们印象极佳。特别感谢 Jack Huey 负责组织这一切同时感谢 Niko、Rémy、tiif、teor、Joel Marcey 和 Ethan Smith 报名担任导师和联合导师。八、Rust for Linux负责常量泛型const generics目标的 Boxy 希望了解哪些方向对 Rust for Linux 团队最为重要。常量泛型这把大伞下涵盖了大量功能点明确优先级至关重要。Rust for Linux 团队重点提出了以下三个方向1. 对常量泛型类型执行算术运算内核中存在一个类型Bounded它同时持有一个值和一个最大位宽两者均为常量值。团队希望能对这类类型进行算术运算从位移运算开始从而在编译期保证结果不超出指定的位宽范围。2. 参数位置常量泛型Argument-position const generics目前常量泛型类型必须写在尖括号内的类型约束区域例如必须写成Bounded::u8, 4::new::7()而不是更自然的Bounded::u8, 4::new(7)。当涉及编译期计算而非简单数值常量时情况会更复杂——还需要用花括号包裹{ ... }。3. 支持数值以外的类型作为泛型参数指针类型将对 asm_const_ptr 很有用字符串字面量也很实用哪怕只是作为透传参数不做任何处理或操作。如果从支持透传字符串出发进而能透传任意类型将有助于团队用枚举enum替换掉目前大量使用的类型状态typestate模式。其他进展Gary 为内核添加了一套通过宏实现指针投影的基础设施dma_read!/dma_write!宏已经切换至这套新机制。值得注意的是这完全通过宏实现并未使用任何字段投影Field projections语言特性。未来字段投影的语法和 trait 支持将使这一工作更加符合人体工学并可以借助借用检查器接受更多合法代码。在字段投影方面Lang 团队召开了一次设计会议讨论了 Benno Lossin、Nadrieril 和 Tyler Mandry 联合提出的最新方案——通过虚拟 PlaceVirtual Places实现字段投影。相关提案和会议记录可在字段投影项目目标页面查阅https://rust-lang.github.io/rust-project-goals/2026/field-projections.html。此外作为此前 rustfmtuse语句讨论的后续Tomas 提交了一个 issuehttps://github.com/rust-lang/rustfmt/issues/6829要求支持将 import 语句保持在单独行上的格式化方式以满足 Rust for Linux 的需求从而避免使用尾部//注释作为变通手段。九、Rust for CPython三月份团队与 CPython 方面进行了一次会议。Drop with context带上下文的析构Python 对象是引用计数指针。在任何给定时刻这些对象要么附着在 Python 解释器上要么处于分离状态。当处于附着状态时其引用计数可以增减但若要进行任何原生调用则必须先解除与解释器的关联。这类指针无法实现Clone或Droptrait因为 trait 的实现不知道对象当时是否附着于解释器状态。如何在 Rust 中对此进行建模同时保证安全性与易用性是一个尚未解决的开放问题。David Hewitt 就带上下文的 DropDrop with context特性展开了咨询——该特性要求在调用drop函数时隐式传入一个关联上下文例如指向 Python 解释器状态的指针。这是 Rust 项目一直在思考的方向可参见 Tyler Mandry 2021 年的博客文章、Nadrieril 近期发布的《What If Traits Carried Values》以及相关的 2026 年字典传递风格实验目标提案。David、Josh Triplett 和 Jack Huey 计划在 Zulip 上以及 2026 年 All Hands 期间继续深入讨论这一议题。Sanitizer 兼容性CPython 在 CI 中运行多种 sanitizer包括 AddressSanitizer/ASan、MemorySanitizer/MemSan、UndefinedBehaviorSanitizer/UBSan 和 ThreadSanitizer/TSan以对 C 代码进行额外的合规性检查这对 Python 的内存安全至关重要。Emma Smith 希望确认 LLVM 和 GCC 的 sanitizer 是否可以混用——答案是否定的。引入 Rust 后Python 解释器中的 C 代码部分将不得不使用 Clang 进行编译并使用 Clang 自带的 sanitizer同时需要确保这些 sanitizer 与原有的覆盖范围一致。团队还询问了 LLVM 各版本间的兼容性问题因为 Rust 使用了自己维护的 LLVM fork。结论是LLVM 主版本之间互不兼容但 Rust 的 fork 与对应的上游版本应当是兼容的Rust 会向自己的 fork 中移植上游的 bug 修复也支持使用原版 LLVM 进行构建。此外由 Rust for Linux 推动的稳定化 MemorySanitizer 和 ThreadSanitizerhttps://rust-lang.github.io/rust-project-goals/2026/stabilization-of-sanitizer-support.html工作也在持续推进中。未来会议安排本月初之后双方暂时没有新议题会议因此暂时搁置。有新话题出现时将重新开始但目前阶段双方各自都有大量的实际工作要推进。Rust 和 CPython 两侧的团队计划在 2026 年 All Hands 期间举行一次联合会议。与此同时Emma Smith 从 CPython 视角发布了一篇进展更新https://blog.python.org/2026/04/rust-for-cpython-2026-04/。团队已完成构建系统的相关工作并通过了 CPython 的 CI 验证。接下来数月他们将规划内部 Rust API 的设计之后撰写 PEPPython Enhancement Proposal类似于 Rust 的 RFC目标版本为 Python 3.16。十、近期值得关注的资讯Rust 基金会文章Canonical 以黄金会员身份加入 Rust 基金会https://rustfoundation.org/media/canonical-joins-the-rust-foundation-as-a-gold-member/Rust 创新实验室的下一步计划https://rustfoundation.org/media/whats-next-for-the-rust-innovation-lab/Rust 项目动态Rust 1.94.0 正式发布https://blog.rust-lang.org/2026/03/05/Rust-1.94.0/以及 1.94.1https://blog.rust-lang.org/2026/03/26/1.94.1-release/Cargo 安全公告https://blog.rust-lang.org/2026/03/21/cve-2026-33056/WebAssembly 目标与未定义符号处理变更https://blog.rust-lang.org/2026/04/04/changes-to-webassembly-targets-and-handling-undefined-symbols/破坏性变更预警影响 WebAssembly 构建docs.rs默认构建目标减少https://blog.rust-lang.org/2026/04/04/docsrs-only-default-targets/破坏性变更预警将于 2026 年 5 月 1 日生效我们听到了哪些关于 Rust 挑战的声音https://blog.rust-lang.org/2026/03/20/rust-challenges/rustup 1.29.0 正式发布https://blog.rust-lang.org/2026/03/12/Rustup-1.29.0/2025 年 Rust 状态调查结果https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/测试征集构建目录布局 v2https://blog.rust-lang.org/2026/03/13/call-for-testing-build-dir-layout-v2/自 Cargo 1.91 起中间构建产物build-dir和最终产物target-dir可以分离存放。Cargo 正在调整build-dir的目录结构target 目录布局不变征集用户测试以发现诸如构建脚本依赖目录结构来推断 target_dir 或可执行文件路径等问题欢迎参与测试并反馈2026 年 1 月 2 月项目董事更新https://blog.rust-lang.org/inside-rust/2026/03/25/project-director-update/Leadership Council 更新 — 2026 年 3 月https://blog.rust-lang.org/inside-rust/2026/04/06/leadership-council-update/Rémy Rakic 担任编译器团队代表Josh Triplett 担任 Libs 团队代表十一、数据统计以下数据反映了 Program 团队 3 月份的工作量会议记录总字数2025 年 6 月 — 2026 年 3 月470,500 字参加会议总场次3 月35 场3 月份会议记录字数73,800 字各团队单次会议平均字数Cargo1,900 字Lang triage3,300 字Libs-API4,300 字Leadership Council2,400 字原文地址https://blog.rust-lang.org/inside-rust/2026/04/09/program-management-update-2026-03/作者Tomas Sedovic、Nurzhan Saken代表 Program 团队
