项目目标更新 - 2025年7月

2025年8月5日 · Tomas Sedovic
代表目标团队

Rust项目目前正在推进40个项目目标，其中3个被指定为旗舰目标。本文提供了我们在这些目标进展方面的精选更新（在某些情况下，也包括进展不足的情况）。任何特定目标的完整细节可在rust-project-goals仓库的相关跟踪问题中找到。

这是2025年上半年的最终更新。我们正在为下半年选择目标。

以下是当前为2025年下半年提议的目标。

旗舰目标

将异步Rust体验提升至接近同步Rust的水平

为什么设定这个目标？ 这项工作延续了我们改进Rust异步编程支持的努力。在2024年下半年，我们稳定了异步闭包；探索了生成器设计空间；并开始开发dynosaur crate，这是一个实验性的proc-macro，用于为trait中的异步函数提供动态分发。在2025年上半年，我们的计划是交付：(1) 改进的trait中异步函数支持，完全包含async-trait crate的功能；(2) 同步和异步生成器的进展，简化迭代器和异步数据流的创建；(3) 改进Pin的人机工程学，使低级异步编码更易上手。这些项目共同开始解除在更广泛生态系统中创建下一代异步库的阻碍，因为那里的进展一直被异步trait和流的稳定解决方案所阻碍。

@tmandry的H1回顾：

进展顺利的方面： 这个周期我们在几个领域看到了显著进展：

• 我们与语言团队就生成器进行了富有成效的对话，并落地了一个内置iter!宏的实验性实现，该宏实现了未固定的生成器。
• 我们作为Rust 2024的一部分发布了异步闭包和新的生命周期捕获规则。
• 我们开发了一个proc宏dynosaur，可用于支持异步函数与dyn Trait一起使用。
• 我们在编译器中落地了一个支持异步Drop的早期实验。
• 我们落地了固定引用自动重新借用的实验性实现，以及许多其他pin人机工程学的改进。

未达预期的方面： 在某些领域，我们没有取得预期的进展。回顾起来，这个目标的范围对一个人来说太大了。对于旗舰项目目标，有一种描绘宏伟愿景的愿望，我认为这最好由另一种没有时间限制的机制来服务。我一直在称此为"北极星"。

在某些情况下，如RTN，进展受到Rust编译器类型系统中技术债务的阻碍。为此，有一个正在进行的项目目标，用下一代版本替换trait求解器。最后，在设计方面，进展有时因关于Rust语言中固定未来方向的不确定性和分歧而放缓。

展望未来： 我的收获是，在下一个项目目标周期中，我们应该专注于回答Rust演变的更基本问题。这些应减少不确定性，并为我们解除未来周期中异步主要功能的阻碍铺平道路。例如，我们能在pin人机工程学方面推进多远？我们应该采取什么方法进行原地初始化，它能支持dyn Trait中的异步函数吗？我们将如何以通用方式支持演化的trait层次结构，使我们能够支持带有异步函数的Tower"中间件"模式？

我对我们为下一个周期准备的目标阵容感到兴奋。期待后续进展！

提供2个详细更新。

@tmandry于2025年7月17日评论：

dynosaur v0.3已发布。此版本包含一些破坏性更改，为即将到来的1.0版本做准备。有关详细信息，请参阅链接的发布说明。

@tmandry于2025年7月30日评论：

H1回顾

进展顺利的方面： 这个周期我们在几个领域看到了显著进展：

• 我们与语言团队就生成器进行了富有成效的对话，并落地了一个内置iter!宏的实验性实现，该宏实现了未固定的生成器。
• 我们作为Rust 2024的一部分发布了异步闭包和新的生命周期捕获规则。
• 我们开发了一个proc宏dynosaur，可用于支持异步函数与dyn Trait一起使用。
• 我们在编译器中落地了一个支持异步Drop的早期实验。
• 我们落地了固定引用自动重新借用的实验性实现，以及许多其他pin人机工程学的改进。

未达预期的方面： 在某些领域，我们没有取得预期的进展。回顾起来，这个目标的范围对一个人来说太大了。对于旗舰项目目标，有一种描绘宏伟愿景的愿望，我认为这最好由另一种没有时间限制的机制来服务。我一直在称此为"北极星"。

在某些情况下，如RTN，进展受到Rust编译器类型系统中技术债务的阻碍。为此，有一个正在进行的项目目标，用下一代版本替换trait求解器。最后，在设计方面，进展有时因关于Rust语言中固定未来方向的不确定性和分歧而放缓。

展望未来： 我的收获是，在下一个项目目标周期中，我们应该专注于回答Rust演变的更基本问题。这些应减少不确定性，并为我们解除未来周期中异步主要功能的阻碍铺平道路。例如，我们能在pin人机工程学方面推进多远？我们应该采取什么方法进行原地初始化，它能支持dyn Trait中的异步函数吗？我们将如何以通用方式支持演化的trait层次结构，使我们能够支持带有异步函数的Tower"中间件"模式？

我对我们为下一个周期准备的目标阵容感到兴奋。期待后续进展！

组织Rust全体大会2025

为什么设定这个目标？ 2025年5月15日标志着Rust 1.0发布的10周年；也标志着Rust子团队创建10周年。当时有6个Rust团队，总共24人。现在有57个团队，166人。面对面的全体大会会议是帮助这些维护者通过高带宽讨论相互了解的有效方式。今年，Rust项目将齐聚RustWeek 2025，这是与RustNL共同组织的联合活动。参与的项目团队将利用这段时间分享知识、制定计划，或只是更好地相互了解。全体大会的一个特定目标是审查Rust愿景文档草案，该文件旨在评估Rust的现状并为未来几年制定高级目标。

稳定Linux Rust所需的工具

为什么设定这个目标？ 这个目标延续了我们从2024年下半年开始的支持Linux内核中Rust开发实验性工作。在2024年下半年我们专注于稳定所需的语言特性，而在2025年上半年我们的重点是稳定编译器标志和工具选项。我们将(1) 实现RFC #3716，该RFC制定了修改ABI标志的设计；(2) 通过创建使用特定编译器选项重建core的稳定方式，向稳定build-std迈出第一步；(3) 扩展rustdoc、clippy和编译器，添加提取元数据以集成到其他构建系统（在这种情况下是内核构建系统）的特性。

发生了什么？

• Ding打开了实现原地初始化实验的PR#142518。
• Ding正在为arbitrary_self_types进行实验性实现（PR#143527）。
• Ding向Clang（LLVM的C前端）打开了一个PR：关于GCC风格内联汇编语句的查询，并已合并。
• @ojeda为下一阶段打开了两个Rust for Linux目标：
  • https://github.com/rust-lang/rust-project-goals/pull/347
  • https://github.com/rust-lang/rust-project-goals/pull/346

提供2个详细更新。

@tomassedovic于2025年7月7日评论：

原地初始化 Ding打开了实现原地初始化实验的PR#142518。

arbitrary_self_types Ding正在为arbitrary_self_types进行实验性实现（PR#143527）。

关于GCC风格内联汇编语句的查询： Ding向Clang（LLVM的C前端）打开了一个PR：https://github.com/llvm/llvm-project/pull/143424 并已合并。

-Zindirect-branch-cs-prefix： 我们讨论了这是需要单独的目标特性还是现有retpoline的修饰符。Josh认为，由于在没有retpoline的情况下启用此功能没有意义，它应该是一个修饰符。另一方面，Miguel提到在用户端会更清晰（当名称相同且我们看到在Rust和Linux内核的Makefiles中启用相同功能时，更容易将名称从GCC和Clang映射到rustc）。 似乎-Cmin-function-alignment将是另一个类似情况。 最终，这是一个编译器问题，应在此处解决：https://github.com/rust-lang/rust/pull/140740

稳定AddressSanitizer和LeakSanitizer：

• https://github.com/rust-lang/rust/pull/123617
• https://github.com/rust-lang/rust/pull/142681

鉴于新提议的#[sanitize(xyz = “on|off”)]语法，我们讨论了是否添加一个简写来同时启用/禁用所有这些功能（例如#[sanitize(all = “on|off”)]）有意义。来自该领域的经验表明，这很少是人们会做的事情。 我们还讨论了选项应该有什么值（例如"yes"/“no” vs. “on”/“off"或true/false）。没有强烈偏好，但在出错的情况下，编译器应建议使用的正确值。

@tomassedovic于2025年7月18日评论：

2025年下半年目标 @ojeda提出了两个目标以推进工作：一个用于语言，另一个用于编译器。

• https://github.com/rust-lang/rust-project-goals/pull/347
• https://github.com/rust-lang/rust-project-goals/pull/346

正在进行的工作更新 @dingxiangfei2009为supertrait-item-in-subtrait-impl工作起草了一个Pre-RFC。需要向RFC添加两个修改以纳入t-lang请求。

寻求帮助的目标

推广并行前端

需要帮助： 帮助测试问题列表中的死锁代码并尝试重现问题

提供1个详细更新。

@SparrowLii于2025年7月11日评论：

关键进展： 我们将rustc-rayon引入rustc的工作树，修复了几个死锁问题的PR已合并。 阻碍因素： 无 需要帮助： 帮助测试问题列表中的死锁代码并尝试重现问题

稳定公共/私有依赖

需要帮助： 这个项目目标需要编译器开发人员来推进。

提供3个详细更新。

@epage于2025年7月10日评论：

需要帮助：这个项目目标需要编译器开发人员来推进。

@sladyn98于2025年7月11日评论：

@epage 嘿，我想帮助贡献这个，如果你能指导我正确的方向，我可以学习并提升能力来推进这个，我可以从一些任务开始，将它们分解成小块并贡献

@epage于2025年7月11日评论：

这目前主要在编译器中，我无法指导或审查编译器更改；我的第一个编译器PR正在合并中。我主要从Cargo端和整体协调参与这个。

稳定cargo-script

需要帮助： 我将致力于验证rustfmt、rust-analyzer和其他工具支持，并将至少需要人们的审查，如果不是一些指导的话。

提供1个详细更新。

@epage于2025年7月10日评论：

关键进展：

• @epage现在将注意力转回这个，因为toml v0.9已发布
• 正在rust-lang/rust#143708中添加-Zunpretty支持

阻碍因素 需要帮助 我将致力于验证rustfmt、rust-analyzer和其他工具支持，并将至少需要人们的审查，如果不是一些指导的话。

其他目标更新

扩展常量泛型的"可稳定"原型

提供1个详细更新。

@BoxyUwU于2025年7月25日评论：

自上次更新以来没什么可说的 - 我一直专注于常量泛型的其他领域，我相信camelid也相对忙于其他事情。我打算让下一个常量泛型项目目标的范围比min_generic_const_args更广，以便其他常量泛型工作可以在这里总结 :)

build-std

讨论了预RFC的最新一轮反馈，其中最重要的是RFC的范围对于MVP来说几乎肯定太大了。 @davidtwco提出了计划的重构，专注于build-std的核心组件，并将更多特性留给最小MVP之后的未来扩展：

• 阶段1a：在Cargo中引入启用build-std行为的手动控制。

• 阶段1b：引入Cargo语法来声明对core、alloc和std crate的显式依赖。

  • 此阶段允许在稳定Rust上使用第3层目标，并允许生态系统开始过渡到对标准库的显式依赖。
  • 此阶段将被视为最小MVP。

• 阶段2：教导Cargo使用不同的代码生成/目标修饰符选项构建std。

  • 此阶段允许使用自定义代码生成选项编译标准库。

• 阶段3：启用自动标准库重建。

  • 此阶段专注于使build-std行为符合人机工程学且自然，无需用户手动要求构建标准库。

达成了普遍共识，认为这个计划感觉可行。@davidtwco将编写阶段1a/b RFC。 已提交2025年下半年目标提案。

提供2个详细更新。

@wesleywiser于2025年7月22日评论：

双周同步会议更新：

• 讨论了预RFC的最新一轮反馈，其中最重要的是RFC的范围对于MVP来说几乎肯定太大了。

• @davidtwco提出了计划的重构，专注于build-std的核心组件，并将更多特性留给最小MVP之后的未来扩展：

  • 阶段1a：在Cargo中引入启用build-std行为的手动控制。

  • 阶段1b：引入Cargo语法来声明对core、alloc和std crate的显式依赖。

    • 此阶段允许在稳定Rust上使用第3层目标，并允许生态系统开始过渡到对标准库的显式依赖。
    • 此阶段将被视为最小MVP。

  • 阶段2：教导Cargo使用不同的代码生成/目标修饰符选项构建std。

    • 此阶段允许使用自定义代码生成选项编译标准库。

  • 阶段3：启用自动标准库重建。

    • 此阶段专注于使build-std行为符合人机工程学且自然，无需用户手动要求构建标准库。

• 达成了普遍共识，认为这个计划感觉可行。@davidtwco将编写阶段1a/b RFC。

• 对先前RFC草案的各种线程进行了一些讨论。

@wesleywiser于2025年7月28日评论：

继续build-std工作已作为2025年下半年的项目目标提交：https://rust-lang.github.io/rust-project-goals/2025h2/build-std.html

继续解决将cargo-semver-checks合并到cargo的阻碍因素

5月和6月的延迟更新：RustWeek非常有成效！与所有利益相关者坐在一个房间里讨论在大规模上可靠地进行跨crate linting需要什么条件，这真是太棒了。 由于这项工作，我们识别了许多先前未知的阻碍因素，以及一些前进路径。更多工作仍然存在，但很高兴我们现在对这项工作应该是什么样子有了更好的了解。

TL;DR：

• ?Sized linting被阻塞，因为它需要rustdoc JSON中的额外数据。

  • 目前我们获得?Sized的语法存在信息。但另一个边界可能暗示Sized，这使得?Sized总体上不成立。
  • 未能考虑这一点将意味着我们得到假阴性和假阳性。这实际上是先前帖子中"隐含边界"问题的对偶。

• 跨crate linting有了一些积极进展，并识别了额外的阻碍因素。

  • docs.rs已开始托管rustdoc JSON，允许我们将其用作缓存，以避免在跨crate linting场景中重建rustdoc JSON，这些构建可能很昂贵。
  • 我们需要一种方法来确定给定顶级crate中活动的一组特性时，依赖项中的哪些特性是活动的（递归地），以便我们知道如何生成准确的rustdoc JSON。该信息目前无法通过lockfile或任何cargo接口获得。
  • 我们需要与rustdoc和cargo团队合作，使使用rmeta文件正确组合跨crate数据成为可能。这有许多移动部件，需要时间才能正确，但基于RustWeek的面对面对话，我们都同意这是最好和最可靠的前进路径。

• 对cargo-semver-checks的其他改进正在进行中：一套完整的#[target_feature] lint将在下一个版本中发布，两位参与Google Summer of Code的人已经开始为cargo-semver-checks做出贡献！

虽然2025年上半年目标的目标在这个时间线上证明有点过于雄心勃勃，但我期待在2025年下半年期间继续我在这个目标上的工作！

提供1个详细更新。

@obi1kenobi于2025年7月4日评论：

5月和6月的延迟更新：RustWeek非常有成效！与所有利益相关者坐在一个房间里讨论在大规模上可靠地进行跨crate linting需要什么条件，这真是太棒了。 由于这项工作，我们识别了许多先前未知的阻碍因素，以及一些前进路径。更多工作仍然存在，但很高兴我们现在对这项工作应该是什么样子有了更好的了解。

TL;DR：

• ?Sized linting被阻塞，因为它需要rustdoc JSON中的额外数据。

  • 目前我们获得?Sized的语法存在信息。但另一个边界可能暗示Sized，这使得?Sized总体上不成立。
  • 未能考虑这一点将意味着我们得到假阴性和假阳性。这实际上是先前帖子中"隐含边界"问题的对偶。

• 跨crate linting有了一些积极进展，并识别了额外的阻碍因素。

  • docs.rs已开始托管rustdoc JSON，允许我们将其用作缓存，以避免在跨crate linting场景中重建rustdoc JSON，这些构建可能很昂贵。
  • 我们需要一种方法来确定给定顶级crate中活动的一组特性时，依赖项中的哪些特性是活动的（递归地），以便我们知道如何生成准确的rustdoc JSON。该信息目前无法通过lockfile或任何cargo接口获得。
  • 我们需要与rustdoc和cargo团队合作，使使用rmeta文件正确组合跨crate数据成为可能。这有许多移动部件，需要时间才能正确，但基于RustWeek的面对面对话，我们都同意这是最好和最可靠的前进路径。

• 对cargo-semver-checks的其他改进正在进行中：一套完整的#[target_feature] lint将在下一个版本中发布，两位参与Google Summer of Code的人已经开始为cargo-semver-checks做出贡献！

虽然2025年上半年目标的目标在这个时间线上证明有点过于雄心勃勃，但我期待在2025年下半年期间继续我在这个目标上的工作！

声明式（macro_rules!）宏改进

当前状态：

• @joshtriplett为属性宏和派生宏都编写了RFC。
• 在与语言团队进一步迭代后，两个RFC都被接受并合并。
• @joshtriplett、@eholk和@vincenzopalazzo在rustc中宏的实现方面进行了一些成功的群体探索。
• @joshtriplett重写了macro_rules!解析器，这实现了未来的可扩展性并产生了更好的错误消息。这随后实现了几个后续重构和简化。
• @joshtriplett编写了一个实现属性宏的PR。

提供2个详细更新。

@joshtriplett于2025年7月21日评论：

当前状态：

• @joshtriplett为属性宏和派生宏都编写了RFC。两者都被接受并合并。
• @joshtriplett、@eholk和@vincenzopalazzo在rustc中宏的实现方面进行了一些成功的群体探索。
• @joshtriplett重写了macro_rules!解析器，这实现了未来的可扩展性并产生了更好的错误消息。这随后实现了几个后续重构和简化。
• @joshtriplett编写了一个实现属性宏的PR（审查中）。

@joshtriplett于2025年7月29日评论：

更新：属性宏的实现PR已发布。

评估C++和Rust之间无缝互操作的方法

@tmandry的回顾： 这个项目目标周期对C++互操作很重要。与语言团队一起，我们确定应该发展Rust以实现一流的C++互操作故事，使两种语言之间丰富和自动的绑定成为可能。在Rust全体大会上，来自整个行业的人们会面，相互描述他们的需求，什么对他们有效，什么无效。这个发现过程导致了对我们现在可以取得进展的领域的许多见解，以及真正"解决"互操作需要什么的想法。 我认为我们可以肯定地说的一件事是，互操作是一个广阔的问题空间，任何两个想要互操作的群体很可能有不同的具体需求。我对@baumanj提出的项目目标提案感到兴奋，该提案开始在公开场合映射这个问题空间，以便在我们引用问题时可以更好地理解我们的需求在哪里重叠和分歧。 尽管需求多样，但我们注意到在语言演化方面有相当多的重叠。这包括Rust for Linux请求的许多特性，Rust for Linux是Rust项目的旗舰客户。回顾起来，这并不奇怪：Rust for Linux需要与C API的细粒度互操作，这大致是与C++ API互操作需求的子集。通常需求比互操作更深，更多的是关于在Rust中支持现有系统语言已经作为一流特性支持的模式。 我期待解决我们可以"扩展Rust基础"的领域，以使这些和其他用例成为可能。这包括H2项目目标提案，如pin人机工程学、重新借用、字段投影和原地初始化。 感谢所有在过去周期为讨论做出贡献的人。期待在下一个周期见到你！

提供2个详细更新。

@tmandry于2025年7月29日评论：

在全体大会之前，@cramertj和@tmandry合作了一个名为ecdysis的原型，探索在Rust编译器中"按需"实例化类型的可行性。这些类型旨在看起来像C++模板实例化。原型在使方向看起来可行方面是成功的，并且也浮现了一些首先需要在编译器中完成的基础工作。也就是说，继续追求它目前不是我们任何人的最高优先级。 非常感谢@oli-obk的建议和指点。

@tmandry于2025年7月29日评论：

回顾 这个项目目标周期对C++互操作很重要。与语言团队一起，我们确定应该发展Rust以实现一流的C++互操作故事，使两种语言之间丰富和自动的绑定成为可能。在Rust全体大会上，来自整个行业的人们会面，相互描述他们的需求，什么对他们有效，什么无效。这个发现过程导致了对我们现在可以取得进展的领域的许多见解，以及真正"解决"互操作需要什么的想法。 我认为我们可以肯定地说的一件事是，互操作是一个广阔的问题空间，任何两个想要互操作的群体很可能有不同的具体需求。我对@baumanj提出的项目目标提案感到兴奋，该提案开始在公开场合映射这个问题空间，以便在我们引用问题时可以更好地理解我们的需求在哪里重叠和分歧。 尽管需求多样，但我们注意到在语言演化方面有相当多的重叠。这包括Rust for Linux请求的许多特性，Rust for Linux是Rust项目的旗舰客户。回顾起来，这并不奇怪：Rust for Linux需要与C API的细粒度互操作，这大致是与C++ API互操作需求的子集。通常需求比互操作更深，更多的是关于在Rust中支持现有系统语言已经作为一流特性支持的模式。 我期待解决我们可以"扩展Rust基础"的领域，以使这些和其他用例成为可能。这包括H2项目目标提案，如pin人机工程学、重新借用、字段投影和原地初始化。 感谢所有在过去周期为讨论做出贡献的人。期待在下一个周期见到你！

实验符合人机工程学的引用计数

提供1个详细更新。

@spastorino于2025年6月30日评论：

我们目前正在研究最后使用优化。我们已经实现了所需的活跃性分析，需要广泛测试它。

公开用于GPU卸载的实验性LLVM特性

@ZuseZ4： 这个项目目标周期的最后更新！我继续致力于gpu支持，而我们的两个Rust/LLVM自动微分gsoc学生在他们相应的项目中取得了巨大进展。

关键进展：

1. 我的内存移动PR经过审查，经过几次迭代后进入nightly。这意味着你现在甚至不需要构建自己的rustc来向GPU和从GPU移动数据（具有我先前帖子中提到的限制）。作为我PR的一部分，我还更新了rustc-dev-guide：https://rustc-dev-guide.rust-lang.org/offload/installation.html。

2. 现在主机（CPU）代码已落地，我研究了将rust内核编译到GPU。当试验rustc的amdgcn目标时，我注意到一个回归，由于该回归，该目标的所有示例都失败了。我提交了一个小补丁来修复它。它在几天前落地，并阻止rustc在AMD GPU上生成f128类型：https://github.com/rust-lang/rust/pull/144383。

3. 我研究了HIP和OpenMP（托管/内核模式）示例，以查看启动内核需要什么。我应该已经有大部分代码上游，因为它作为我主机PR的一部分落地，所以我认为我应该很快能够添加剩余的粘合代码来开始在GPU上运行Rust代码。https://github.com/rust-lang/rust/pull/142696。

4. @KMJ-007的主要PR已发布，开始为Enzyme（我们的std::autodiff模块的后端）生成typetrees。Enzyme有时希望获得比从LLVM获得的更多关于类型的信息，所以它要么需要推断它（慢），要么将无法编译（坏）。将来我们希望将MIR信息降低到Enzyme，这是它的第一步。我刚刚提交了第一轮审查：https://github.com/rust-lang/rust/pull/142640

5. @Sa4dUs的主要PR已发布，它用适当的rustc-autodiff-intrinsic替换了我历史上增长的中端。这允许我们移除一些hack，从而更易于维护。它还将处理更多边缘情况，并减少rustc中与自动微分相关的代码约400行。我也给了它第一轮审查通过。

6. 我还提交了一个更新的项目目标来完成std::offload模块，到我们可以用纯（nightly）Rust编写大量有趣内核并将它们启动到GPU的程度。所有新项目目标都应该有来自它们相关团队的"冠军”，就我的自动微分/批处理/卸载工作而言，这将是t-compiler和t-lang（有关更多详细信息，请参阅Niko的博客文章）。由于我前一段时间加入了编译器团队，我现在可以在编译器端自己为它冠军，@traviscross自愿在语言端继续支持，谢谢！

提供1个详细更新。

@ZuseZ4于2025年7月30日评论：

这个项目目标周期的最后更新！我继续致力于gpu支持，而我们的两个Rust/LLVM自动微分gsoc学生在他们相应的项目中取得了巨大进展。

关键进展：

1. 我的内存移动PR经过审查，经过几次迭代后进入nightly。这意味着你现在甚至不需要构建自己的rustc来向GPU和从GPU移动数据（具有我先前帖子中提到的限制）。作为我PR的一部分，我还更新了rustc-dev-guide：https://rustc-dev-guide.rust-lang.org/offload/installation.html

2. 现在主机（CPU）代码已落地，我研究了将rust内核编译到GPU。当试验rustc的amdgcn目标时，我注意到一个回归，由于该回归，该目标的所有示例都失败了。我提交了一个小补丁来修复它。它在几天前落地，并阻止rustc在AMD GPU上生成f128类型：https://github.com/rust-lang/rust/pull/144383

3. 我研究了HIP和OpenMP（托管/内核模式）示例，以查看启动内核需要什么。我应该已经有大部分代码上游，因为它作为我主机PR的一部分落地，所以我认为我应该很快能够添加剩余的粘合代码来开始在GPU上运行Rust代码。https://github.com/rust-lang/rust/pull/142696。

4. @KMJ-007的主要PR已发布，开始为Enzyme（我们的std::autodiff模块的后端）生成typetrees。Enzyme有时希望获得比从LLVM获得的更多关于类型的信息，所以它要么需要推断它（慢），要么将无法编译（坏）。将来我们希望将MIR信息降低到Enzyme，这是它的第一步。我刚刚提交了第一轮审查：https://github.com/rust-lang/rust/pull/142640

5. @Sa4dUs的主要PR已发布，它用适当的rustc-autodiff-intrinsic替换了我历史上增长的中端。这允许我们移除一些hack，从而更易于维护。它还将处理更多边缘情况，并减少rustc中与自动微分相关的代码约400行。我也给了它第一轮审查通过。

6. 我还提交了一个更新的项目目标来完成std::offload模块，到我们可以用纯（nightly）Rust编写大量有趣内核并将它们启动到GPU的程度。所有新项目目标都应该有来自它们相关团队的"冠军"，就我的自动微分/批处理/卸载工作而言，这将是t-compiler和t-lang（有关更多详细信息，请参阅Niko的博客文章）。由于我前一段时间加入了编译器团队，我现在可以在编译器端自己为它冠军，@traviscross自愿在语言端继续支持，谢谢！

扩展pubgrub以匹配cargo的依赖解析

提供2个详细更新。

@Eh2406： 我在亚马逊的时间即将结束。他们支持了2024年下半年目标的非常成功的努力，并鼓励我提出现在正在收尾的2025年上半年目标。不幸的是，其他工作努力导致2025年上半年目标的进展非常有限。我不知道接下来会发生什么，但这肯定涉及花时间放松和恢复。恢复涉及重新发现我所热爱的工作中的乐趣。而且，我对这个问题有深厚的热情。我希望找时间研究这个。但是，放松需要减少我对他人做出的承诺和相关压力。所以我不会承诺进展，也不会为2025年下半年续订目标。

@Eh2406于2025年7月2日评论：

我在亚马逊的时间即将结束。他们支持了2024年下半年目标的非常成功的努力，并鼓励我提出现在正在收尾的2025年上半年目标。不幸的是，其他工作努力导致2025年上半年目标的进展非常有限。我不知道接下来会发生什么，但这肯定涉及花时间放松和恢复。恢复涉及重新发现我所热爱的工作中的乐趣。而且，我对这个问题有深厚的热情。我希望找时间研究这个。但是，放松需要减少我对他人做出的承诺和相关压力。所以我不会承诺进展，也不会为2025年下半年续订目标。

@tomassedovic于2025年7月25日评论：

感谢你所做的一切Jacob，祝你好运！ 随着2025年H1周期即将结束，我们专注于下半年的目标，我们将在本月（2025年7月）底前关闭这个问题。 如果你或其他人在研究这个并有更新要分享，请在2025年7月29日前将它们作为评论添加到这里，以便它们可以包含在最终博客文章中。 即使问题关闭后，这里的工作也可以被拾起 - 我们只是不再将其作为2025年H1目标努力的一部分进行跟踪。

外部可实施项目

完成libtest json输出实验

提供2个详细更新。

@epage于2025年7月10日评论：

关键进展： 阻碍因素

• 人员方面，注意力被toml v0.9和现在的cargo-script占据 需要帮助
• 帮助在原始harness之上编写最终用户API

@epage于2025年7月28日评论：

关键进展：

• https://github.com/assert-rs/libtest2/pull/94
• https://github.com/assert-rs/libtest2/pull/99
• https://github.com/assert-rs/libtest2/pull/100

实现Open API命名空间支持

提供1个详细更新。

@b-naber于2025年7月28日评论：

为@epage插话，因为进一步的进展仍然被编译器实现阻塞。不幸的是，事情进展比我最初希望的要慢。我们一直在进行一些重构（https://github.com/rust-lang/rust/pull/142547 和 https://github.com/rust-lang/rust/pull/144131），允许我们在名称解析中为命名空间crate引入一个新的Scope。有一个草案PR（https://github.com/rust-lang/rust/pull/140271）应该可以很容易地适应重构。

实现限制，准备稳定

提供1个详细更新。

@jhpratt于2025年8月5日评论：

实现仍在进行中；我很快将能够落地几个PR，使其大部分实现。进展比预期慢，因为我有很多事情要做。由于我仍然非常想要这个特性，即使目标正式失效，我也会继续研究它。 此外，我认为在完全实现后，可能可以利用impl限制的crate本地知识以enum_dispatch-like方式优化dyn。我还没有研究这在编译器中的可行性 - 这仅仅是一个怀疑。

改进状态机代码生成

使用安全合约检测Rust标准库

提供2个详细更新。

@celinval于2025年7月3日评论：

不幸的是，自4月以来我们没有取得太大进展，除了在Rust全体大会期间进行了一次非常有用的讨论。一些笔记可以在这里找到：https://hackmd.io/@qnR1-HVLRx-dekU5dvtvkw/SyUuR6SZgx。我们仍在等待与编译器团队的设计讨论会议。

@celinval于2025年7月25日评论：

@dawidl022作为GSoC的一部分正在工作，在@tautschnig的指导下改进合约实现。此外，@tautschnig和@carolynzech正在将合约从https://github.com/model-checking/verify-rust-std移植到Rust仓库。

使compiletest更可维护：重做指令处理

指标倡议

提供1个详细更新。

@yaahc于2025年7月11日评论：

除了先前的最终更新外，本月没有更新。我仍然打算发布json->influxdb转换代码

在a-mir-formality中建模一致性

下一代trait求解器

提供2个详细更新。

@lcnr于2025年7月14日评论：

我们 - 或者更确切地说，主要是@compiler-errors - 在过去一个月继续对新求解器进行性能改进：https://github.com/rust-lang/rust/pull/142802 https://github.com/rust-lang/rust/pull/142732 https://github.com/rust-lang/rust/pull/142317 https://github.com/rust-lang/rust/pull/142316 https://github.com/rust-lang/rust/pull/142223 https://github.com/rust-lang/rust/pull/142090 https://github.com/rust-lang/rust/pull/142088 https://github.com/rust-lang/rust/pull/142085 https://github.com/rust-lang/rust/pull/141927 https://github.com/rust-lang/rust/pull/141581 https://github.com/rust-lang/rust/pull/141451。nalgebra目前比旧求解器实现慢70%，在大多数普通crate中我们似乎慢约30-50%。

@lcnr于2025年7月29日评论：

自上次更新以来，@compiler-errors落地了两个额外的性能优化：https://github.com/rust-lang/rust/pull/143500 https://github.com/rust-lang/rust/pull/143309。

有了这个，我就可以落地实际的快速路径，修复rayon和由于大量where-bound导致的类似挂起。这也应该很快完成。然后我将回去实现新的不透明类型处理方法，因为那是我们呼吁测试之前唯一剩余的问题。

符合人机工程学的SIMD多版本化的Nightly支持

提供1个详细更新。

@veluca93于2025年7月10日评论：

关键进展： https://github