Rust 项目目标更新 - 2025年11月

Rust 项目目前正在推进 41 个项目目标，其中 13 个被指定为旗舰目标。本文章提供了我们在这些目标进展（或在某些情况下，缺乏进展）的精选更新。任何特定目标的完整详细信息可在其关联的 rust-project-goals 仓库的追踪问题中找到。

旗舰目标

“超越 &”

继续试验 Pin 语法改进 (rust-lang/rust-project-goals#389)

进度

联系人：Frank King
负责人：Frank King
冠军团队：编译器 (Oliver Scherer), 语言团队 (TC)

详细更新 (2025-11-21)

状态更新：

• &pin const|mut T 类型的模式匹配支持，已合并。
• &pin 模式和 ref pin mut 绑定模式，已合并。
• Drop::pin_drop，等待审查（自上次审查后有新更新）。

待解决问题：当前实现需要修改 src/docs/book 子模块，但主仓库和子模块仓库必须同时更改才能通过两个仓库的 CI 测试。这是因为在 rustdoc 中，Drop::drop 被添加了默认体，变成了一个 provided 方法而不是 required 方法。有什么方法可以避免这种情况吗？（或许可以让 rustdoc 继续将 Drop::drop 视为 required 方法？）

• &pin const|mut T 与 &{mut} T 之间的强制转换，等待审查（新提交）。

设计解决字段投影的语言特性 (rust-lang/rust-project-goals#390)

进度

联系人：Benno Lossin
负责人：Benno Lossin
冠军团队：语言团队 (Tyler Mandry)

TL;DR 我们基于 @Nadrieril 提出的新颖的、基于"位置"（place）的方案取得了巨大进展。自上次更新以来，他将自己的想法写成了一篇博客文章，并在 Zulip 上进行了大量讨论。仍有许多未解决的问题。如果您有任何想法，欢迎在 Zulip 上分享。

本月初，我们探索了移动投影（moving projections）和 &own。我们还研究了减少投影特征的数量。

PR https://github.com/rust-lang/rust/pull/146307 本月处于停滞状态，但将在 12 月重新拾起。

详细更新 (2025-11-01)

移动投影和 &own 移动投影是 Rust 中现已存在的第三种投影，对于 Box 以及任何持有结构体的局部变量都有效。虽然我们不会将其包含在 MVP 中，但我们仍然希望确保未来可以扩展语言以支持移动投影。这是一个使用 Box 的示例：

1
2
3
4
5

fn destructure_box(mut b: Box<Struct>) -> Box<Struct> {
    let f1 = b.f1;
    b.f1 = F1::new();
    b
}

此投影将字段移出 Box，在此过程中使其失效。为了使其重新有效，必须为该字段移入一个新值。或者，可以丢弃这个部分有效的 Box，这将丢弃 Struct 的所有其他字段，然后释放 Box。注意，最后一个特性目前是通过编译器魔法实现的，而移动投影将允许 Box 的这种特殊行为通过库实现来完成。

为了使这种投影对所有类型可用，我们可以通过添加以下特征使其成为正式操作：

1
2
3
4
5
6
7
8
9

pub unsafe trait ProjectMove: Projectable {
    type OutputMove<'a, F: Field<Base = Self::Target>>;
    
    unsafe fn project_move<'a, F: Field<Base = Self::Target>>(
        this: *mut Self,
    ) -> Self::OutputMove<'a, F>;
    
    unsafe fn drop_husk(husk: *mut Self);
}

重要的是，我们还需要一个 drop_husk 函数，负责清理在所有字段都被移动投影后剩下的"外壳"（husk）。对于 Box，它会释放内存。因此，对于 Box，我们可以这样实现此特征：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

impl<T> ProjectMove for Box<T> {
    type OutputMove<'a, F: Field<Base = T>> = F::Type;

    unsafe fn project_move<'a, F: Field<Base = T>>(
        this: *mut Self,
    ) -> F::Type {
        let ptr = unsafe { (*this).0.pointer.as_ptr() };
        ptr::read(unsafe {
            <*const T as Project>::project::<'a, F>(&raw const ptr)
        })
    }

    unsafe fn drop_husk(husk: *mut Self) {
        // this is exactly the code run by `Box::drop` today, as the compiler
        // drops the `T` before `Box::drop` is run.
        let ptr = (*husk).0;
        unsafe {
            let layout = Layout::for_value_raw(ptr.as_ptr());
            if layout.size() != 0 {
                (*husk).1.deallocate(From::from(ptr.cast()), layout);
            }
        }
    }
}

为了支持将值移回，我们有两个选项：

1. 添加一个 ProjectMoveBack 特征，声明一个接受值并将其移回到投影中的操作。
2. 添加 &own 引用。

到目前为止，我们探索了第二个选项，因为 &own 有很多其他应用。

&own 引用 关于 &own 引用的简短说明。 一个 &'a own T 是一种特殊的所有权引用，它拥有其指向的值。这意味着如果你丢弃一个 &own T，你也会丢弃它所指向的值。你可以直接构造一个到局部变量的 &own（如 &own my_local）或从现有的 &own 通过字段投影派生 &own 来获得它。智能指针通常也允许从 &own SmartPtr<T> 创建 &own T。

与 &mut T 的一个重要区别是，&own 不仅在时间上是唯一的（即没有其他未从它派生的引用指向该值），而且对于该值本身也是唯一的。换句话说，一个局部变量最多只能创建一个 &own T。

1
2
3
4

let mut val = Struct { ... };
let x = &own val; //~ 帮助信息：所有权在此处转移
drop(x);
let y = &own val; //~ 错误：不能拥有 `val` 两次

由于 drop(x) 语句丢弃了 val，借用检查器必须禁止任何未来的访问。但是，我们允许将值移回 val 的内存：

1
2
3
4
5

let mut val = Struct { ... };
let x = &own val;
drop(x);
val = Struct { ... };
let y = &own val;

&'a own T 中的生命周期 'a 是底层内存的生命周期。这意味着当 'a 到期时，内存也不再有效（或者更准确地说，无法证明它在 'a 之后有效）。因此，必须在 'a 到期之前丢弃（或遗忘）一个 &'a own T（因为在之后就不能再丢弃它了）。

&own T 本身支持移动投影（另一个表明拥有它们是好主意的迹象）。但仅限于不实现 Drop 的类型（类似于普通的结构体解构——也有关于解除此限制的讨论，但投影 &own 不会产生新问题）。

&own 和固定 为了使 &pin own T 在 T: !Unpin 时，面对恐慌（panics）仍然是健全的，我们必须添加丢弃标志（drop flags）或拥有不可遗忘的类型。我们在下面探索了一个使用丢弃标志的设计；同时正在进行关于 Leak/Forget 特性的实验，我认为这至少对于 &own 来说可能是比丢弃标志更好的解决方案。

我们需要丢弃标志来确保固定值的丢弃保证。丢弃标志将在创建原始 &own 时存储，并存活在创建它的函数的栈帧中。它们在以下场景中是必需的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

fn foo() {
    let x = Struct { ... };
    bar(&pin own x);
}

fn bar(x: &pin own Struct) {
    if random() {
        std::mem::forget(x);
    }
    if random() {
        panic!()
    }
}

由于 x 被固定在栈上，它需要在 foo 返回之前被丢弃（即使发生展开）。当 bar 遗忘这个所有权引用时，析构函数不会运行，如果此时它发生恐慌，则需要在 foo 中运行析构函数。但由于它已经将 x 的所有权交给了 bar，bar 可能已经丢弃了 x（当第一个 random() 调用返回 false 时就是这种情况）。为了跟踪这一点，我们需要在 foo 的栈帧中设置一个丢弃标志，当 x 被丢弃时将其设置为 true。

丢弃标志存在几个问题：

1. 我们不能拥有指向非静态值（例如来自 Box::leak_owned 函数）的 &'static own T。
2. 字段投影使情况复杂化：如果我们投影到一个字段，那么我们可能遗忘一个字段，但丢弃另一个字段。
   • 解决方案：不仅为整个结构体存储丢弃标志，还要为所有实现 Drop 的传递性字段存储。
3. &own T 和 &pin own T 之间存在不同的行为，前者可以被遗忘且析构函数不会运行，后者也可以被遗忘，但无论如何析构函数都会运行。

最后一点使我相信，实际上我们希望 &pin own T: !Leak when T: !Leak；但据我所知，这不会阻止以下代码工作：

1
2
3
4
5

fn main() { 
    let x = Struct { ... };
    let x = &pin own x;
    Box::leak(Box::new(x));
}

DerefMove DerefMove 操作和特征在过去已经讨论过（不过我还没有找到相关的讨论）。它是 &own 相对于 Deref 的类似操作。我们需要理清它与 Deref 和 DerefMut 的层级关系，但暂时忽略这个问题，DerefMove 看起来会是这样：

1
2
3
4
5

trait DerefMove: DropHusk {
    trait Target: ?Sized;

    fn deref_move(&own self) -> &own Self::Target;
}

注意超特征要求 DropHusk —— 它为 Self 提供了一个特殊的丢弃操作，当 &own Self::Target 引用被丢弃时使用。例如，Box<T> 将通过 DropHusk 释放底层内存。其定义如下：

1
2
3

pub unsafe trait DropHusk {
    unsafe fn drop_husk(husk: *mut Self);
}

我们当然也会将这个特征用于 ProjectMove。单独实现 DropHusk 没有任何作用；实现 DerefMove 或 ProjectMove 将使编译器在值超出作用域并已被投影或调用了 DerefMove::deref_move 后，调用 drop_husk 而不是 Drop::drop。

我们观察到 DerefMove 在可用性上比 Deref 限制得多 —— 我们需要投影来使其在常见情况下真正有用。原因是 &own 只能创建一次，但人们希望每个字段都能创建一次（这正是移动投影所允许的）。考虑这个例子：

1
2
3

let b = Box::new(Struct { ... });
let field1 = &own b.field1; // 脱糖为 `DerefMove::deref_move`
let field2 = &own b.field2; //~ 错误：不能拥有 `b` 两次

“不能拥有 b 两次"错误源于解糖的工作方式：

1
2
3
4

let b = Box::new(Struct { ... });
let field1 = &own DerefMove::deref_move(&own b).f1;
let field2 = &own DerefMove::deref_move(&own b).f2;
//                                       ^^^ 错误：不能拥有 `b` 两次

现在很清楚，我们试图创建两个 &own 指向同一个值，这是行不通的（对于 &mut 也存在同样的问题，但这已经被 ProjectExclusive 覆盖了）。

我们可以这样写：

1
2
3
4

let b = Box::new(Struct { ... });
let b = &own b;
let field1 = &own b.field1;
let field2 = &own b.field2;

但这很繁琐。

我们还注意到 ProjectMove 是 ArcRef 的正确投影，因为它避免了任何额外的引用计数更新。我们可以依赖提议的"人性化引用计数"特性来提供克隆值和执行更多投影的人性化方法。

详细更新 (2025-11-02)

拥有单一的 Project 特征 现在这 3 个 Project* 特征的定义几乎完全相同，所以我们花了一些时间尝试将它们统一为一个特征。虽然我们无法摆脱拥有三个特征的必要性，但我们可以通过添加泛型将它们合并为一个：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#[sealed]
pub trait ProjectKind {
    type Ptr<T: ?Sized>;
}

pub enum Shared {}
pub enum Exclusive {}

impl ProjectKind for Shared {
    type Ptr<T: ?Sized> = *const T;
}

impl ProjectKind for Exclusive {
    type Ptr<T: ?Sized> = *mut T;
}

pub trait Projectable {
    type Target;
}

pub unsafe trait Project<Kind: ProjectKind>: Projectable {
    type Output<'a, F: Field<Base = Self::Target>>;

    unsafe fn project<'a, F: Field<Base = Self::Target>>(
        this: Kind::Ptr<Self>,
    ) -> Self::Output<'a, F>;
}

我们需要一些更多的编译器魔法来确保没有人泛型地实现这个特征，比如 impl<K> Project<K> for MyType，以保持我们的方法可扩展（如果这在其他情况下也有用，可以是一个属性 #[rustc_deny_generic_impls]）。

合并定义的好处是，我们只需要记录一个单一的特征，并且我们还可以在 ProjectKind 类型上添加文档。也存在一些人体工程学上的缺点，例如所有输出类型现在都叫 Output，因此如果存在多个投影实现，就需要完全限定（<MyType as Project<Exclusive>>::Output<'_, F> 对比 MyType::OutputExclusive<'_, F>）。

为了使这个提议与移动投影兼容，我们还需要更多的编译器魔法来确保如果 Kind = Move，我们要求 Self: DropHusk。或者我们可以使用关联特征，并在 ProjectKind 中添加一个，然后在 Project 中使用（Kind = Shared 会将其设置为 Pointee）。

这种方法也让我更多地思考语法，如果将来我们发现更多的投影，采用一种可扩展的方法可能更有意义，例如 @keyword expr{->,.@,.,~}ident（例如 @move x->y 或 @mut x.y）。

详细更新 (2025-11-06)

新视角：通过位置进行投影 @Nadrieril 在一个 Zulip 主题中提出了"重借用字段的常规 Rust 方式使用位置"的想法。然后他开始为字段投影构思一个类似的设计，但有一个关键区别：将位置作为基本构建块。我们在该主题中进行了非常长的讨论（交换了关于字段投影的现有想法和涉及位置的新想法），最终形成了 @Nadrieril 的这篇精彩总结：https://hackmd.io/[@Nadrieril][]/HJ0tuCO1-e。这是一份非常详尽的文档，这里只能部分总结：

• 代替 Project* 特征，我们拥有 Place* 特征，这些特征管理在给定 x: MySmartPtr 时，对 *x 可以执行何种位置操作（读取、写入和借用）。
• 我们可以允许自定义智能指针重借用，可能使用语法 @MySmartPtr <place-expr>。
• 我们需要多重投影以允许 &mut x.field.a 和 &mut x.field.b 同时存在。

在这个提议中，我们仍然有许多需要充实的地方（其中一些由 @Nadrieril 指出）：

• FRT（未来引用类型）如何融入其中？实现 Projection 特征的类型是什么？
• 对于像 MaybeUninit<T>、UnsafeCell<T> 和 ManuallyDrop<T> 这样的非间接位置容器，我们该怎么做？
• BorrowKind 能作为借用检查器的模型吗？
• 我们如何使匹配的人体工程学良好地工作？
• 我们如何绕过孤儿规则的限制？
• 几个较小的问题/疑问…

这是一个非常有趣的视角，我倾向于将其作为主要的提议想法。这些特征与当前的字段投影设计没有太大不同，并且特殊的借用检查器行为也至少在字段的第一层被考虑。因此，这是字段投影提议的自然演变。非常感谢 @Nadrieril 的出色总结！

重借用特征 (rust-lang/rust-project-goals#399)

进度

联系人：Aapo Alasuutari
负责人：Aapo Alasuutari
冠军团队：编译器 (Oliver Scherer), 语言团队 (Tyler Mandry)

详细更新 (2025-11-11) 我们一直在努力实现 CoerceShared 特征的连贯性检查，并得出结论（至少作为第一步）只有一个生命周期，即第一个生命周期，应参与重借用。关于如何为 CoerceShared 存储字段映射的问题很多。

“灵活、快速(er)的编译”

build-std (rust-lang/rust-project-goals#274)

进度

联系人：David Wood
负责人：Adam Gemmell, David Wood
冠军团队：cargo (Eric Huss), 编译器 (David Wood), 库 (Amanieu d’Antras)

详细更新 (2025-11-22) 我们的第一个 RFC - rust-lang/rfcs#3873 - 正在 FCP（最终评论期）过程中，等待勾选框被选中。rust-lang/rfcs#3874 和 rust-lang/rfcs#3875 正在接收反馈，我们正在处理这些反馈。

生产就绪的 Cranelift 后端 (rust-lang/rust-project-goals#397)

进度

联系人：Folkert de Vries
负责人：bjorn3, Folkert de Vries, [Trifecta Tech Foundation]
冠军团队：编译器 (bjorn3)

无详细更新。

推进并行前端 (rust-lang/rust-project-goals#121)

进度

联系人：Sparrow Li
负责人：Sparrow Li

无详细更新。

重新链接而非重新构建 (rust-lang/rust-project-goals#400)

进度

联系人：Jane Lusby
负责人：@dropbear32, @osiewicz
冠军团队：cargo (Weihang Lo), 编译器 (Oliver Scherer)

详细更新 (2025-11-21) 在此处链接，以便人们了解为什么这个项目目标没有进展。 #t-compiler > 2025H2 Goal Review @ 💬

“更高级别的 Rust”

人性化引用计数：RFC 决策和预览 (rust-lang/rust-project-goals#107)

进度

联系人：Niko Matsakis
负责人：Niko Matsakis, Santiago Pastorino
冠军团队：编译器 (Santiago Pastorino), 语言团队 (Niko Matsakis)

详细更新 (2025-11-05) 三篇新博客文章：

• 显式捕获子句
• 关于 Handle 的命名和其他后续想法
• 但是再次…也许叫 Alias？

这些文章中最重要的结论是：

• 显式捕获子句将很有用，我提出了一个特定的语法，但需要讨论。为了"人性化”，我们需要能够引用完整的位置，例如 move(cx.foo.clone()) || use(cx.foo)。
• 我们应该考虑将 Handle 特征命名为 Alias 或 Share；目前我倾向于 Alias，因为它既可以用作名词也可以用作动词，并且更类似于 clone —— 也就是说，你可以说"foo 的一个别名"，就像你会说"foo 的一个克隆"一样。
• 我们应该寻找同样适用于 clone 和 alias 的解决方案，这样即使克隆"重量级"类型（Alias 不适用的类型）时，更高级别的 Rust 也能获得人体工程学上的好处。

详细更新 (2025-11-12) 新博客文章：https://smallcultfollowing.com/babysteps/blog/2025/11/10/just-call-clone/

探索一种在保持显式的同时更人性化的方法，即使 .clone() 和 .alias() (1) 被移动闭包脱糖理解，并且 (2) 在冗余时被优化掉。

稳定 cargo-script (rust-lang/rust-project-goals#119)

进度

联系人：Ed Page
负责人：Ed Page
冠军团队：cargo (Ed Page), 语言团队 (Josh Triplett), 语言文档团队 (Josh Triplett)

详细更新 (2025-11-21)

关键进展：rust-lang/rust#148051

阻碍因素：rustdoc 决定并实现在 doctest 中如何处理 frontmatter。

“解锁停滞的特征”

演进特征层次结构 (rust-lang/rust-project-goals#393)

进度

联系人：Taylor Cramer
负责人：Taylor Cramer, Taylor Cramer 及其他人
冠军团队：语言团队 (Taylor Cramer), 类型团队 (Oliver Scherer)

无详细更新。

原地初始化 (rust-lang/rust-project-goals#395)

进度

联系人：Alice Ryhl
负责人：Benno Lossin, Alice Ryhl, Michael Goulet, Taylor Cramer, Josh Triplett, Gary Guo, Yoshua Wuyts
冠军团队：语言团队 (Taylor Cramer)

详细更新 (2025-11-14) 11月12日，Xiangfei Ding 组织了一场关于原地初始化的小型设计会议。与会者包括 Xiangfei Ding、Alice Ryhl、Benno Lossin、Tyler Mandry 和 Taylor Cramer。 我们讨论了这份文档：https://hackmd.io/@rust-for-linux-/H11r2RXpgl

新一代特征求解器 (rust-lang/rust-project-goals#113)

进度

联系人：lcnr
负责人：Boxy, Michael Goulet, lcnr
冠军团队：类型团队 (lcnr)

详细更新 (2025-11-13) 新的求解器现已正式被 Rust Analyzer 使用：https://rust-analyzer.github.io/thisweek/2025/10/27/changelog-299.html。非常感谢 Jack Huey Chayim Refael Friedman Shoyu Vanilla 和 Laurențiu Nicola 的这项工作。

在 rustc 方面，Rémy Rakic 花了很多时间分析最近的 crater 运行结果。这发现了一批新的边缘情况，导致产生了 6 个新的追踪问题。

展望未来，我们打算继续进行 crater 分析，同时修复剩余问题，直到我们准备好稳定化：）剩余问题在 https://github.com/orgs/rust-lang/projects/61/views/1 中追踪。

可在 nightly 上稳定的 Polonius 支持 (rust-lang/rust-project-goals#118)

进度

联系人：Rémy Rakic
负责人：Amanda Stjerna, Rémy Rakic, Niko Matsakis
冠军团队：类型团队 (Jack Huey)

详细更新 (2025-11-25)

关键进展：

• 我构建了修复活跃性健全性问题的原型，但这被认为太脆弱。

• 因此，我们为类型团队准备了一次会议来讨论该问题和可能的解决方案。

• 我们准备了另一次类型团队会议，以讨论 Polonius 总体情况，特别是 alpha 算法，以便在团队内分享知识。这也将有助于以后以位置敏感的方式应用成员约束，因为目前它们是在 SCC 级别应用的，我们需要确保这些带有选择区域的约束存在于局部子集图中。

• niko 和 tiif 在 a-mir-formality 中添加借用检查支持方面取得了很大进展，所以我也参加了这些会议，因为我们还需要对 alpha 进行建模。

• 我研究了 Prusti 的 Place Capability Graphs，并计划了解如何将 alpha 集成到其中，如果可能的话，结合论文中提到的模糊测试能力，目标一如既往是扩大测试范围，正如我们多次提到的。

• 我们还讨论了一个可能的研究生项目，并思考了不同的实践和理论课题。

寻求帮助的目标

其他目标更新

为 rustdoc 团队添加章程 (rust-lang/rust-project-goals#387)

进度

联系人：Guillaume Gomez
冠军团队：rustdoc (Guillaume Gomez)

详细更新 (2025-11-21) 在 https://github.com/rust-lang/rust-forge/pull/852 中已完成。

在 a-mir-formality 中进行借用检查 (rust-lang/rust-project-goals#122)

进度

联系人：Niko Matsakis
负责人：Niko Matsakis, tiif
冠军团队：类型团队 (Niko Matsakis)

详细更新 (2025-11-05) tiif 和我每周都在这里会面，并向 a-mir-formality/nikomatsakis 的 living-large 分支推送更改。我们正在取得进展，我们有一个 minirust 类型检查器和借用检查器的雏形。我们决定尝试使用"判断式"方法，而不是将其建模为数据流，因为我认为这将更深入地揭示特征检查器的"结构"。

详细更新 (2025-11-12) tiif、Jack Huey 和我今天会面，并在"living-large"分支上做了更多工作。借用检查判断正在成型。我的预期是，我们将遍历 CFG，跟踪到目前为止发生的借用集合。在每个语句处，我们将有一个判断，该判断查看 (a) 由类型检查生成的子类型关系（与流量无关，类似于 NLL）；(b) 已发出且尚未终止的借用；以及 (c) 稍后可能被访问的活跃位置。然后我们将要求，如果你正在访问一个位置 P，那么从活跃位置可访问的借用中没有以不兼容的方式借用 P 的。

详细更新 (2025-11-19) 本周继续工作：详细阐述了一些关于访问或语句何时有效的定义。我们正在努力构建我们认为将是"很大程度上准确"的当前 NLL 模型——显然，然后我们会想要测试它，并比较在各种边缘情况下的行为。

C++/Rust 互操作问题空间映射 (rust-lang/rust-project-goals#388)

进度

联系人：Jon Bauman
负责人：Jon Bauman
冠军团队：编译器 (Oliver Scherer), 语言团队 (Tyler Mandry), 库 (David Tolnay)

详细更新 (2025-11-26)

关键进展：自上次更新以来发生了什么。如果确实是"没什么"，完全可以列出"没什么"，我们知道人们很忙。 没什么！这是第一次更新，我还未将注意力集中在这个项目目标上。作为背景，我受雇于 Rust 基金会领导 C++ 互操作性计划，到目前为止一直在执行问题陈述中详述的策略。由于取得了超出预期的成功以及与 WG21 会议相关的截止日期，我最近一直专注于社交互操作性策略。我刚刚达到一个可以将更多注意力转向其他策略的阶段，因此预计很快能在这个目标上取得进展。

阻碍因素：列出你正在等待的 Rust 团队以及你在等待什么。 没有；项目在各个方面都给了我极好的支持。我迄今的成功没有他们是不可能的，而且在此空间无法一一列举。不久将有一篇博客文章详细介绍过去一年该计划的工作，我打算在其中深入细节。请关注此空间以获取更新。

寻求帮助：是否有需要更广泛社区贡献或反馈的地方？ 我总是对贡献和反馈感兴趣。如果你有兴趣，请通过 interop@rustfoundation.org 或 t-lang/interop 联系我们。

Rust 的全面利基检查 (rust-lang/rust-project-goals#262)

进度

联系人：Bastian Kersting
负责人：Bastian Kersting, Jakob Koschel
冠军团队：编译器 (Ben Kimock), 操作语义团队 (Ben Kimock)

无详细更新。

常量泛型 (rust-lang/rust-project-goals#100)

进度

联系人：Boxy
负责人：Boxy, Noah Lev
冠军团队：语言团队 (Niko Matsakis)

详细更新 (2025-11-05) 自从语言会议以来，这个项目目标上的大部分进展都与 adt_const_params 无关。

在 min_generic_const_args 上做了大量工作，特别是 Noah Lev 的 PR (rust-lang/rust#139558)，一旦落地，该功能的核心实现工作就完成了。我与 Oliver Scherer 一起评审了它，它几乎已经准备就绪，只需一些小评审。

一旦这个 PR 落地，我希望会有一批"较小"的 PR 可以做，这可以成为指导新贡献者的一组很好的 PR。

详细更新 (2025-11-29) 再次，这里的大部分进展都在 min_generic_const_args 上。

Noah Lev 的 PR (rust-lang/rust#139558) 现在已经落地，以及他的另一个 PR：rust-lang/rust#148716。在这两个 PR 之间，核心实现现在应该"大部分完成"了，至少在没有启用额外功能门的情况下 :)。

下一步是使 min_generic_const_args 原型与 adt_const_params 良好协作，我已经在 rust-lang/rust#149136 和 rust-lang/rust#149114 中自己实现了。这些 PR 仍需要评审，但那里的实现主体工作现在已经完成。这些 PR 允许构造 ADT，其中字段值本身可以是常量参数或 type_consts 的非具体用法（即值是常量参数位置）。

一旦我的 PR 落地，我会将 mgca 作为一个原型视为真正"完成"，尽管作为实际功能尚未完成。非常感谢 camelid 坚持完成了许多相当痛苦的 PR，让我们走到了这一步。

继续解决 cargo-semver-checks 合并到 cargo 中的障碍 (rust-lang/rust-project-goals#104)

进度

联系人：Predrag Gruevski
负责人：Predrag Gruevski
冠军团队：cargo (Ed Page), rustdoc (Alona Enraght-Moony)

详细更新 (2025-11-02) 截至 11月1日 的状态更新 关键进展：

• 在 rustdoc JSON 中暴露隐含边界的草案 PR：https://github.com/rust-lang/rust/pull/148379
• 关于这些新信息如何转化为涵盖多种边界的数十个新 lint 的具体计划

事实证明，检查 ?Sized 和 'static 边界比我预想的要复杂得多。关键问题是，看到 T: Foo + ?Sized 并不能保证 T 可以是非大小的，因为我们可能有 Foo: Sized，这使得 ?Sized 的放宽无效。同样，看到 T: Foo 也可能通过类似的隐含边界隐含 T: 'static。

未能正确考虑隐含边界将导致灾难性的误报和漏报。例如，将 T: Foo 改为 T: Foo + 'static 可能是一个重大的破坏性更改，也可能是无操作，具体取决于我们是否有 Foo: 'static（直接或通过其他特征边界隐含）。 我们无法使用今天 rustdoc JSON 中存在的信息来确定隐含边界，因此 rustdoc 团队和我一直在迭代在 rustdoc JSON 中计算和包含该信息的最佳方法。假设类似于上述 PR 的内容成为 rustdoc JSON 的一部分，cargo-semver-checks 有望获得几十个新 lint，涵盖与特征关联类型、泛型类型参数以及 APIT/RPIT/RPITIT 相关的这些棘手情况。

详细更新 (2025-11-23) Google Summer of Code 2025 已完成 + 跨 crate lint 终于有所进展！🚀

关键进展：

• 两名学生成功完成了 Google Summer of Code，致力于 cargo-semver-checks —— 更多详细信息请参见此处！

• rustdoc JSON 现在包含 rlib 信息，遵循 RustWeek 2025 创建的跨 crate rustdoc JSON 信息的设计：https://github.com/rust-lang/rust/pull/149043

• 一旦解决，我们将有足够的信息来构建一个基本原型。由于存在更多的 cargo 相关边缘情况，在依赖项中正确处理特性可能需要更多工作。

开发保持 FLS 最新的能力 (rust-lang/rust-project-goals#391)

进度

联系人：Pete LeVasseur
负责人：Pete LeVasseur, Ferrous Systems 的贡献者和其他待定成员, t-spec 和 Ferrous Systems 的贡献者
冠军团队：bootstrap (Jakub Beránek), 语言团队 (Niko Matsakis), spec (Pete LeVasseur)

详细更新 (2025-11-05) 2025-10-31 举行的会议纪要（感谢 Tomas Sedovic 🥰）

总体：

• 保持高质量标准，尽可能合并经过充分审查的小变更
• 需要集中努力将 1.90 FLS 更新合并

Hristian Kirtchev 和 Tshepang Mbambo 目前正在与 TC 一起解决这个问题。

• 一旦 1.90 合并，我们作为团队将第一次尝试处理 1.91

讨论：

• 建议每个人都从阅读术语表开始

• 如何最好地分类/处理传入的问题？

  • TC 和 Pete LeVasseur 将必要的标签移到了 FLS 仓库上
  • Pete LeVasseur 创建了问题模板（正在审查中）以帮助集中分类

详细更新 (2025-11-21) 会议纪要见：2025-11-14 - t-fls Meeting

关键进展：FLS 1.90 更新的 PR 已合并。我们现在正准备处理 FLS 的 1.91 更新。

阻碍因素：目前没有

寻求帮助：任何熟悉 Rust 参考手册的人都非常鼓励通读 FLS，以了解其内容以及可能进一步统一的地方。当你发现问题时，请随时在 FLS 仓库上提交问题。

在代码生成中发出重标记 (rust-lang/rust-project-goals#392)

进度

联系人：Ian McCormack
负责人：Ian McCormack
冠军团队：编译器 (Ralf Jung), 操作语义团队 (Ralf Jung)

详细更新 (2025-11-11) 我们已经发布了一份征求意见的预 RFC，并将继续在这里更新和扩展草案。这反映了当前实现的大部分状态，除了精确跟踪内部可变性，这仍然是待定事项，但在 RFC 中有所描述。

扩展 Rust 参考手册以指定更多 Rust 语言方面 (rust-lang/rust-project-goals#394)

进度

联系人：Josh Triplett
负责人：Amanieu d’Antras, Guillaume Gomez, Jack Huey, Josh Triplett, lcnr, Mara Bos, Vadim Petrochenkov, Jane Lusby
冠军团队：语言文档团队 (Josh Triplett), spec (Josh Triplett)

详细更新 (2025-11-12) 我们正在 https://rust-lang.github.io/project-goal-reference-expansion/ 整理我们的参考手册更改的原型/演示。这包括演示提供稳定性标记的工具更改（既"记录不稳定的 Rust"也"对稳定的 Rust 进行不稳定的文档记录"）。

完成 libtest json 输出实验 (rust-lang/rust-project-goals#255)

**