项目目标更新 — 2026年4月（2025年下半年）

来源： Rust Blog
作者： Nurzhan Saken
发布时间： 2026年5月18日 08:00:00
原文链接： https://blog.rust-lang.org/2026/05/18/project-goals-2026-04/

2025H2 项目目标（Project Goal）时期现已结束。在这几个月里，Rust 项目朝着 41 个项目目标 前进，其中 13 个被指定为 旗舰目标。本文包含自 上一篇文章 以来的进展更新，以及每个目标的最终状态（其中许多目标将作为 2026 年时期的一部分继续推进）。有关特定目标的完整细节，请参见其 跟踪问题。

感谢所有贡献者！<3

目录

8 / p r o j e c t – g o a l s – 2 0 2 6 – 0 4 / # s v e – a n d – s m e – o n – a a r c h 6 4 )
– Type System Documentation
– Unsafe Fields

旗舰项目：超越 &

持续试验 Pin 人体工程学（Pin Ergonomics）

以下提供 3 条详细更新。

设计语言特性以解决字段投影（Field Projections）问题

以下提供 5 条详细更新。

以下是翻译后的内容，保留所有 Markdown 格式，技术名词首次出现时附英文，代码、URL、路径等不翻译：

field projections（字段投影），并编写在结构体字段上通用的函数。例如，可以编写如下的代码：

`

#![feature(field_projections)]

use std::field::{Field, field_of};

use std::ptr;

fn project_ref<‘a, T, F: Field>(r: &’a T) -> &’a F::Type {

// SAFETY: Field trait 保证这是安全的。

unsafe { &*ptr::from_ref(r).byte_add(F::OFFSET).cast() }

}

struct Struct {

define Struct {

field: i32,

other: u32,

}

fn main() {

let s = Struct { field: 42, other: 24 };

let r = &s;

let field = project_ref::<_, field_of!(Struct, field)>(r);

let other = project_ref::<_, field_of!(Struct, other)>(r);

println!(“field: {field}”); // 输出 42

println!(“other: {other}”); // 输出 24

}

`

field_of! 返回的类型的一个非常重要的特性是：如果你拥有基类型（base type），你可以为这些类型实现 trait（特质）。这允许通过扩展 Field trait 来为字段附加信息。例如，这可以编码“结构上固定的字段”（structurally pinned field）这一属性：

`

use std::pin::Pin;

unsafe trait PinnableField: Field {

type StructuralRefMut<‘a>

where

Self::Type: ‘a,

Self::Base: ‘a;

fn project_mut<‘a>(base: Pin<&’a mut Self::Base>) -> Self::StructuralRefMut<‘a>

where

Self::Type: ‘a,

Self::Base: ‘a;

}

fn project_pinned<‘a, T, F>(r: Pin<&’a mut T>) -> ::StructuralRefMut<‘a>

where

F: PinnableField,

{

F::project_mut(r)

}

`

然后，我们可以为结构体的所有字段实现这个额外的 trait（并通过过程宏自动化实现）：

`

unsafe impl PinnableField for field_of!(Struct, field) {

type StructuralRefMut<‘a> = &’a mut i32;

fn project_mut<‘a>(base: Pin<&’a mut Self::Base>) -> Self::StructuralRefMut<‘a>

where

Self::Type: ‘a,

Self::Base: ‘a,

{

let base = unsafe { Pin::into_inner_unchecked(base) };

&mut base.field

}

}

}

unsafe impl PinnableField for field_of!(Struct, other) {

type StructuralRefMut<‘a> = Pin<&’a mut u32>;

// u32 是 Unpin，所以这并没有做什么特别的事情，但它突显了这种模式。

fn project_mut<‘a>(base: Pin<&’a mut Self::Base>) -> Self::StructuralRefMut<‘a>

where

Self::Type: ‘a,

Self::Base: ‘a,

{

let base = unsafe { Pin::into_inner_unchecked(base) };

unsafe { Pin::new_unchecked(&mut base.other) }

}

}

`

现在，你可以通过调用 project_pinned 函数并传入正确的 FRT（关联类型），安全地获得对 other 的固定可变引用（pinned mutable reference）以及对 field 的正常可变引用。

（normal mutable reference）。

（playground 链接）

  • Benno Lossin —— 2026-03-20 的评论

    2026 年计划

    对于 2026 年，我们有一个更新后的计划，包括三个主要步骤：


    • a-mir-formality，

    • 实现（Implementation），

    • 实验（Experimentation）。

    其中一些子任务依赖于其他步骤的子任务。你可以在更新后的跟踪问题中找到详细信息。以下是对每个步骤的简要概述：

    a-mir-formality: 我们希望为我们提议的借用检查器变更创建一个形式化模型（formal model），以确保正确性。我们还希望创建一个文档，用更易读的语言解释我们的模型。要真正开始这项工作，我们被阻塞在……


n e w e x p r e s s i o n b a s e d s y n t a x i n d e v e l o p m e n t b y N i k o .

实现： 与此同时，我们可以开始在编译器中实现更多部分。我们将继续改进 FRTS（字段相关类型系统），同时铭记如果它们最终变得不必要，我们可能会移除它们。它们仍然是一个有用的特性，但可能与字段投影（field projections）正交。我们计划从库的添加开始，进行小而渐进的修改。我们也希望开始探索潜在的脱糖（desugaring）方式，为此我们将添加一些手动和底层的宏。一旦我们明确了这一点，我们就可以快速推进语法变更。当我们对借用检查器集成拥有了足够成熟的正式模型后，我们会将其移植到编译器中。经过进一步评估后，我们可以考虑移除 incomplete_feature（不完整特性）标记。

实验： 每次编译器或标准库变更后，我们都会考察多个项目，在实际代码中对我们的想法进行压力测试。我将负责在 Linux 内核中进行实验，而 Tyler Mandry 将负责使用 crubit 测试字段投影。Josh Triplett 也表达了在标准库中引入它们的热切愿望；我将与他以及 t-libs-api 团队的其他成员协调，在那里进行实验。

  • Benno Lossin — 来自 2026-04-02 的评论


    昨天，我们就当前的方法举行了一次 t-lang 设计会议。Nadrieril 和我根据 Tyler Mandry、Ding Xiang Fei、Alice Ryhl 以及 Gary Guo 的反馈，撰写了一份设计文档。在这份文档中，我们阐述了这一特性的动机，一个适合 Rust 现有特性的解决方案的外观和感觉，以及基于虚拟位置（virtual places）的当前方法的全面且紧凑的介绍。

    总体反响极为积极。以下是会议中的一些具体引述：


    • Josh：

      > 我喜爱这个！我非常欣赏它的正交性，以及它所具有的影响力和普适性。我预计这将成为一个深受喜爱的、无处不在的 Rust 特性。

      >

      > 位置和投影在我看来非常重要，值得我们将剩余宝贵的 ASCII 符号之一赋予它们，而 @ 能很好地唤起“位置”的概念（某物位于一个位置）。因此，就最终语法需要符号来说，我 :+1: 赞成赋予它 @。（不过，具体细节请参见下面的反馈。）


    • TC：

      > 很棒。概念很高。正如我在上次会议上所说：



> 我特别喜欢那些能减少库表面（library surface area）需求的语言特性，这正是一个这样的特性。

当然，还有许多细节需要进一步明确和解决，例如关于迁移问题、与 const、async 及其他类似效果（effect-like）的交互等。我很期待看到形式化（formalization）工作的成果。

– tmandry:

> 我喜欢这个方向的一点在于，它多么有效地建立在 Rust 已有的基础之上。我乐于看到那些强化我们现有概念，同时又推动它们朝着更具表现力方向发展的设计。

– Jack:

> 哇哦。这太棒了。这里面的内容太多了，我简直不知道该从哪里开始评论。我认为，只有经过一定量的实验，我们才能真正搞清楚其中的细微细节和人体工程学（ergonomics）问题。

这次会议得出以下几点结论：

  • **Mark 提出了 concern（担忧），认为 t-libs（Rust 库团队）应该更多地参与审查我们计划添加的实验性 trait（experimental traits）。确保我们不会意外地稳定（stabilize）或暴露某些行为，对我们的实验性 trait 提供充分的文档，并且让 t-libs 总体上了解该特性的进展。
  • Mark 主动提出审查 PR，我会在相关 PR 中标记他。

Jack 提出了 concern，认为应避免增加 95% 用例的认知负担（cognitive load）。让用户在 @ 和 & 之间做出正确选择可能具有挑战性。
– 我们在会议中进一步讨论了这一点，并得出结论，我们需要进行一些实验，可能利用用户研究团队（user research team）的力量。我们当然会记住这一点，并在有了部分可工作的实现后重新审视。

TC 要求我们发布精细的设计原则（fine-grained design axioms），基本上就是我们在考虑修改提案时需要逐一核对的事项清单。
– 我会就此问题撰写一篇更新，详细解释这些原则。

除了这些 concern 和可直接执行的事项外，会议还涵盖了我们希望在未来几周/几个月内研究的设计问题/评论：

– 我们能否支持一种携带对齐信息（alignment information）并在投影（projection）时更新的指针？

– 我们需要或希望支持与效应（effect）的何种兼容性？

– 引入字段投影（field projections）会关闭未来指针人体工程学改进的哪些可能性？

感谢所有参与会议的人！

Reborrow traits（重新借用 trait）

提供了 1 条详细更新。

  • Aapo Alasuutari — 2026-02-28 的评论


    PR 已提交，旨在将 Reborrow 和 CoerceShared trait 的首个可工作版本合并。 `Coerce

    阻碍项

    当前“受阻于” PR 审核，当然也取决于我（以及 Ding）修复所有审核问题的工作进度。

    审核过程中提出了一个机会：用更通用的变体替换 Rvalue::Ref / ExprKind::Ref，使其既能涵盖引用也能涵盖用户定义的引用。这功能强大，但会是一次巨大且令人担忧的变更。如果这对审核者构成了阻碍，那么在可预见的未来此的将来，该目标将被阻塞，因为 PR 将从此开始大规模重构。

    寻求帮助

    当前 PR 未包含 derive traits（派生 trait），但我们非常需要它们。与其写成这样：

    `

    impl<‘a> Reborrow for CustomMarker<‘a> {}

    impl<‘a> CoerceShared<CustomMarkerRef<‘a>> for CustomMarker<a’> {}

    Coerce

    impl<‘a, T> Reborrow for CustomMut<‘a, T> {}

    impl<‘a, T>Shared<CustomRef<‘a, T>> for CustomMut<‘a, T> {}

    Coerce

    `

    我们更希望能写成这样：

    `

    [derive(Reborrow,Shared(CustomMarkerRef))]

    Coerce

    struct CustomMarker<‘a> { … }

    [derive(Reborrow,Shared(CustomRef))]

    (Reborrow, Coerce

    struct CustomMut<‘a, T> { … }

    `

    如果有人愿意接手这个线索，那就太棒了：derive 宏不需要真正执行任何有效性检查，因为 trait 本身会完成这项工作。

    如果 PR 很快合并，那么接下来重要的将是公开测试和对这些 trait 的探索。同时，很可能还要进行大规模重构，以泛化 Rvalue::Ref / ExprKind::Ref。


旗舰目标：灵活、快速（更快）的编译

build-std（构建标准库）

提供了 4 条详细更新。

Production-ready cranelift 后端

推进并行前端

重新链接，不要重新构建

Flagship: Higher-level Rust

易用引用计数：RFC 决策与预览

稳定 cargo 脚本稳定化

3 条详细更新可用。

旗舰项目：解除休眠 trait 的阻塞 (Flagship: Unblocking dormant traits)

演进中的 trait 层次结构 (Evolving trait hierarchies)

原地初始化 (In-place initialization)

提供了 1 个详细更新。

下一代 trait 求解器 (Next-generation trait solver)

提供了 1 个详细更新。

在 nightly 上可稳定的 Polonius 支持

已有 2 份详细更新。

  • Rémy Rakic — 2026-01-30 的评论


    本月的更新内容：


    • tiif 在在计算隐含边界（implied bounds）时对不透明类型（opaques）进行规范化方面取得了进展。

    • 我们讨论了如何调查并修复 Tage 工作中剩余的正确性问题，以便更准确地评估它：特别是关于变体（variance）和双向边（bidirectional edges）的问题，以及不依赖 NLL（即通过计算区域值 / 错误）的情况。

    • 我们尝试了是否可能移除 cfg 区域元素（cfg region elements）。

    • Amanda 仍在撰写两篇论文，一篇关于当前的借用检查器（borrow checker），另一篇关于 Polonius 的工作。她关于在区域推断（region inference）期间重构占位符（placeholder）处理的主要 PR 因与后续 trait 解析器（trait solver）开发的冲突而停滞，可能不得不放弃。与更大的类型团队的工作仍在继续，同时一些小型补丁/重构/改进也在不断合入。

    • #149639 现已合入，#150551 仍在审查中。

    • 我还基于之前的 PR 修复了一些小的低效问题（例如在诊断中按需计算无聊/相关局部变量、移除位置与点之间的转换等），因此这些修复需要先被审查。

    • 我再次使用 alpha 版本查看了 crates.io，寻找比 NLL 更慢的函数。据我所知，最坏的情况是对于一个 5000 行、包含 42000 个借贷（loans）、255000 条语句和 125000 个生命周期约束（outlives constraints）的函数，性能差距达到 60%。我会看看能对此做些什么。小型可组合函数依然是良好建议。

    • 似乎存在优化机会：1. 将传播限制在受双向边影响的块数量限制到更少；2. 对最多赋值一次的活动局部变量的不变生命周期（invariant lifetimes）进行统一，类似于使用-定义链，use-def chains）；3. 对于无效化（invalidations），如果仅仅是预留（reservation）的激活。

    • 我们讨论了使用为 Metrics 项目创建的基础设施收集实际统计数据的可能计划。

    • 我们也在准备今年的新项目目标，届时希望能稳定 alpha 版本 🤞


  • Rémy Rakic — 2026-02-02-28 的评论


    本月时间较少，更新会更简短，但我希望依然有意义：


    • #150551 已合入，感觉已具备稳定化条件。对我而言，这部分目标已经实现。

    • 尽管如此，“具备稳定化条件”并不等于“稳定”，还有更多工作要做。我们计划在今年进行稳定，2026 年项目目标提案记录了具体计划。

    • tiif 仍然深入在 #152051 中，并与 Niko 和我一起进行 a-mir-formality 的工作。

    • Amanda 发布了一些清理 PR（#152438 和 #152579），#151863 已经合入。她还开始研究 Tage 的旧 PR，看看我们是否能修复它、更准确地对其基准测试，并找出其中可以使用的优秀部分。

    • Jack 今年可能会有时间与我们合作！他的帮助将非常受欢迎，尤其是我自己的时间会减少。

    • 我们将在 #153215 中跟踪不透明类型区域活跃性（opaque type region liveness）的声音性问题，并且我添加了一些测试，以便在 tiif 的 PR 或任何影响该问题的地方合入时进行验证。

    • 我之前提到的一些小型清理也已在 #152587 中合入。


其他目标更新

为 rustdoc 团队添加团队章程

在 a-mir-formality 中的借用检查

C++/Rust 互操作问题空间映射

  • 相关人员： <a href=”http://github.com/rust-lang/compiler-team）（Oliver Scherergithub.com/oli-obk）、[lang]（http://github.com/rust-lang/lang-team）（Tyler Mandrygithub.com/tmandry）、[libs]（https://github.com/rust-lang/libs-team）（David Tolnaygithub.com/dtolnay）**

  • 状态： [继续] (https://rust-lang.github.io/rust-project-goals/2026/interop-problem-map.html”>Joel Marcey
  • 负责人： [compiler

5 条详细更新可用。

  • Joel Marcey — 2026-01-20 评论


    Rust 基金会正在开放一个短期（约 3 个月）的合同职位，以协助我们的 Rust/C++ Interop 倡议。该职位的主要工作和交付成果是：通过收集离散的问题陈述，并基于所发现的问题，提出后续工作建议，从而在 Problem Space Mapping Rust Project Goal 上取得实质性进展。

    如果你对编程语言之间的互操作方式感兴趣，希望理解其中存在的问题，并有热情思考如何解决这些问题以改善互操作，那么这项工作可能适合你。

    理想的候选人应具备 Rust 编程经验。同时，强烈推荐具有 C++ 经验者。如果你有直接从事需要在 Rust 和 C++ 代码库之间进行互操作的实际工程经验，那就更好了。

    如果你感兴趣，请通过 电子邮件联系我（邮箱地址可在我的 GitHub 个人资料中找到），或直接在 Zulip 上联系我，截止日期为 1 月 27 日（星期二），届时我们将进一步探讨是否存在进一步讨论的可能性。

    谢谢。


  • Joel Marcey — 2026-01-31 评论


    为支持此项目目标而填补 合同职位 的努力正在收尾。面试和讨论过程已接近完成。我们预计在 2 月初为该职位做出最终决定。


  • teor — 2026-02-27 评论


    大家好，我是互操作问题空间映射项目目标的新合同工。

    在过去的一周半里，我做了以下工作：

    下一步是对部分用例进行优先排序，然后更详细地处理相关问题陈述。

    阻碍

    目前没有阻碍，仍在进行问题空间的高层映射。

    寻求帮助

    非常欢迎提供更多互操作用例的建议，只需在 t-lang/interop 中展开讨论，我会将其转化为一个票据。


你完全可以直接开启一个用例工单。

我会每隔几周在这里发布更新，你也可以在 Zulip 上关注更详细的每周更新。

– 添加了多个互操作（interop）代码示例，其中包括来自 Outreachy 申请者的许多实例

– 继续指导 Outreachy 申请者

– 继续推进重载（Overloading）Rust 语言实验

>

具体来说，上个月我们在两个高优先级用例上取得了详细进展：

>

– 从 Rust 调用重载的 C++ 函数，附带 Rust 语言实验 – 实现讨论

– 我们已 合并了一个重构 为该实验做准备，该重构带来了一些不错的性能提升

– 初始的 重载实验 PR 已经历两轮审查，正在等待我的修改和变基（rebasing）

– 将 Rust 添加到现有的 C++ 构建系统

Outreachy 申请者编写了 互操作示例代码 PR

– 这些互操作用户体验正在等待分析，以便后续在构建系统和重载问题陈述中进行总结

– 这可能会在 RustWeek 和全体会议（All Hands）之后进行

>

下一步是继续推进重载实验，同时进行 RustWeek/全体会议的准备工作，并在会议期间收集反馈。

>

### 障碍

>

目前没有。新的用例、问题、代码示例以及 Rust 语言实验反馈正在持续涌现。

Rust 全面 niche 检查

常量泛型（Const Generics）

6 条详细更新可用。

宝子 — 2026年1月27日评论

我和 Boxy 已定下固定时间，定期检查在 a-mir-formality 中形式化建模的进度。今天，我们主要致力于常量值（const values）的“模型”，从以下内容开始：

>

`

#[term]

pub enum ConstData {

// 相当于 ValTreeKind::Branch

#[cast]

RigidValue(RigidConstData),

>

// 相当于 ValTreeKind::Leaf

#[cast]

Scalar(ScalarValue),

>

#[variable(ParameterKind::Const)]

Variable(Variable),

}

>

#[term]

pub enum ScalarValue {

Value {

#[grammar(u8($v0))]

U8(u8),

#[grammar(u16($v0))]

U16(u16),

#[grammar(u32($v0))]

U32(u32),

#[grammar(u64($v0))]

U64(u64),

#[grammar(i8($v0))]

I8(i8),

#[grammar(i16($v0))]

I16(i16),

I16(i16),

#[grammar(i32($v0))]

I32(i32),

#[grammar(i64($v0))]

I64(i64),

#[grammar($v0)]

Bool(bool),

#[grammar(usize($v0))]

Usize(usize),

#[grammar(isize($v0))]

Isize))]

Isize(isize),

}

>

#[term($name $ { $,values })]

pub struct RigidConstData {

pub name: RigidName,

pub parameters: Parameters,

pub values: Vec,

}

`

>

也就是说，一个常量值（const value）可以是标量值（scalar value，与现在一样），也可以是类似 Foo { ... } 的结构体字面量（这也涵盖了元组等）。我们已通过了各项测试。万岁！

Boxy — 2026年1月30日评论

除了 niko ily 除了 niko 之前提到的东西，本月还有其他许多进展。很多人已经提交了改进 mGCA 的 PR：León Orell Valerian Liehr、Noah Lev、@enthropy7、Kivoeo、mu001999、@Human9000-bit、Redddy、@Keith-Cancel、@AprilNEA

>

mGCA 的改进内容大致包括：

>

– mGCA 现在支持大量新表达式：常量构造器（const constructor）、元组构造器调用（tuple constructor call）、数组表达式（array expression）、元组表达式（tuple expression）、字面量，字面量（literals）

– associated_const_equality 已合并到 min_generic_const_args。由于前者实际上已经依赖于后者，所以这只会让使用前者时更美好 🙂

– 如果所有关联常量都是类型常量（type consts）且在 trait 对象中指定，那么 trait 现在可以变得 dyn 兼容（例如 dyn Trait）

– 类型常量（type consts）强制要求非泛型（non-generic）

– 修复了一批 ICE

– camelid 一直在研究“非最小”版本的 mGCA，它将允许在类型系统中使用任意表达式（一旦真正落地，将发布一篇更详细的博客文章）

>

在非 mGCA 的更新方面，正如 niko 所说，我们定期会面，在 a-mir-formality 中推进常量的建模。我还花时间思考了 adt_const_params 与带有隐私/安全不变量的 ADT 之间的相互作用，我认为我知道如何在这个领域组织 RFC 了，因此可以再次取得进展。

关于大家所做的各项工作的更多细节，以及谁做了什么，请参见：#project-const-generics > perfectly adequately sized wins @ 💬

sized wins @ 💬

  • Niko Matsakis — 评论于 2026-02-13


    Boxy 和我已经会面（并持续会面），致力于在 a-mir-formality 中为 const 泛型（const generics）建模。我们仍在进行基础工作。

    下一年的项目目标（project goal）已经有了提案。


  • Boxy — 评论于 2026-02-28


    本月对 mGCA 进行了大量杂项修复。我还开始起草一些博文，解释 mGCA/oGCA 的进展，并征求它们以及 adt_const_params 的使用案例/体验报告。此外，本月我在 Rust Nation 上与一些朋友讨论了 const 泛型用户进行了交流，了解了哪些特性对他们有用以及原因。


  • Boxy — 评论于 2026-04-02


    >

    更新晚了😅。niko 和我继续会面讨论 const 泛型。我们在解决 const 泛型中隐私/安全性方面的问题取得了一些进展。同时也在讨论 const 泛型的宏观规划以及我们未来的“方向”。


  • Boxy — 评论于 2026-05-01

    >


    开始每周召开 const 泛型会议，以便更容易跟踪所有致力于 const 泛型相关工作的人员的进度。我认为 min_adt_const_params 现在已经到了需要确定 RFC 规范细节的阶段。

    的阶段。

    感谢 ashley 的工作，GCA 取得了良好的进展。我还与 lcnr 会面，讨论了在不久的将来是否有某个版本的 mGCA 可以稳定化（也许有可能！）。


继续解决 cargo-semver-checks 合并到 cargo 的阻塞问题

有 1 条详细更新。

提升保持 FLS 及时更新的能力

有 2 条详细更新。

  • Pete LeVasseur — 2026-03-04 评论


    我们在 2026 年已接管了一个项目目标：稳定 FLS 发布节奏。针对 1.93.1 版本的推进看起来不错，大部分问题都已 关闭。

    寻求帮助

    我们非常欢迎来自安全关键领域的更多朋友，贡献于处理 issues，或者在发现遗漏时提出新的 issue。


  • Pete LeVasseur — 2026-04-04-02 评论


    尝试提前准备 FLS 发布：


    • 由于这次我们提前完成了 FLS 的 1.94.0 发布，于是按照今年目标的扩展部分，提前审视了 1.95.0 版本

    • 感谢 Eric Huss 和 TC 提供的技巧，我们进一步了解了发布说明的流程

    • 我和 Tshepang Mbambo 上周参加了 t-release 会议，讨论了如何与他们“上游”协作，更早地生成发布说明

    • 明天的 t-fls 会议上，我们将讨论介入该工作的意愿；至少我会参与 t-release

    术语表与正文协调：


    • Tshepang Mbambo 的首个 PR 已落地，移除了术语表中的 ID

    • 后续步骤已计划，我们有相关的跟踪 issue

    开发者指南：


    • 类似于 Reference 现在拥有的开发者贡献指南，我们将在 FLS 中也引入同样的指南

    • Hristian Kirtchev 正在着手这项工作


在代码生成中发出 Retags

有 4 条详细更新。

  • Ian McCormack — 2026年1月9日评论


    这是我们一月的状态更新！


    • 昨天，我们为 retag 内联函数（intrinsics）提交了一份 [MCP]（https://github.com/rust-lang/compiler-team/issues/958）。在等待进展的同时，我们将开始调整当前原型，以消除对 MIR 层级 retag 的依赖。完成后，我们就准备好提交 PR。

    • 我们发布了 BorrowSanitizer 的首篇月度博文。

    • 我们的 2026 年总体目标是从研究原型过渡到功能工具。还有三个关键功能尚未实现：垃圾回收、错误报告以及对原子内存访问的支持。这些完成后，我们就能开始测试真实世界的库，并与 Miri 对比验证结果。


  • Ian McCormack — 2026年2月24日评论


    我们刚刚发布了 BorrowSanitizer 的二月状态更新。概要如下：


    • 我们为别名违规提供了详细的错误信息，看起来几乎和 Miri 的一样！

    • 我们有两种形式的 retag 内联函数：__rust_retag_mem 和 __rust_retag_reg。我们不再需要编译器插件来确定 retag 关联的权限，这意味着只需向 rustc 提供单个 -Zsanitizer=borrow 标志即可使用 BorrowSanitizer。你可以查看我们的 MCP 了解更详细的设计更新。

    • 我们开始对 BorrowSanitizer 的实际性能有了更好的理解，但目前数据还不够充分，无法下定论。从某个测试用例来看，我们的速度似乎比 Miri 快一些，但在与其他 sanitizer 对比时，性能表现仍处于同一类别。随着基准测试管道的扩展，预计会看到更详细的结果。

    • 我们有一个初步计划，打算在 2026 年将 BorrowSanitizer 上游化，先从它的 LLVM 组件开始。一旦 API 稳定下来，我们计划在今年春天启动 LLVM 方面的 RFC 流程。


  • Ian McCormack — 2026年3月30日评论


    我们刚刚发布了 BorrowSanitizer 的三月状态更新。概要如下：


    • 我们从 Miri 的测试套件中新增了数百个相关测试。目前通过率是 80%。

    • 我们改进了 cargo 插件（cargo-bsan），以更好地支持多语言库。这将使我们能够开始重现先前评估中发现的 bug。

    四月的目标是继续扩展测试套件，完成 BorrowSanitizer 的 LLVM 组件初始版本，并希望能在 LLVM 方面启动 RFC 流程。


  • Ian McCormack — 2026年4月29日评论


    我们有个令人兴奋的消息：我们的 BorrowSanitizer 演讲已被今年 RustConf 录用！我们很感激这个机会，并期待在今年九月与更广泛的社区分享我们的成果。

    我们刚刚发布了四月状态更新。这篇更新技术性较强。概要如下：


    • BorrowSanitizer 现在使用 shadow stack 在运行时跟踪元数据——这与其它 LLVM sanitizer 的策略显著不同，这将帮助我们支持垃圾回收。

    • 我们现在已经准备好开始提交 retag 内联函数的 PR。将变更拆分成有意义、可审查的块需要一些时间——预计未来一周内就能看到这些 PR。

    LLVM 组件的 RFC 花费的时间比预期稍长，但值得多花时间测试编译器的变更进行测试，并确保插桩传递的核心部分已经稳定。我们将在未来几周内起草 RFC。


扩展 Rust 参考手册，以规范 Rust 语言的更多方面

有 1 条详细更新可用。

完成 libtest JSON 输出实验

完成 std::offload 模块

有 2 条详细更新可用。

std::autodiff 正逐步接近 nightly，而 std::offload 在性能、功能及硬件支持方面正获得多项改进。

>

#### autodiff（自动微分）

>

Jakub Beránek、sgas ho 和我继续致力于在 nightly 中启用 autodiff。我们已经有一个 PR，在 CI 中构建了 autodiff，并验证了构件可以在 Linux 上安装且正常工作。然而，在 Apple 平台上我们发现任何 autodiff 的使用都会导致挂起。经过调查，结果是我们最终嵌入了两个 LLVM 副本：一个在 rustc 中，另一个在 Enzyme 中。移除第二个副本应该相对容易。一旦我们验证这一修复能解决构建问题，我们将合并该 PR，以在两个目标平台上都启用 nightly 中的 autodiff。

>

#### offload（任务卸载）

>

在性能、功能和硬件支持方面有许多有趣的更新。

>

1. Marcelo Domínguez、@kevinsala、@jdoerfert 和我开始实现首批基准测试，因为这是发现缺失特性或性能问题的最佳方式。我们惊喜地发现开箱即用的性能相当出色。我们将实现更多基准测试，并在验证后公布结果。我们还实现了多个 PR，包括错误修复、清理以及所需的功能，例如对标量的支持。我们还开始研究 LLVM 优化，以确保能实现更好的性能。

2. 我注意到我们的 offload 内建函数允许在 GPU 上运行 Rust 代码，但在调用 cuBLAS 等 GPU 厂商库时并无太大帮助。我实现了一个新的辅助内建函数，能方便地调用这些函数，而无需手动在设备间移动数据。它将受益于与我们完整 offload 内建函数相同的 LLVM 优化。此外，它在编译器和链接器端配置起来也稍微简单些，因此它已经能正常处理 std 和 mangled 内核名称——而我们主 offload 内建函数在这点上仍有待改进。

3. 在 LLVM offload 方面，针对 SPIRV 和 Intel GPU 支持做了大量工作。目前，我们的 Rust 前端已在 NVIDIA 和 AMD 服务器及消费级 GPU，以及 AMD HPC 和笔记本电脑 APU 上进行了测试。Karol Zwolak o l a k) 联系了我们，表示希望帮助我们在更多平台上运行 Rust。

我们将以上内容翻译为中文：

t o n I n t e l G P u s . O f f l o a d r e l i e s o n L L V M w h i c h s t a r t e d g a i n i n g I n t e l s u p p o r t , s o h o p e f u l l y w e w o n ‘ t n e e d m u c h w o r k b e y o n d a n e w i n t e l – g p u t a r g e t a n d a n e w s t d a r c h m o d u l e . T h e r e i s a l s o w o r k o n a n e w s p i r v t a r g e t f o r r u r r u s t c , w h i c h w e c o u l d a l s o s u p p o r t i f i t g o e s t h r o u g h L L V M . D u e t o s o m e o p e n q u e s t i o n s a r o u n d t y p e d p o i n t e r s i t d o e s n o t s e e m c l e a r y e t w h e t h e r i t w i l l , s o w e w i l l h a v e t o w a i t .

  1. N i k i t a s t a r t e d w o r k i n g o n [ u p d a t i n g i n g ] ( h t t p s : / / g i t h u b . c o m / r u s t – l a n g / r u s t / p u l l / 1 5 0 7 2 2 ) o u r s u b m o d u l e t o L L V M 2 2 . T h i s h o p e f u l l y d o e s n o t o n l y b r i n g s s o m e c o m p i l e a n d r u n t i m e p e r f o r m a n c e i m p r o v e m e n t s , b u t a l s o g r e a t l y s i m p l i f i e s h o w h o w w e c a n b u i l d a n d u s e o f f l o a d . O n c e i t l a n d e d I ‘ l l r e f a c t t o r o u r b o o t s t r a p p i n g l o g i c , a n d a s p a r t o f t h a t s t a r t b u i l d i n g o f f l o a d i n C I .
  • Manuel Drehwald — comment from 2026-04-01


    std::autodiff is now partly in CI, and std::offload got tested on a lot more benchmarks.

    autodiff

    Work continued on enabling autodiff in nightly. S i n c e t h e l a s t u p d a t e , w e h a v e e n a b l e d a u t o d i f f i n s o m e M i n g w a n d L i n u x r u x r u n n e r s . U s e r s c a n n o w d o w n l o a d l i b E n z y m e a r t i f a c t s , p l a c e t h m l o c a l l y i n t h e r i g h t s p o t f o r t h e i r t o o l c h a i n , a n d e n h e n u s e a u t o d i f f o n o n t h e i r n n i g h t l y o m p i l e r . O n c e m a c O S i s a d d e d , w e w i l l e n a b l e a n e w r u s t u p o m p o n e n t t h a t w i l l h a n d e t h e d o w n l o a d f o r u s e r s . B e f o r e e n a b l i n g a u t o d i f f o n m a c O S , h o w e v e r , w e w a n t t o c h a n g e h o w w e d i s t r i b u t L L V M o n t h i s t a r g e t ( f r o m s t a t i c t o d y n a m i c l i n k i n g ) . T h e r e a r e a l o t o f w o r k f l o w s a n d u s e r s o f t h i s t a r g e t , n o t a l l o f w h i c h c a n b e m o d e l l e d i n t h e R u s t C I . O u r l a s t t w o a t t e m p t s s a d l y b r o k e s u c h d o w n s t r e a m u s e r s a n d l o c a l o n t r i b u t o r s , s o b o t h a t t e m p t s h a d t o b e r e v e r t e d . S i n c e t e s t i n g h e r e i s t r i c k y , p e r f o r m a n c e h e r e m i g h t b e o n t h e s l o w e r s i d e ; w e w i l l s e e .

    offload

    Most of the work on the offload side lately has been invisible, since we were working on implementing worked on implementing more benchmarks and LLVM optimizations, as well as missing features discovered by those benchmarks. W e a c h i e v e d e x c e l l e n t p e r f o r m a n c e o n t h o s e b e n c h m a r k s ; m o r e d e t a i l s w i l l s o o n b e p r e s e n t e d b y Marcelo Domínguez at the EuroLLVM conference in two weeks!

    Beyond benchmarks, there was a lot of tinkering on smaller PRs, reviewing, and housekeeping. L L V M – 2 2 l a n d e d , s o w e u p d a t e d o u r b o o t s t r a p c o d e t o t o m a k e u s e o f n e w A P I s , a n d t r i e d t o m o v e a f e w s m a l l e r P R s f o r w a r d , m a i n l y a r o u n d a b e t b e t t e r u s e r e x p e r i e n c e a n d f o r m a k i n g m o r e R u s t f e a t u r e s a v a i l a b l e . S i n c e t h e f o c u s i s s t i l l o n b e n c h m a r k s , n o t m a n y o f t h o s e P R s l a n d e d . T h e y a r e i n a m o s t l y r e a d y s t a t e , s o i t ‘ s a g o o d t i m e t o p i c k t h e m u p i f y o u ‘ r e c o n s i d e r i n g.


（注：原文中存在大量多余空格，已按正常英文单词清理；链接中的空格也已移除，恢复为正确的 URL。）

g 贡献中。如果你感兴趣，请在 Zulip 或任何带有 offload 标签的 PR 中联系我！

将 Rust for Linux 纳入稳定版 Rust：编译器特性

有 4 条详细更新可用。

在稳定版 Rust 中实现 Rust for Linux：语言特性

提供 6 个详细更新。

  • Tomas Sedovic — 评论于2026-01-19


    来自2026-01-14会议的更新。

    Deref（解引用）Receiver（接收者）

    Ding 的 arbitrary_self_types（任意自我类型）：拆分解引用链 rust#14095 正在等待审查。它更新了方法解析，使得逻辑本质上变为：derref_chain(T).flat_map(|U| receiver_chain(U))。

    性能测试结果无显著，carter 已于昨天完成。分析待定。

    RFC #3851：超 trait 自动实现

    Ding 已提交了一份 Rust 项目目标：超 Trait 自动实现。

    任意自我类型 rust#44874

    我们发现了一个 #[feature(arbitrary_self_types_pointer)] 特性门控。由于语言团队（Lang）的共识是不支持在裸指针类型上实现 Receiver trait，我们可能会移除它（但这需要进一步讨论）。这是原始提案的残留，但语言团队此后已经改变了方向。

    derive(CoercePointee) rust#123430

    Ding 正在修复以防止 trait 实现的意外特化。rust#149968 添加了一个临时修复。

    Alice 为 rust#136776 打开了一个参考 PR。关于 as 转换与强制转换的行为存在疑问。

    向汇编传递常量指针 rfc#3848

    Gary 为 RFC 打开了实现：rust#138618。

    字段投影项目 goal#390

    Benno 将字段表示类型的 PR 更新到了最新设计。这使得 PR 变得简单得多。

    Tyler 创建了一个 超越引用 (Beyond References) 维基，用于将所有提案和资源集中在一个地方。

    就地初始化 goal#395

    Ding 正在撰写一篇文章，描述所有开放提案，包括 Alice 在 LPC 2025 上提出的新方案。他将把文章合并到 超越引用 (Beyond References) 维基 中。

    宏、属性、派生宏等

    Josh 提出了他关于增加更强大的声明式宏来编写属性和派生宏的工作。他已经向 Rust for Linux 团队询问他们需要什么才能停止使用过程宏。

    Miguel 提到他们刚刚添加了对 syn 的依赖，但他们希望有朝一日能移除它。

    Benno 提供了一些大型宏的案例，他认为这些宏不太可能被声明式宏替代。Josh 表示可能有办法，并建议进行异步讨论。


  • Tomas Sedovic — 评论于2026-02-16

u b . c o m / r u s t – l a n g / r u s t – p r o j e c t – g o a l s / i s s u e s / 1 1 6 # i s s u e c o m m e n t – 3 9 0 9 5 8 2 1 9 5 )

来自2026-01-28和2026-02-11会议的更新：

#### 移除 likely/unlikely 提示，转而使用 cold_path

core::hint::cold_path lint 的稳定化 即 将 完 成 ， 此 后 ， likely 和 unlikely 提 示 很 有 可 能 （ 请 原 谅 这 个 双 关 ） 会 被 移 除 。

团队讨论了这一影响。这些提示在 C 语言中有使用，但在 Rust 中尚未普及。cold_path 已经足够，但在没有 else 分支的情况下，likely / unlikelyunlikely 仍然更便捷。Tyler Mandry ( ) 提到，这些提示可以通过 cold_path` 来实现。

#### 小生境优化（Niche optimizations)

我们讨论了在指针低位嵌入数据的可行性——这是内核在 C 语言中的做法。这还可以启用对整数最高位（否则永远不会被置位）的设置，使之代表错误情况（或者在其他情况下代表普通指针）。

理想情况下，这将在安全的 Rust中完成，因为其目标是为所涉 C 代码提升安全性。

扩展小生境iche)是 Rust 希望实现的，但这需要等待模式ypes。使用 unsafe 并将其封装在安全宏中可实现短期/中期方案，但长期希望该功能在语言层面得到支持。

#### 引入 zerocopy

该项目有意引入[zerocopy 。我们邀请了其维护者Jack Wrenn、保证析构函数guaranteed destructors)、类型别名实现 Trait (Type Alias Impl Trait, TAIT)、返回类型表示法 (Return Type Notation, RTN)、const traits、const 泛型（针对整数类型）、外部类型 (extern type)。

#### 2026 项目目标

<

blockquote>今年引入了路线图的概念。我们现在有了一份<a href=”以及若干更细粒度的目标。随着时间的推移，我们会添加更多目标，但目前已合并的目标涵盖了我们的重点工作方向。

暂时就这样。

  • [Tomas Sedovic](https://github.com/tomassedovic”>Rust for Linux — 2026-03-11 的评论


    来自 2026-02-25 会议的更新：

    2026 项目目标

    我们在会议上花了大部分时间审查公开的项目目标、Rust for Linux 路线图以及其他我们希望看到但尚不适合作为目标的事项。

    Miguel Ojeda 提到了即将发布的 Debian 14（预计在 2027 年第二季度左右推出），我们逐一讨论了每个事项，并判断是否需要确保其出现在该版本中。

    Debian 稳定版是一个重要的里程碑，其中包含的 Rust 版本将作为 Rust for Linux 开发的基线。

    我会将所有数据添加到路线图中。


  • Tomas Sedovic — 2026-03-16 的评论


    来自 2026-03-11 会议的更新：

    字段投影 (Field projections)

    我们现在有了一个使用投影机制的宏和基础设施。

    dma_read! / dma_write! 宏已切换为使用该机制。这还修复了一个健全性问题 1。

    注意：目前完全通过宏实现，并未使用任何字段投影的语言特性。字段投影的语法和 trait 将使其更符合人体工程学，并能整合借用检查器，从而接受更多代码。

    我们计划在 计划在 3 月最后一周与 Lang 团队举行设计会议。

    rustfmt 导入格式化和尾部斜杠

    我们再次讨论了 use 语句的 rustfmt 格式化问题。虽然使用尾部空注释 // 的变通方案（参见此更新）作为临时措施可以接受，但我们需要找到一个长期解决方案，使用户能够配置 rustfmt 接受这种写法。

    目前我们还没有针对这种特定格式的 issue，不过在 #3361 中已讨论过。

    下一步是创建这样一个 issue。我们原本不愿给已经超负荷的团队增加负担，但有了 issue 就可以从 Rust for Linux 方面进行跟踪。


  • Tomas Sedovic — 2026-03-26 的评论（注：原文链接中 github. c o m 空格修复后应为 github.com，但原文本写的是 github. c o m - l a n g？重复检查原文：[c o m m e n t f r o m 2 0 2 6 - 0 3 - 2 6 ] ( h t t p s : / / g i t h u b . c o m / r u s t - l a n g / r u s t - p r o j e c t - g o a l s / i s s u e s / 1 1 6 # i s s u e c o m m e n t - 4 1 3 6 7 5 5 1 1 5 )，注意是 github.com，没有 -lang。修复后为保险起见，修复为 https://github.com/rust-lang/rust-project-goals/issues/116#issuecomment-4136755115）


    来自 2026-03-26 会议的更新：

    常量泛型 (Const generics)

    Boxy 向团队询问了在常量泛型中最需要哪些特性。


常量泛型（const generics）总览。这可能有助于优先级排序和理解实际用途。

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

2. 参数位置的常量泛型：目前，常量泛型类型必须在类型约束部分（尖括号内）指定。例如，你必须写 Bounded::::new::<7>() 而不是更自然的 Bounded::::new(7)。当涉及编译期计算而非简单的数值常量时，情况会更复杂——此时还需要用花括号包裹：{ ... }。

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

statx

Alice Ryhl 提议能够从 Linux statx 系统调用创建 std::fs::Metadata。

这在 Libs-API 会议中进行了讨论，他们对 statx ABI 可能的演进有疑问——未来它是否会/如何增长，以及如果他们想要一些新数据，如何处理。所以我们在 Rust for Linux 会议上讨论了它。

最终，采取合理防御措施似乎比依赖系统调用预填充默认值更谨慎。

Alice Ryhl 提议一个不透明的 statx 结构体，它可以让标准库决定结构体的大小、预填充内容和掩码。

Miguel Ojeda 建议联系 Christian Brauner 和 Alexander Viro（即 VFS 维护者）；Josh Triplett 同意，如果我们能和相关人员在 linux-fsdevel 上开一个讨论线程，那会很好。

摘自 2026 年 4 月 8 日会议更新：

#### Rust 标准库中的 zerocopy 特性

zerocopy 使用了两个 trait，它们都是不稳定 trait 的替代方案：KnownLayout（对应 ptr_metadata）和 Immutable（对应 Freeze）。 这 将 有 助 于 zerocopy 的 维 护（Rust for Linux 计划开始使用它），如果这些特性能够稳定化的话。

ptr_metadata 是团队独立希望在内核中实现的功能。它可能被 Sized Hierarchy 工作 所阻塞（或至少与其有交互）。

Freeze（现在叫 NoCell）有一个 RFC。

#### Deref / Receiver

Jack Huey 开始审阅 Ding Xiang Fei 的 拆分自动解引用链的 PR，并认为它尚未准备好提交给完整的 Lang 团队。

我们还讨论了 Deref 和 Receiver 实现之间的依赖/独立性，特别是在什么情况下实现 Deref 但 不 实现 Receiver 是有意义的。Josh Triplett 建议收集此类场景的示例（即类型不能在函数声明中作为 Self 类型使用，但允许调用其方法）。

目前的实验计划是将这些 trait 分开，但让编译器强制规定：如果它们实现了同一个类型，它们的 target 必须相同。这将为我们未来的任何可能性敞开大门（比如超 trait / 子 trait 关系，或者未来目标分化）。

我们希望通过实验观察这些 trait 及其可能的演化在哪些场景和如何发挥作用。

#### null-ptr-deref

团队希望获得一个（可选的）编译器保证，即编译器永远不删除对裸指针的空值检查。目前在 C 语言中，

但空值检查仍然有助于防止进一步的问题，在 C 语言中，内核现已禁用了会删除该检查的优化。

Miguel Ojeda 将为此开启一个 MCP。

#### 原地初始化（In-Place Initialization）

Benno Lossin 在 2026 年 All Hands 上提交了一份 原地初始化的线下会议室提案。

这里有一个 元问题，跟踪所有关于此特性的提案和讨论。

这个设计空间非常复杂，团队希望线下讨论能推动其进展。

实现 Open API 命名空间支持

MIR 移动消除

1 条详细更新。

  • Amanieu d’Antras — 2026-04-03 的评论


    RFC 刚刚发布。与上一版草案相比，它经过了大量重写。

    值得注意的变更：


    • 移除了激活/去激活（activation/de-activation）概念。现在语义无需处理部分分配的局部变量。这在优化能力上有所削弱，但应该仍能覆盖大多数情况。

    • 在调用参数中新增了 byref/byval（按引用/按值传递），以明确参数的传递方式。

    • 新增了一个独立章节，将表层语言变更与 MIR 变更区分开来。

    • 增加了关于消除移动的 MIR 优化的更多细节。

    • 将 MIR 操作数求值顺序改为从左到右，但目标位置（destination places）始终最后求值。

    • 重新加入了 StorageLive：我们需要它来标记应插入 llvm.lifetime.start 的位置，这与局部变量初始化的位置不同。在操作语义（opsem）中，StorageLive 并不实际分配局部变量，分配仍然在通过写入进行初始化时完成。


原型设计一套新的 Cargo “管道”命令

原型设计 Cargo 构建分析

1 条详细更新。

此项目目标的原型基本完成。

>

### 当前状态

>

该目标在 Cargo 中引入了构建分析支持（build analysis support），旨在让构建行为在多次调用（而非单次运行）中变得可理解。

>

从高级层面看，原型实现了：

>

– 随时间记录构建元数据，包括：

– 重新构建原因（rebuild reasons）

– 时序信息（timing information）

– 相关的调用上下文（invocation context）

– 将数据本地存储为结构化的日志格式，便于后续分析

– 通过不稳定的 cargo report 子命令暴露数据，例如：

– cargo report sessions – 列出会话 ID

– cargo report timings – HTML 时序报告

– cargo report rebuilds – 为何内容被重新构建

>

更详尽的使用文档请参见参考文档。

>

—

>

### 稳定化路径

>

在此功能稳定之前，必须解决以下未决问题。它们可能不阻塞稳定化，但需要评估是否适合留待未来处理。

>

#### cargo report 命令

>

这是一个稳定化阻塞点。

>

– 目前所有三个报告命令（sessions、rebuilds、timings）在不在工作区内时都会隐式地检查全局日志文件。

– 是否应通过一个标志显式指定？

– 如果不在工作区内，是否应报错？

– 对命令名称进行 bikeshed（命名讨论）

– 目前我们使用全部名词

– 对于 sessions：

– runs 简单但含义模糊

– 像 git log 那样直接用 log

– history 对用户友好（docker history、shell history，但并非类似）

– 对于 timings：

– 没有争议，因为已经有 --timings 标志

– 对于 rebuilds：

– rebuild-reasons 更明确

– 或者改为面向操作的动词：

– cargo report list-sessions

– cargo report analyze-timings（bazel analyze-profile）

– cargo report explain-rebuilds

– 或者面向问题的动词：

– cargo report what-ran 更通用（buck2 log what-ran）

– cargo report why-rebuilt/why-reran

>

##### cargo report sessions

>

– 目前它输出人类可读的内容，没有供编程使用的格式。

– 是否应提供编程输出（例如通过 --message-format=json）？

>

##### cargo report rebuilds

>

– 将报告从指纹（fingerprint）扩展到新的哈希值（-Cmetadata/-Cextra-filename）

– 目前我们无法区分一次全新构建是真正的新构建，还是仅 rustflags 发生了改变

– https://github.com/rust-lang/cargo/pull/16456#discussion\_r2662364819

– 使每条重新构建原因对最终用户来说更具可操作性、更友好

– 是否应记录被比较的指纹值，还是仅记录差异结果？

– #t-cargo > logging unit fingerprint @ 💬

>

#### 日志消息模式

>

这是一个稳定化阻塞点。

>

– 提供用于读取日志消息的类型

– 我们应在 cargo-util-schemas 中导出 LogMessage 枚举及相关类型

– 用户可能希望以编程方式解析日志

– https://github.com/rust-lang/cargo/pull/16150#discussion\_r2462065538

– JSON schema evolution and versioning（JSON 模式演进与版本控制）

– 我们是否应在每条消息中显式地对模式进行版本控制？

– 兼容性可能与 https://doc.rust-lang.org/nightly/cargo/commands/cargo-metadata.html?highlight=compa#compatibility 相同

– Message structure consistency（消息结构一致性）

– 当前的日志消息偏离了 cargo 的标准 JSON 消息结构

– 我们是否应该与现有的 cargo JSON 输出格式保持一致，例如 target 字段？

– https://github.com/rust-lang/cargo/pull/16414#discussion_r2632724893

– https://github.com/rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487

– 我们是否应该直接暴露整个 DirtyReason（脏原因）枚举？

– 当前暴露了内部实现细节

– 可能希望创建一个独立的面向公众的枚举

– 需要决定哪些变体（variants）是面向用户的，哪些是内部的

– 检查每个变体的实用性

– 某些变体可能已过时（例如，RustflagsChanged 在 -Cmetadata -Cmetadata “ 变更后可能很少出现）

– 需要审查哪些变体在实践中实际出现

– 删除或合并极少使用的变体

– 使脏原因（dirty reasons）对终端用户友好

– 当前原因过于技术化（例如，“local fingerprint type changed”）

– 用户需要可操作的消息（例如，“file modified: src/lib.rs”）

– 暴露 target（目标）和 mode（模式）

– 它们是否适用于所有类型的单元？我们可能需要将 mode 重命名为 action，作为单元的操作类型。

– https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20analysis.20log.20format/near/564781487

>

#### Log infrastructure（日志基础设施）

>

这些主要是未来的可能性，未来可能性，不是稳定化的阻碍，因为完全有可能进行增量改进。

>

– 日志压缩： https://github.com/rust-lang/cargo/issues/16475

– 日志轮换： https://github.com/rust-lang/cargo/issues/16471

– 崩溃时丢失数据是否可以接受？ https://github.com/rust-lang/cargo/pull/16150#discussion_r2462056940

>

另请参阅 https://github.com/rust-lang/cargo/issues/16471#issuecomment-3724915770

>

#### Nested Cargo calls（嵌套 Cargo 调用）

>

参见 https://github.com/rust-lang/cargo/issues/16477。

>

基本上，我们需要一种方式来关联嵌套 Cargo 调用的日志文件。这有助于其他工具以及 cargo fix 本身。

>

这是一个稳定化的阻碍。

>

#### How contributors can help（贡献者如何帮助）

>

未来的贡献者可以通过以下方式提供帮助：

>

– 接手下方列出的任何相关议题，或查看 https://github.com/rust-lang/cargo/issues/15844 中的议题

– 构建利用日志消息的外部工具，并提供反馈

– 从大型或非典型构建中提供实际反馈

>

已切割一系列后续任务以跟踪剩余工作：

>

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 0

– https://github. c o m / r u s / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 1

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 2

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 3

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 4

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 5

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 7 7

– https://github. c o m / r u s t – l a n g / c a r g o / i s s u e s / 1 6 4 8 8

反射与编译期计算 (reflection and comptime)

5 个详细更新可用。

重新设计 Cargo 构建目录布局 (Rework Cargo Build Dir Layout)

2 个详细更新可用。

  • Ross Sullivan — 来自 2026-01-15 的评论


    build-dir 的细粒度锁定 已合并，现可通过 -Zfine-grain-locking 不稳定标志在 nightly 版本中使用。🎉

    在正式发起测试调用之前，我们有一些已知问题需要解决。具体包括：改进阻塞消息、修复当锁阻塞时 Cargo 任务队列中潜在的线程饥饿问题，以及研究增加 rlimits 以降低在大型项目中达到最大文件描述符限制的风险。

    我希望这些问题能在未来一个月内得到解决，届时我们将发起测试调用，开始收集社区关于新锁定策略是否改善工作流程的反馈。


  • Ross Sullivan — 来自 2026-03-09 的评论


    在上次更新的初始 PR 合并后，我们将重点转向解决一些已知问题。值得注意的是，锁定会缓慢阻塞 Cargo 任务队列，如果许多构建单元被另一个 Cargo 实例持有，从而导致线程饥饿。

    我们研究了为 Cargo 增加在等待锁时“挂起”内部任务的能力，但认为这一改动过于侵入性，且与任务队列的设计不匹配。因此我们计划改变设计，在运行任务队列之前获取所有构建单元的锁（参见 #16657）。

    与此同时，我们持续改进新的 build-dir，为测试调用和最终稳定化做准备。（#16542, #16502, #16515, #16514）

    最后，我们决定将 .cargo-lock 拆分为两个锁，以允许当 artifact-dir == build-dir 且启用 -Zfine-grain-locking 时，cargo check 和 cargo build 并行运行。

    我认为这可能是关于此目标的最后一次更新，因为 2026 年的目标列表即将到来。虽然我没有为 2026 年续订此目标，但我计划继续推进相关工作，并在今年内实现其稳定化。


在 Rust 的 CI 中为 GCC 后端运行更多测试

Rust 稳定对 MemorySanitizer 和 ThreadSanitizer 的支持

3 条详细更新。

Rust 愿景文档

  • 参与人员: Niko Matsakis, 愿景团队
  • 状态: 部分完成；工作将在项目目标之外继续进行

rustc-perf 改进

稳定公有/私有依赖（public/private dependencies）

稳定 rustdoc 的 doc_cfg 特性（rustdoc doc_cfg` feature）

AArch64 上的 SVE 和 SME

有 5 个详细更新可用。

就目标中的可伸缩向量（scalable vector）部分而言，我们已经提交了一系列编译器修复 — rust-lang/rust#153286、rust-lang/rust#153608、rust-lang/rust#154850、rust-lang/rust#154950、rust-lang/rust#155106 以及 rust-lang/rust#155243 — 并且使用内建函数（intrinsics）打开了我们的 stdarch 补丁 — rust-lang/stdarch#2071。该补丁应该在通过每日更新修复一个无关的偶然 CI 失败后，于明天通过 CI 检验。后续我们还有少量工作要做，已列在 rust-lang/rust#145052 中。

就目标中的 Sized 层级（sized hierarchy）部分而言，Rémy Rakic 和我与语言团队（language team）举行了两次设计会议（2026/03/18 和 2026/03/25），分别讨论了语法/命名（syntax/naming）和迁移策略（migration strategy）。

在语法方面，语言团队倾向于引入一种“仅限边界（only bounds）”语法，用于控制退出默认边界并选择某一 trait 家族（trait family）中的替代边界（详见 RFC 中的替代方案）。但有一个未决问题：该语法应应用于单个边界还是所有边界 — Niko Matsakis 正在研究这个问题。

在命名方面，语言团队更倾向名称 SizeOfVal 而非 MetaSized，并且不喜欢 Pointee，但也没有更好的替代方案。Rémy Rakic 准备了 rust-lang/rust#154374 来执行这次重命名，并启动了与库团队（library team）的讨论 以确认他们对该名称满意，因为更改它涉及大量改动。库团队希望了解后续可能还会引入哪些层级中的其他 trait，因为这将有助于确定当前提议的 trait 的命名，所以 Rémy Rakic 撰写了一份文档 提供了这些信息。我们正在等待……

f f o n d o i n g a n y n a m e c h a n g e s u n t i l l w e f i n d s o m e c m e c o n s e n s u s b e t w e e n l i b s a n d l a n g – w h o i s r e s p o n s i b l e f o r t h e s e t r a i t s ‘ n a m e s i s a b i t u n c l e a r .

关于迁移，语言团队对我们的提议方法大体上表示满意，我们意识到 lcnr 提出的关联类型方法可能也适用于其他迁移。R é m y R a k i c 已与 lcnr 举行了多次会议，以更好地理解该方法并制定下一步实施计划。

Type System Documentation（类型系统文档）

Unsafe Fields（不安全字段）

有 2 条详细更新。

  • Jack Wrenn — 2026-02-18 的评论


    RFC 已被接受。我正在准备一个 2026 年的持续目标以实现稳定化。


  • Jack Wrenn — 2026-04-14 的评论


    已打开 PR（#16767(https://github.com/rust-lang/rust-clippy/pull/16767)），扩展 Clippy 对不安全字段的支持。

    阻碍因素

    等待 t-clippy 审查 #16767(https://github.com/rust-lang/rust-clippy/pull/16767)。


标签

相关文章

实时焦点

上海开源信息技术协会工作月报【2025-6（总第5期）】
​《开源硬件与新工业革命白皮书》在上海临港正式发布
基础软件到底需要什么样的自主可控？
开源技术开源商业第一次工作会议于9月20日召开