@tmandry 于 2025年2月26日发布的评论

Rust 1.85

第一个更新是 Rust 1.85 的发布，它包含了至少两个影响异步 Rust 的主要特性。第一个是异步闭包，这一特性长期以来一直是许多人的愿望清单上的项目，并在过去一年中由 @compiler-errors 娴熟地推进。

第二个特性是作为 Rust 2024 版本一部分的新生命周期捕获规则。这应该能显著改善用户在编写 -> impl Future 时使用异步 Rust 的体验，因为它在大多数情况下消除了对 + '_ 或类似边界的需求。它也将使语言更易于理解，因为这些边界之前是通过利用 impl Trait 更微妙的规则来实现的，这与它们在语言中的实际语义作用相反。在 2024 版本中，这个微妙的规则已被移除，我们默认捕获所有输入生命周期，并可以通过使用 + use<> 语法来选择退出。更多信息请参阅这篇博客文章。

生成器

语言团队召开了两次关于生成器的设计会议，最后一次会议的结果是，我们将在编译器中实现一个 std::iter::iter! 宏（确切路径待定），作为语言团队允许使用 yield 语法的实验。我们决定朝这个方向发展，是因为我们希望为自借用和可能的借出生成器保留 gen 关键字，并且尚未决定在该语法下暴露哪些特性子集。此决定与正在进行的编译器开发相互作用，而该开发尚未准备好支持借出实验。

我们希望与此同时，通过发布 iter!，我们将让人们有机会开始在自己的代码中使用生成器，并更好地理解人们在实践中会遇到哪些限制。

您可能已经注意到，我在这里没有讨论异步生成器。这是异步倡议的最终目标，但我们认为第一步应该是澄清同步生成器的状态，以便在讨论异步生成器时以此为基础。

dynosaur

dynosaur v0.1.3 已发布，下一个版本正在开发中。我们认为很快就会接近 1.0 版本 (tm)。此时，您应该可以在您的 crate 上尝试它，以便为带有 async fn 和其他 -> impl Trait 方法的 trait 启用 dyn dispatch。如果您需要将其与 #[trait_variant] 一起使用，可能需要等到 #55 修复后的下一个版本。

其他

异步项目目标已被 2025H1 接受！

@m-ou-se 于 2025年2月28日发布的评论

目前进展

• 分配了活动的预算。
• 资金已从 Rust 基金会转移至 RustNL。
• 预订了场地，包括午餐和点心。
• 将去年差旅资助计划的剩余预算添加到今年，以帮助支付差旅费用。
• 公告已发布：https://blog.rust-lang.net.cn/inside-rust/2024/09/02/all-hands.html
• 在多次向团队和个人发送提醒后，约有 110 名项目成员报名。（少数取消了。）
• 已向所有注册者发送正式邀请函。
• 全体会议信息：https://rustweek.org/all-hands/
• 酒店预订可用：https://rustweek.org/hotels-all-hands/
• 创建了公共和私有的 zulip 频道。
• 约 65 人确认已预订酒店。
• 开放了关于全体会议讨论主题的讨论。
• 受邀嘉宾：非项目成员的项目目标（任务）负责人（共12人）。目前已有4人报名。
• 为全体会议前一天准备了 150 份秘密礼物。

下一步

• 提醒大家如果想参加 RustWeek 大会（周二+周三），也需购买门票。
• 在决定邀请哪些人后，邀请更多嘉宾。（今天在理事会会议上讨论。）
• 确定是否也能为嘉宾提供差旅+酒店费用资助。（今天在理事会会议上讨论。）
• 整理全体会议的所有议题想法，以便之后将其转化为一致的时间表。
• 起草根据团队和议题分配房间的方案。
• 作为 RustWeek 大会的一部分，开放项目议程（周三）的演讲提案征集。

@nikomatsakis 于 2025年1月15日发布的评论

在今天的会议中，我们审查了2025H1 项目目标的计划...

先前“几乎完成”的事项

• 重新稳定 CoercePointee -- Alice 正在研究此问题，这是尝试讨论中的新模板的好机会
• 稳定任意自类型 v2 -- @adetaylor 3周前留下了评论，表明一切已大致合并。RFL 已在使用它，这提供了其运行良好的证据。接下来的步骤是整理文档并进行稳定化。
• asm-goto -- 已准备好稳定，尚未合并，仍在进行 Rust 参考文档的工作（PRs https://github.com/rust-lang/rust/pull/133870, https://github.com/rust-lang/reference/pull/1693）

ABI 修改标志

rust-lang/rfcs#3716 现在处于最终评论期 (FCP)。#133138 中有一个初步实现，@petrochenkov 将进行审查。合并后还需要一些额外的工作进行测试、清理等。

来自 RFL#2 的其他标志

我们查看了 RFL 使用的一系列标志，并调查了可能阻碍每个标志的问题。稳定其中一个标志的过程基本上是准备稳定化 PR（最少的工作，但我们需要将标志从 -Z 重命名为 -C），附带稳定化报告和适当的文档，然后抄送 @davidtwco 或 @wesleywiser 来准备稳定化。在大多数情况下，我们需要记录这些标志如何被滥用，最常见的情况是链接到使用不同标志构建的 std 或其他 crate。如果因此产生重大的正确性问题，我们很可能需要将该标志视为“ABI 修改”标志。

• 提取依赖信息的能力，目前使用 -Zbinary_dep_depinfo=y -- 基本上已准备好稳定 * tmandry: 您是否希望在您的依赖信息中包含工具链运行时 (libstd, compiler-rt) 吗？根据我的经验，此功能可以完成我想要做的 90% 的工作，但在稳定之前唯一的问题是是否移除运行时的包含。
• -Zcrate-attr，用于在不要求源代码文件包含 no-std 的情况下配置 no-std -- 没有实际担忧
• -Zunpretty=expanded -- 必须明确记录输出是不稳定的，就像我们记录 MIR 输出一样。这实际上已经“事实”稳定，因为在实践中 cargo expand 使用 RUSTC_BOOTSTRAP=1，并且每个人都在使用它。
• -Zno-jump-tables -- 这应该被视为 ABI 修改标志，因为我们认为 CFI 需要它，因此如果链接不兼容的模块会存在风险。
• -Zdwarf-version, -Zdebuginfo-compression -- 这应该已准备好稳定，只要我们记录了当混合使用不同版本（特别是 libstd，它使用 DWARF4）编译的内容时，应预料到会出现 debuginfo 等的混合。调试器已经为这种情况做好了准备。zstd 压缩自 Rust 1.82.0 起已支持。

稳定的 rustdoc 特性允许 RFL 项目提取和自定义 rustdoc 测试 (--extract-doctests)

@imperio 编写了 https://github.com/rust-lang/rust/pull/134531，目前正在审查中。一旦 PR 合并，RFL 将验证设计，然后可以进行稳定化。

Clippy 配置（可能包括 .clippy.toml 和 CLIPPY_CONF_DIR）

我们与 Clippy 团队进行了讨论，这似乎不是什么大问题，主要是一个文档修改，一个顾虑是 Clippy 是否应该接受它不认识的选项（因为它们可能来自未来版本的 Clippy）。目前来看不是什么大问题，RFL 只使用了 (msrv, check-private-items=true, disallowed-macros)。

重建 libcore

ARM 团队正在作为此项目目标的一部分开展这项工作，期待更新。🎉

@nikomatsakis 于 2025年1月30日发布的评论

更新

2024H2 清理

• 任意自类型 v2：稳定化 PR 已开放 (rust-lang/rust#135881)。
• 稳定 CoercePointee：RFL 现在正在使用它；我们正在努力完成稳定化。

2025H1

• ABI 修改标志 RFC (rust-lang/rfcs#3716) 已完成 FCP 并需要合并。由 @azhogin 编写的实现 PR #133138 仍在审查中。
• 其他编译器标志，我们制定了优先列表。一个简单的下一步是将此列表中的所有 -Z 标志重命名为可稳定化的名称（例如 -C），这将需要 -Zunstable-features。
  • -Zdwarf-version -- wesley wiser
  • -Zdebuginfo-compression，已解除阻塞
  • -Zcrate-attr，用于在不要求源代码文件包含 no-std 的情况下配置 no-std，没有实际担忧
  • -Zunpretty=expanded，已解除阻塞，可能需要一个 PR 说明“不要依赖此”，Linux 仅用于调试宏（即不在正常构建中，因此不那么关键）。需要一个稳定的名称，例如 --emit macro-expanded，并且我们应该确保输出不能通过管道传输到 rustc。rustfmt 告诉我们 (Rust for Linux)，他们将尽最大努力使 rustfmt 能够格式化展开的输出。
  • -Zno-jump-tables，被视为 ABI 修改标志
  • -Zbinary_dep_depinfo=y -- 基本上已准备好稳定（@tmandry 问：“您希望在您的依赖信息中包含工具链运行时 (libstd, compiler-rt) 吗？根据我的经验，此功能完成了我想要做的 90% 的工作，但在稳定之前唯一的问题是是否移除运行时的包含”，但我们尚未理解此点，因为他们没有出席会议）。
• 稳定的 rustdoc：PR rust-lang/rust#134531 正在审查中，应该很快合并，然后下一步将是 RFL 的人们进行试用。
• Clippy 配置：没有进展，讨论了一些新选项并在帖子中发布，此处所需工作量极小。
• 重建 libcore：@davidtwco 未出席，因此没有更新，但我们知道正在取得进展

宣传这项工作

我们简要讨论了如何更好地宣传这项合作。几点如下：

• @Darksonn 将在 Rust Nation 发表演讲
• 我们可以撰写一篇 Rust-lang 博客文章，也许等语言项全部完成后？
• LWN 文章可能是一个选项

general-regs-only

我们讨论了引入一个标志以避免使用浮点寄存器的可能性，尚未达成明确结论。

@nikomatsakis 于 2025年2月20日发布的评论

来自我们2025年2月12日会议的更新

鉴于最近关于 Rust 在内核中使用的争议，RFL 小组撰写了一份政策说明文档来解释该政策，并且 LWN 上也有一篇文章。

关于任意自类型和 coerce pointee，我们正在等待 rust-lang/rust#136764 和 rust-lang/rust#136776。前者正在语言团队 FCP 中。后者已获得语言团队批准，并等待 @BoxyUwU 进行进一步的实现工作。

@ojeda 正在研究如何管理依赖信息和从外部配置 no-std。

@GuillaumeGomez 实现的 rustdoc 特性已经合并，我们正在等待 RFL 进行实验。

@davidtwco 在 ARM 的团队撰写了一份关于构建 std 的推荐方式的文档，并正在收集反馈。

@wesleywiser 正在准备一个 PR，以添加 -Zdwarf-version 来推进编译器标志的工作。

存在一个与 cfg(no_global_oom_handling) 相关的令人困扰的问题，RFL 不再使用它，但它仍然存在于较旧的内核分支 (6.12, LTS) 中。

作为一组在类似 mono-repo 的方式中共同演进的“叶子 crate”，RFL 希望有一个禁用孤儿规则的解决方案。

@epage 于 2025年2月20日发布的评论

寻求帮助：此项目目标需要一名编译器开发者来推进。

@epage 于 2025年2月20日发布的评论

寻求帮助：此项目目标需要有人进行实现工作

@ashiskumarnaik 于 2025年2月23日发布的评论

Hi @epage 我非常感兴趣参与这项实现工作。我们在 Zulip 上聊吧，请查看私信。

@celinval 于 2025年2月25日发布的评论

暂无进展。

寻求帮助：正在寻找愿意帮忙进行一些重构工作的人。请通过 project-stable-mir Zulip 频道或仓库联系。

@epage 于 2025年2月20日发布的评论

寻求帮助：此项目目标需要一名编译器开发者来推进。

@BoxyUwU 于 2025年2月27日发布的评论

camelid 提交了一个 PR，该 PR 已基本完成并经过审查，它可以解析和降低 min_generic_const_args 下的所有路径。完成这项工作花了一些时间，因为我们必须注意避免通过复制类型和 const 路径降低的所有逻辑，导致编译器的部分代码难以维护。

@davidtwco 于 2025年2月19日发布的评论

关于我们一直在做什么以及一些背景的初步更新

• 此目标代表 Arm 的 Rust 团队提交，但主要由 @AdamGemmell 负责。任何感兴趣的人都可以随时联系我获取更新，我将保持此议题的最新状态。
• 我们的团队一直试图通过完成 rust-lang/wg-cargo-std-aware 中的议题来推进 build-std 的进展，但发现效果不佳，因为大多数议题没有明确的范围或期望的结果，并且相关团队缺乏评估任何提案所需的背景信息。
• 此后，我们与 Cargo 团队进行了讨论，并同意起草一份文档，描述 build-std 的用例、动机和现有工作，以便 Cargo 团队能够自信地审查任何进一步的提案。
  • @AdamGemmell 在 Zulip 的 #t-cargo 中分享了这份文档的初步草稿，目前正在根据反馈进行进一步修改。
  • 在对该特性的背景达成共识后，@AdamGemmell 将起草一份完整的 build-std 提案，该提案有望被稳定化。它将描述在 build-std 范围内的和不在范围内的用例，以及将在初步实现中包含哪些特性。
• @davidtwco 正在确保最终提出的使 build-std 在稳定工具链上工作的机制也适合 Rust for Linux 项目在自行构建核心库时使用。

@obi1kenobi 于 2025年2月19日发布的评论

谢谢，Niko！复制 2025h1 周期的新任务：

• 使用变通方法原型设计跨 crate linting (@obi1kenobi)
• 允许 lint 泛型类型、生命周期、边界 (@obi1kenobi)
• 处理 'static 和 ?Sized 等“特殊情况” (@obi1kenobi)
• 在 sealed trait 分析中处理 #[doc(hidden)] (@obi1kenobi)
• 讨论和精神支持 (cargo, [rustdoc])

@tmandry 于 2025年2月26日发布的评论

今天我们召开了一次语言团队设计会议，讨论 C++ 互操作。结果非常积极，大家对支持 C++ 互操作的宏大愿景充满热情：即绝大多数实际 C++ 代码都可以自动绑定到 Rust，反之亦然。

同时，团队表达了以符合 Rust 价值观的方式实现这一目标的愿望。特别是，我们不会让 Rust 成为 Rust+C++ 的超集，而是会定义扩展点，这些扩展点可用于表达超出 Rust 本身所允许的语言互操作边界。例如，我们可以通过 Rust“插件”允许模板实例化，而无需在 Rust 本身中添加模板。类似地，我们可以在不向 Rust 本身添加函数重载的情况下调用重载的 C++ 方法。其他互操作需求更自然地可以通过 Rust 语言中的特性来实现，例如自定义引用类型。

无论如何，我们为支持互操作所做的任何工作都需要根据其自身的价值来考量。互操作是支持某个特性的一个原因，但绝不是添加我们可能认为有用的任何东西的“空白支票”。

到目前为止的讨论是高层次的。下一步将是：

• 讨论作为即将到来的项目目标的一部分，我们可以追求哪些重要但现实的里程碑，以及如何实现它们。无论这是否是另一个语言团队会议的一部分，还是为感兴趣方召开的更专门的启动会议，我都会确保及时向语言团队通报情况，并继续在这里发布更新。
• 在与语言、库和编译器团队的会议中，深入探讨我们希望启用的用例的更具体提案。

笔记：https://hackmd.io/2Ar_7CNoRkeXk1AARyOL7A?view

@spastorino 于 2025年2月26日发布的评论

提交了一个 PR https://github.com/rust-lang/rust/pull/134797，该 PR 实现了提议的 RFC，但没有包含优化。该 PR 尚未合并，我们现在需要继续处理 PR 的评论，直到合并为止，然后开始实现优化。

@ZuseZ4 于 2025年1月3日发布的评论

新年快乐各位！经过几轮反馈，下一个 autodiff PR 最近已合并：https://github.com/rust-lang/rust/pull/130060 至此，我只剩下最后一个开放的 PR，就可以在上游拥有一个完全工作的 autodiff MVP。上游合并过程中移除了一些特性以简化审查流程，但它们应该更容易作为单独的 PR 重新添加回来。

从下周开始，我还将着手 LLVM/Enzyme 的 batching 特性的 MVP，它能实现一些 AoS 和 SoA 向量化。它主要重用了现有的 autodiff 基础设施，所以我预计相关的 PR 会小得多。

在 GPU 方面，最近另一位开发者推动向 Rust 编译器添加新的 AMD GPU 目标。这正是我在 llvm offload 项目中无论如何都需要的东西，所以我很高兴看到这方面的进展：https://github.com/rust-lang/compiler-team/issues/823

@Eh2406 于 2025年2月26日发布的评论

迄今为止的主要更新是发布了PubGrub 0.3。这使得为满足 Cargo 和 UV 所需的功能和性能而进行的关键改进得以可用。其他生产用户现在可以利用过去几年来的改进。非常感谢 @konstin 促成了此次发布。

其他进展受到了阻碍，因为一月份患了新冠，导致持续一周的脑雾，随后是几个高优先级的日常工作项目。目前尚不清楚何时工作需求会允许我重新专注于这个项目。

@m-ou-se 于 2025年2月28日发布的评论

现在 https://github.com/rust-lang/rust/pull/135726 已合并，@jdonszelmann 和我将着手实现 EII。

我们已经在白板上设计好了实现方案。目前我们不预期有任何重大的阻塞。下周开始编写代码后，我们会知道更多。

@epage 于 2025年2月20日发布的评论

这项工作暂停，直到 #92 的实现完成。#92 的 rustc 部分正在审查中，之后还需要一些 r-a 和 cargo 的额外工作才能完成实现，然后才能进行测试和稳定化。

@jhpratt 于 2025年2月26日发布的评论

首次状态更新

暂无进展。本周末我将审查现有 PR，看看是重新基线可行，还是手动重新应用补丁更可行。我怀疑后者可能更可取。

@traviscross 于 2025年2月26日发布的评论

我认为，这主要是等待我们语言团队审查，可能是在一次设计会议上，来摸清我们能够接受的可能性范围。

@celinval 于 2025年1月3日发布的评论

关键进展：我们在 verify-rust-std 分支中编写并验证了大约 220 个安全契约。14 个挑战中有 3 个已解决。我们已成功将 Kani 集成到仓库 CI 中，并且正在努力集成另外 2 个验证工具：VeriFast 和 Goto-transcoder (ESBMC)。

@jieyouxu 于 2025年2月19日发布的评论

更新 (2025-02-19)

• 为了更容易跟踪 bootstrap 进入运行 compiletest 管理的测试套件的测试流程，我在 https://github.com/rust-lang/rust/pull/137080 中为 bootstrap 添加了更多跟踪。
• 我正在首先进行一些前提性的清理/改进工作，以使参考 bootstrap + compiletest 的代码库更容易阅读：https://github.com/rust-lang/rust/pull/137224, https://github.com/rust-lang/rust/pull/136474, https://github.com/rust-lang/rust/pull/136542
• 我正在考虑原型，我将尝试从 rust-lang/rust 创建一个分支进行实验，而不是完全独立进行，这样我就可以在 bootstrap 和我们实际拥有的测试的上下文中进行实验，而不是在完全隔离的环境中尝试（特别是在 staging 和依赖许可证方面）。
  • Onur 正在处理稳定 rustc 工具的阶段管理 #137215，我将等待此 PR 合并，以匹配 compiletest 使用的 ToolStd 行为。

@jieyouxu 于 2025年2月27日发布的评论

更新 (2025-02-27)

• 清理工作仍在等待合并（一些 PR 被其他人的更改所阻塞，导致进展缓慢）。

@yaahc 于 2025年2月25日发布的评论

我非常高兴看到这个被接受为项目目标 🥰 🎉

让我先给出我目前进展的初步状态更新。

• 我们已经完成了配置指标存储目录的初步实现，该目录也作为一组默认指标的启用标志，目前包括 ICE 报告和不稳定特性使用指标。
• 实现了基本的不稳定特性使用指标，目前会为每个编译的 crate 转储一个 json 文件，显示启用了哪些指标。（示例见下文）
• 实现了 rust-lang/rust/src/tools/features-status-dump，它将所有不稳定、稳定和已移除特性的状态信息转储为 json 文件。
• 在我的笔记本电脑上使用 InfluxDB 3.0 Alpha 和 Graphana 设置了一个极其简单的初步概念验证实现（图片见下文）。
  • 我写了一个小程序，可以将 json 文件转换为influxdb 的行协议，用于使用信息和状态信息（片段如下所示）。
    • 时间戳是编造的，因为它们都需要是唯一的，否则 influxdb 会将它们视为对同一行的更新。我希望保留指标最初转储时的时间信息，无论是保存在 json 中，还是通过修改 rustc 直接以 influxdb 的行格式或其他等效协议进行转储。（请注意，这可能只对使用指标是必要的，但对于状态指标，我必须更改下面示例中的行格式 schema 以避免同样的问题，这与 influxdb 如何处理标签和字段有关。）
  • 我通过使用 RUSTFLAGS_NOT_BOOTSTRAP="-Zmetrics-dir=$HOME/tmp/metrics" ./x build --stage 2 编译 rustc 并运行 ./x run src/tools/features-status-dump/ 来收集了一个最小数据集，将输出保存到文件系统，然后使用上述程序将输出转换为行协议。
  • 将生成的两个文件写入 influxdb
  • 然后我用两种不同的方式设置了表，一种是直接使用 influxdb 的 cli 查询数据库（查询如下所示），另一种是尝试在 graphana 中设置一个等效查询（这里肯定有一些需要解决的难题，我绝不是 graphana 专家）。

来自 unstable_feature_usage_metrics-rustc_hir-3bc1eef297abaa83.json

{"lib_features":[{"symbol":"variant_count"}],"lang_features":[{"symbol":"associated_type_defaults","since":null},{"symbol":"closure_track_caller","since":null},{"symbol":"let_chains","since":null},{"symbol":"never_type","since":null},{"symbol":"rustc_attrs","since":null}]}

不稳定特性使用指标转换为行协议后的片段

featureUsage,crateID="bc8fb5c22ba7eba3" feature="let_chains" 1739997597429030911
featureUsage,crateID="439ccecea0122a52" feature="assert_matches" 1739997597429867374
featureUsage,crateID="439ccecea0122a52" feature="extract_if" 1739997597429870052
featureUsage,crateID="439ccecea0122a52" feature="iter_intersperse" 1739997597429870855
featureUsage,crateID="439ccecea0122a52" feature="box_patterns" 1739997597429871639

特性状态指标转换为行协议后的片段

featureStatus,kind=lang status="unstable",since="1.5.0",has_gate_test=false,file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/unstable.rs",line=228,name="omit_gdb_pretty_printer_section" 1739478396884006508
featureStatus,kind=lang status="accepted",since="1.83.0",has_gate_test=false,tracking_issue="123742",file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/accepted.rs",line=197,name="expr_fragment_specifier_2024" 1739478396884040564
featureStatus,kind=lang status="accepted",since="1.0.0",has_gate_test=false,file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/accepted.rs",line=72,name="associated_types" 1739478396884042777
featureStatus,kind=lang status="unstable",since="1.79.0",has_gate_test=false,tracking_issue="123646",file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/unstable.rs",line=232,name="pattern_types" 1739478396884043914
featureStatus,kind=lang status="accepted",since="1.27.0",has_gate_test=false,tracking_issue="48848",file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/accepted.rs",line=223,name="generic_param_attrs" 1739478396884045054
featureStatus,kind=lang status="removed",since="1.81.0",has_gate_test=false,tracking_issue="83788",file="/home/jlusby/git/rust-lang/rust/compiler/rustc_feature/src/removed.rs",line=245,name="wasm_abi" 1739478396884046179

使用 influxdb3 query --database=unstable-feature-metrics --file query.sql 运行

SELECT
  COUNT(*) TotalCount, "featureStatus".name
FROM
  "featureStatus"
INNER JOIN "featureUsage" ON
  "featureUsage".feature = "featureStatus".name
GROUP BY
  "featureStatus".name
ORDER BY
    TotalCount DESC

@yaahc 于 2025年2月25日发布的评论

我的下一步是重新审视输出格式，目前是编译器内部数据表示形式的直接 json 序列化。根据个人经验，这已经被证明是不够的，因为需要额外的临时转换到另一种包含伪造时间戳数据的格式（原始转储中没有），并且与 @badboy (Jan-Erik) 的谈话中，他建议我们明确避免对遥测 schema 进行临时定义，这可能导致难以管理的混乱。

我目前正在评估有哪些可用的选项，例如围绕 influxdb 行格式构建的自定义系统，或 opentelemetry 的 metrics API。

无论如何，我想在评估输出格式选项时，将 firefox 的遥测系统作为灵感/需求基础。

我与 Jan-Erik 对话的相关笔记

• firefox 遥测始于一个问题：我们收集这些数据是为了回答什么？添加新遥测的人必须明确注明，并且围绕添加新遥测有一整套流程。
  • 定义指标
  • 描述
  • 所有者
  • 期限限制（自动过期，需要手动延长）
  • 数据管理员
    • 进行数据审查
    • 检查遥测是否合理
    • 检查是否符合所有标准
  • 添加指标可能增加开销的缺点
  • 有助于工具链，我们可以将所有这些信息展示为文档
  • schema 从定义生成

@nikomatsakis 于 2025年2月26日发布的评论

我已经设立了一些固定的“办公时间”时段，在此期间我在 jitsi 上可用。我们合并了一些小的 PR，改进了解析器，oli-obk 和 tif 一直在为 const 泛型工作建模效果。既然基本的合并工作已经完成，我计划开始更深入地研究一致性的建模。

@lcnr 于 2025年2月27日发布的评论

我们已在 1.84 版本中稳定了 -Znext-solver=coherence，并开始在一个项目看板中跟踪剩余问题。

修复导致 wg-grammar 中断的不透明类型问题很困难，需要更深入的更改，为此现在已有一个已接受的 Types MCP。这可能也会解除使用旧解析器进行 TAIT 稳定化的阻塞。

在等待 MCP 期间，我已开始研究编译 nalgebra 时出现的错误。@lqd 最大限度地减少了失败。这些失败是由于我们周期处理不足引起的。通过 https://github.com/rust-lang/rust/pull/136824 和 https://github.com/rust-lang/rust/pull/137314，周期现在应该完全支持了。

我们还与 @compiler-errors、@BoxyUwU 和我一起完全分类了启用新解析器的所有 UI 测试，并修复了多个不太复杂的问题。

@veluca93 于 2025年2月25日发布的评论

关键进展：进一步讨论了三种主要提议的前进方向的实现细节。在 https://github.com/rust-lang/lang-team/issues/309 中请求了一次设计会议。

@1c3t3a 于 2025年2月19日发布的评论

状态更新：null 检查已合并到 rust#134424 中。接下来是枚举判别式检查。

@blyxyas 于 2025年2月26日发布的评论

每月更新（之前发布在 Zulip 上）：我们取得了一些重大进展！

• rust-clippy#13821 议题已开放，目前正在审查中。它将 MSRV 逻辑从单独的 lint 属性提取中移出，并放入 Clippy 全局 MSRV 中（进行了一个非常好的优化，考虑了只有很小比例的 crate 使用该特性）。

• 一个 Clippy 专属的基准测试工具已出现，由现有的 lintcheck 基础设施和 perf 提供支持。因此它与 flamegraph 等工具兼容。rust-clippy#14194 稍后我们可以将其扩展到 CI 或专用机器人。

• 您可能知道，rust#125116 已经合并，这只是提醒一下那个大目标是如何像屠龙一样被解决的 :dragon:。

我们现在知道要优化哪些函数（或者至少对 Clippy 花费时间的地方有了基本了解）。作为未来的一些功能，我希望能够构建带有调试符号的 cargo 和 rust，并将其连接到 Clippy，但这可能更困难。它并不完美，但这是一个好的开始！

@JoelMarcey 于 2025年2月24日发布的评论

上周在伦敦举行的 Safety Critical Rust Consortium 会议上，Ferrous Systems 公开向联盟成员宣布，他们已承诺将 FLS 贡献给 Rust 项目。我们正在敲定该过程的细节，但可以同时预先进行 FLS 集成测试。

@m-ou-se 于 2025年2月28日发布的评论

我们与代尔夫特理工大学开始了合作。我们组建了一个由一名教授和一名硕士生组成的小型研究团队，他将作为其硕士论文的一部分开展这项工作。我们每周进行面对面会面。

该项目于两周前启动，目前正处于文献研究阶段。

@m-ou-se 于 2025年2月28日发布的评论

与此相关，另有人正在实现我的 #[export] rfc：https://github.com/rust-lang/rust/pull/134767 这有望为研究项目提供有意义的输入。

@nikomatsakis 于 2025年2月19日发布的评论

更新：我们落后于计划，但无论如何已经开始运行了！请大家耐心等待。目标 RFC (https://github.com/rust-lang/rfcs/pull/3764) 于 2 月 18 日结束了FCP。新的项目目标团队已获得批准，我们已更新了新里程碑的跟踪议题。

鼓励项目目标负责人通过 GitHub 复选框或其他符号更新议题正文，以反映实际任务进展，如此处所述。我们很快就会开始催促首次状态更新！

@nikomatsakis 于 2025年2月19日发布的评论

迄今为止的更新：我在 Zulip (hackmd) 上发出了志愿者召集令，许多人响应。我们在 1 月 30 日召开了第一次会议（会议记录在此）。我们为这个项目目标创建了一个 Zulip 流 (vision-doc-2025)，并且我在 https://github.com/nikomatsakis/farsight 仓库中进行了一些实验，以了解目录结构可能是什么样子。

下一个里程碑是制定计划。我们有点落后于计划，但并非无法实现！

@davidtwco 于 2025年2月19日发布的评论

关于我们一直在做什么以及一些背景的初步更新

• 此目标代表 Arm 的 Rust 团队提交，但主要由 @Jamesbarford 负责。任何感兴趣的人都可以随时联系我获取更新，我将保持此议题的最新状态。
• 我们已安排与 @Kobzol 定期通话，讨论对 rust-perf 进行任何更改的约束和要求（参见t-infra 日历），并起草了一份文档，描述了我们更改后该服务的高层架构提案。
  • 这已在#project-goals/2025h1/rustc-perf-improvements Zulip 频道中分享，以收集反馈。
  • 一旦我们就高层架构达成一致，我们将在进行实现之前准备一份更详细的计划，其中包括数据库 schema 变更等细节。

@lqd 于 2025年1月31日发布的评论

本月关键进展

• @amandasystems 继续致力于这项如西西弗斯般艰巨的任务 https://github.com/rust-lang/rust/pull/130227，并在重写类型测试、诊断问题、修复 bug、跟上主分支变化等方面取得了进展。
• 非常感谢 @jackh726 和 @matthewjasper 的审查：在他们的帮助下，上次更新的所有 PR 都已合并到 nightly。
• 我提交了几个关于分析本身的 PR (https://github.com/rust-lang/rust/pull/135290, https://github.com/rust-lang/rust/pull/136299) 以及一些清理工作。有了这些，现在只有大约 4 个失败的测试仍然需要调查，以及 8-10 个诊断差异需要解决。这是我目前的重点，但我们也需要扩大测试覆盖率。
• 我还在提交了一些 PR，逐步扩展 polonius MIR dump 的可视化功能。接下来我将添加我一直用来帮助调试测试失败的交互式“工具”。
• 关于组织和协作
  • 我们与 Amanda 的一位学生进行了会面，讨论了关于 polonius 更偏工程方面（性能 <3）的硕士论文的可能性。
  • 并与 @ralfjung 的团队讨论了在 a-mir-formality 中建模借用检查的相关议题。

@davidtwco 于 2025年2月19日发布的评论

关于我们一直在做什么以及一些背景的初步更新

• 此目标代表 Arm 的 Rust 团队提交，但主要由我和 (@davidtwco) 以及 @JamieCunliffe 负责。任何感兴趣的人都可以随时联系我获取更新，我将保持此议题的最新状态。
• @JamieCunliffe 多年来一直致力于支持 Arm 的可伸缩向量扩展 (SVE)，主要是在 rust-lang/rfcs#3268 及其实现 rust-lang/rust#118917 中。
  • 通过这项工作，我们发现了支持这些类型而无需在类型系统中特殊处理所需的其他语言更改，我们也在进行这方面的工作（见下文）。
  • Jamie 仍在处理此 RFC 及其实现的反馈，并保持其重新基准。我们希望现在有了可行的途径来移除类型系统中的特殊情况（见下文），可以实验性地将其合并。
  • 此 RFC 和实现的下一步骤是...。
    • ...继续回应关于 RFC 和实现的反馈。
• 我 (@davidtwco) 一直在研究 rust-lang/rfcs#3729，该 RFC 改进了 Rust 对异常大小类型的支持，并允许在类型系统中表示可伸缩向量而无需特殊情况。
  • 我们与语言团队就该 RFC 召开了两次设计会议，并得到了广泛的积极反馈。
    • 对 const traits (rust-lang/rfcs#3762) 存在非严格依赖，这使得在没有明确 const traits 具体细节的情况下，该 RFC 是否能被接受存在不确定性。
  • 我一直在努力实现该 RFC：非 const traits 的初步实现已经完成，const traits 的添加正在进行中。
    • 语言团队表示有兴趣看到这项工作进行实验性合并，但这取决于 const traits 的实现者是否同意，因为这会增加他们在 rust-lang/rfcs#3762 中实现语言团队请求的任何语法更改所需的工作量。
  • 我将继续回应关于 RFC 的反馈，但由于反馈已基本减少，此 RFC 的下一步骤是：..
    • ...语言团队决定接受、拒绝或要求对 RFC 进行进一步更改。
    • ...实现工作继续推进。

@jswrenn 于 2025年2月26日发布的评论

关键进展：在2月19日的语言团队设计会议中，我们达成共识，unsafe 字段的 MVP 应限制于可加不变量。