@m-ou-se 于 2025 年 4 月 1 日发布的评论

• 在决定邀请谁之后，邀请更多嘉宾。（今日理事会会议上讨论。）
• 确定我们是否也能资助嘉宾的差旅和酒店费用。（今日理事会会议上讨论。）

我已向所有参会者征集邀请嘉宾的建议。据此，我迄今已邀请了大约 20 位嘉宾。其中只有两位需要差旅费用资助，我们可以从同一差旅预算中支付。

@nikomatsakis 于 2025 年 3 月 13 日发布的评论

来自我们 2025 年 3 月 12 日会议的更新（完整会议记录）

• RFL 团队请求有人查看内核所需的 #138368，由 @davidtwco 负责。
• -Zbinary-dep-info 可能不需要；RFL 也许可以模拟它。
• 用于导出 doctest 的 rustdoc 更改正在整合中。@GuillaumeGomez 也在研究该功能的内核端。@ojeda 认为，最好以一种不会将两个项目过度耦合的方式进行，这样 rustdoc 以后在更改输出时会有更大的灵活性。
• 为 clippy 稳定化编写了 Pre-RFC。
• build-std 设计正在积极迭代；cargo 团队正在提供反馈。
• @wesleywiser 发送了一个 PR 来稳定 -Zdwarf-version。
• RfL 不再使用 cfg(no_global_oom_handling)。很快，支持多个 Rust 版本的稳定/LTS 内核也将不再使用它。因此，上游 Rust 理论上可以移除该 cfg 而不影响 Linux，尽管其他用户如 Windows 可能仍在 P使用它（#t-libs>no_global_oom_handling removal）。
• 关于禁用 orphan 规则以允许实验的最佳前进方法的讨论，尚未有确定结论。

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

来自今日会议的更新

最终确定 2024 年下半年目标

• asm-goto 现已稳定！将在 1.87 版本中发布。
• asm-const 有一个初步实现，需要 gcc 支持。
• 虽然未在 RFL 中使用，naked_asm 不在此列表中，但将推进稳定。它与 global_asm 存在相同的 LLVM bug，即忘记目标特性标志。

ABI 修改编译器标志

• Andrew Zhogin 在 Alice 关于哪些 sanitiser 应该成为修饰符的议题之后，开启了一个草稿 PR (https://github.com/rust-lang/rust/pull/138736) (https://github.com/rust-lang/rust/issues/138453)。

提取依赖信息，外部配置 no-std (-Zcrate-attr)

• 我们决定不需要能够提取依赖信息
• jyn 为 -Zcrate-attr 提交了一个 RFC：https://github.com/rust-lang/rfcs/pull/3791

Rustdoc 提取 doc test 的特性

• 无更新。

Clippy 配置

• Pre-RFC 已发布，但据我们所知没有进展。最好与 @flip1995 同步后续步骤。

Build-std

• 无更新。负责该工作的贡献者度假回来后，进展将在下周恢复。

-Zsanitize-kcfi-arity

• 已将其添加为一个新的可交付成果。此类“新兴 codegen 标志”请求会不时出现。笔记可在此处和此处查看。
• 该 PR 已被审阅，不再阻止合并。

@SparrowLii 于 2025 年 3 月 18 日发布的评论

• 关键进展： 长期存在（超过一年）的几个死锁问题已通过 #137731 解决。并行前端的新测试套件正在改进中。
• 阻碍： 无
• 寻求帮助： 协助测试 议题列表中的死锁代码，并尝试重现问题

@epage 于 2025 年 3 月 17 日发布的评论

• 关键进展：@tgross35 促使 rust-lang/rust#135501 合并，这改进并推进了 rust-lang/rust#119428，它是两个主要阻碍之一。在 rust-lang/rust#119428 中，我们进一步讨论了更多设计和权衡。
• 阻碍：需进一步处理 rust-lang/rust#119428 和 rust-lang/rust#71043
• 寻求帮助：需要 T-compiler 团队成员处理上述议题。

@BoxyUwU 于 2025 年 3 月 17 日发布的评论

camelids PR 已合并，我们现在（据我所知）在 mgca 下正确地降低了 const 路径。我有一个 PR 正在进行中，以确保我们正确处理带有泛型或推断变量的 const 路径评估，并且在常量被检查为良好形式之前不尝试评估它们。我目前还在指导一个人实现在 mgca 下对固有关联常量进行标准化的适当处理。

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

一个小的更新，@adamgemmell 分享了上述文档的修订版，目前正在处理进一步的反馈意见。

@obi1kenobi 于 2025 年 3 月 8 日发布的评论

关键进展

• Sealed trait 分析正确处理了 #[doc(hidden)] 项。这完成了该目标的一个清单项！
• 我们发布了一系列检测泛型类型、生命周期和 const generics 中破坏性变更的 lint。其中一个 lint 已经在实际应用中捕获到了意外的破坏！

cargo-semver-checks v0.40 于今日发布，包含对 sealed trait 分析的各种改进。可以概括为“更智能、更快、更正确”，并将对 diesel 和 zerocopy 等流行 crate 产生直接的积极影响。

虽然我们已经发布了一系列检测泛型相关破坏性变更的 lint，但还需要更多工作来完成该清单项。这一点，以及“像 'static 和 ?Sized 这样的特殊情况”，将是接下来工作的重点。

@tmandry 于 2025 年 3 月 25 日发布的评论

自上次更新以来，有人提议在 Rust 全员大会上专门安排一些时间进行互操作性讨论；@baumanj 和 @tmandry 将着手充实议程。@cramertj 和 @tmandry 与 @oli-obk（他提供了很大帮助）集思广益，讨论了如何支持更具雄心的“从 Rust 进行模板实例化”目标，这可能会在某个时候变成一个原型。

@nikomatsakis 于 2025 年 3 月 17 日发布的评论

更新：rust-lang/rust#134797 已合并。

PR 中实现的语义

• 引入了一个 trait UseCloned，为 Rc 和 Arc 类型实现。
• x.use 检查 x 的类型 X 是否实现了 UseCloned trait；如果实现了，则 x.use 等同于 x.clone()，否则它是对 x 的复制/移动；
• use || ...x... 闭包的行为类似于 move 闭包，但尊重 UseCloned trait，因此它们会根据情况对 x 进行 clone、复制或移动。

后续步骤

• 修改 codegen，以确保如果在单态化（monomorphization）后 X: Copy 为真，x.use 将执行复制。目前，解糖为 clone 发生在单态化之前，因此即使对于 X 是 Copy 类型的情况，它也会调用 clone 方法。
• 如果这是最后一次使用，将 x.use 转换为移动而不是克隆。
• 使 x 等同于 x.use，但带有（默认允许的）lint 来指示发生了特殊情况。

值得注意的决定和讨论

• 选择将控制 x.use 是执行克隆还是移动的 trait 命名为 UseCloned，而不是 Use。这是因为该 trait 不控制你是否可以使用某个东西，而是控制你使用时会发生什么。
• 在 Zulip 上有人提出问题，询问 x.use 是否应该自动解引用。经过思考，得出结论不应该，因为 x 和 x.use 最终的行为应该与 lint 相同（忽略 lint 的影响），但出于易用性考虑，一个 &T -> T 的强制转换（coercion）仍然会很有用。

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

我刚刚注意到我错过了二月份的更新，所以这次更新我会稍微概括一些，以免过长。

关键进展

1. 所有关键的 autodiff PR 都已合并。因此，在使用 autodiff 特性构建 rust-lang/rust 后，用户现在就可以使用它，无需任何自定义 fork。
2. std::autodiff 收到了新贡献者的首批 PR，他们之前并未参与过 rustc 开发！我的计划是建立一个团队来维护这项特性，所以这是一个很棒的开始。这些 PR 在这里、这里和这里。随着时间的推移，我希望能够移交越来越大的议题。
3. 我收到了加入 Rust 编译器团队的邀请，所以现在我也可以正式审阅和批准 PR 了！目前，我将专注于审阅我最熟悉的领域的 PR，包括 autodiff、batching，以及即将到来的 GPU 卸载。
4. 我实现了一个独立的 batching 特性。它规模稍大（约 2k 行代码），并且需要一些（当时尚未合并的）autodiff PR，因为它们都使用了相同的底层 Enzyme 基础设施。因此我没有推动将其合并。
5. 我最近将 batching 实现为 autodiff 宏的一部分，供希望两者一起使用的人员使用。随后，我拆分出了第一批代码改进和重构，这些改进和重构已经合并。剩余的 autodiff 特性PR只有 600 行代码，所以我目前正在清理它以便进行审阅。
6. 我花时间准备了一个 MCP，以在 CI（以及 nightly 构建）中启用 autodiff。我还花了很多时间讨论 rustc 潜在的 MLIR 后端。如果您想参与，请联系我！

**寻求帮助：** 我们希望在 lib 构建中支持 autodiff，而不仅仅是二进制文件。oli-obk 和我最近找到了底层 bug，我已经在 https://github.com/rust-lang/rust/pull/137570 中开始了一个 PR。问题在于 autodiff 假定使用 fat-lto 构建，但 lib 构建会使用 thin-lto 编译部分库代码，即使用户在 Cargo.toml 中指定了 lto=fat。如果将 Autodiff 作为临时解决方案启用，我们会希望将所有内容都移至 fat-lto，后续再转向 embed-bc 作为长期解决方案。如果您有时间提供帮助，请联系我们！我们中的一些人已经研究过一点，但被其他事情分散了注意力，所以最好先讨论一下哪些代码可以重用，而不是从头开始。

我也预订了 RustWeek 的门票，所以我很乐意讨论各种科学计算、HPC、ML，或者“受诅咒的” Rust(c) 和 LLVM 内部机制！如果您也去并想见面，请随时私信我。

@Eh2406 于 2025 年 3 月 14 日发布的评论

由于 $DAY_JOB 中的高优先级任务，进展持续受阻。目前仍不清楚工作需求何时允许我重新专注于该项目。

@epage 于 2025 年 3 月 17 日发布的评论

• 关键进展
  • 在处理 #92 的任务间隙，我开始重新熟悉 libtest-next 的代码库。
• 阻碍
• 寻求帮助

@folkertdev 于 2025 年 3 月 18 日发布的评论

@traviscross 我们如何在此方面取得进展？到目前为止，我们主要与 @joshtriplett 进行了交流，前提是循环上的 #[loop_match] 属性与标记“跳转到下一次迭代”的 #[const_continue] 属性相结合，作为语言实验是可以接受的。

我们当前的实现处理以下内容

#![feature(loop_match)]

enum State {
    A,
    B,
}

fn main() {
    let mut state = State::A;
    #[loop_match]
    'outer: loop {
        state = 'blk: {
            match state {
                State::A =>
                {
                    #[const_continue]
                    break 'blk State::B
                }
                State::B => break 'outer,
            }
        }
    }
}

关键在于，这不增加新的语法，仅增加属性和 MIR 降低中的内部逻辑，用于静态执行模式匹配以选择要跳转到的正确分支。

那么主要的挑战是在编译器本身中实现这一点，我们一直在努力（我很快会发布我们的 tl;dr 更新）

@folkertdev 于 2025 年 3 月 18 日发布的评论

一些基准测试（截至 3 月 18 日）

https://github.com/bjorn3/comrak/blob/loop_match_attr/autolink_email.rs 的基准测试，这基本上是一个大型状态机，非常适合 loop match

Benchmark 1: ./autolink_email
  Time (mean ± σ):      1.126 s ±  0.012 s    [User: 1.126 s, System: 0.000 s]
  Range (min … max):    1.105 s …  1.141 s    10 runs
 
Benchmark 2: ./autolink_email_llvm_dfa
  Time (mean ± σ):     583.9 ms ±   6.9 ms    [User: 581.8 ms, System: 2.0 ms]
  Range (min … max):   575.4 ms … 591.3 ms    10 runs
 
Benchmark 3: ./autolink_email_loop_match
  Time (mean ± σ):     411.4 ms ±   8.8 ms    [User: 410.1 ms, System: 1.3 ms]
  Range (min … max):   403.2 ms … 430.4 ms    10 runs
 
Summary
  ./autolink_email_loop_match ran
    1.42 ± 0.03 times faster than ./autolink_email_llvm_dfa
    2.74 ± 0.07 times faster than ./autolink_email

#[loop_match] 优于现状，并且也大幅优于 llvm 标志。

---

使用 16 字节块进行 zlib 解压缩的基准测试（这使得 loop_match 的影响更明显）

Benchmark 1 (65 runs): target/release/examples/uncompress-baseline rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          77.7ms ± 3.04ms    74.6ms … 88.9ms          9 (14%)        0%
  peak_rss           24.1MB ± 64.6KB    24.0MB … 24.2MB          0 ( 0%)        0%
  cpu_cycles          303M  ± 11.8M      293M  …  348M           9 (14%)        0%
  instructions        833M  ±  266       833M  …  833M           0 ( 0%)        0%
  cache_references   3.62M  ±  310K     3.19M  … 4.93M           1 ( 2%)        0%
  cache_misses        209K  ± 34.2K      143K  …  325K           1 ( 2%)        0%
  branch_misses      4.09M  ± 10.0K     4.08M  … 4.13M           5 ( 8%)        0%
Benchmark 2 (68 runs): target/release/examples/uncompress-llvm-dfa rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          74.0ms ± 3.24ms    70.6ms … 85.0ms          4 ( 6%)        🚀-  4.8% ±  1.4%
  peak_rss           24.1MB ± 27.1KB    24.0MB … 24.1MB          3 ( 4%)          -  0.1% ±  0.1%
  cpu_cycles          287M  ± 12.7M      277M  …  330M           4 ( 6%)        🚀-  5.4% ±  1.4%
  instructions        797M  ±  235       797M  …  797M           0 ( 0%)        🚀-  4.3% ±  0.0%
  cache_references   3.56M  ±  439K     3.08M  … 5.93M           2 ( 3%)          -  1.8% ±  3.6%
  cache_misses        144K  ± 32.5K     83.7K  …  249K           2 ( 3%)        🚀- 31.2% ±  5.4%
  branch_misses      4.09M  ± 9.62K     4.07M  … 4.12M           1 ( 1%)          -  0.1% ±  0.1%
Benchmark 3 (70 runs): target/release/examples/uncompress-loop-match rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          71.6ms ± 2.43ms    69.3ms … 78.8ms          6 ( 9%)        🚀-  7.8% ±  1.2%
  peak_rss           24.1MB ± 72.8KB    23.9MB … 24.2MB         20 (29%)          -  0.0% ±  0.1%
  cpu_cycles          278M  ± 9.59M      270M  …  305M           7 (10%)        🚀-  8.5% ±  1.2%
  instructions        779M  ±  277       779M  …  779M           0 ( 0%)        🚀-  6.6% ±  0.0%
  cache_references   3.49M  ±  270K     3.15M  … 4.17M           4 ( 6%)        🚀-  3.8% ±  2.7%
  cache_misses        142K  ± 25.6K     86.0K  …  197K           0 ( 0%)        🚀- 32.0% ±  4.8%
  branch_misses      4.09M  ± 7.83K     4.08M  … 4.12M           1 ( 1%)          +  0.0% ±  0.1%
Benchmark 4 (69 runs): target/release/examples/uncompress-llvm-dfa-loop-match rs-chunked 4
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          72.8ms ± 2.57ms    69.7ms … 80.0ms          7 (10%)        🚀-  6.3% ±  1.2%
  peak_rss           24.1MB ± 35.1KB    23.9MB … 24.1MB          2 ( 3%)          -  0.1% ±  0.1%
  cpu_cycles          281M  ± 10.1M      269M  …  312M           5 ( 7%)        🚀-  7.5% ±  1.2%
  instructions        778M  ±  243       778M  …  778M           0 ( 0%)        🚀-  6.7% ±  0.0%
  cache_references   3.45M  ±  277K     2.95M  … 4.14M           0 ( 0%)        🚀-  4.7% ±  2.7%
  cache_misses        176K  ± 43.4K      106K  …  301K           0 ( 0%)        🚀- 15.8% ±  6.3%
  branch_misses      4.16M  ± 96.0K     4.08M  … 4.37M           0 ( 0%)        💩+  1.7% ±  0.6%

重点是：loop-match 比 llfm-dfa 快，并且当两者结合使用时，性能比单独使用 loop-match 要差。

@traviscross 于 2025 年 3 月 18 日发布的评论

感谢您的更新。我已单独联系您。

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

我们已经成功将 Rust 编译器中对 contracts 的初步支持合并到 contracts 不稳定特性下。@tautschnig 创建了第一个 PR，将 contracts 集成到标准库中，并发现了一些我们正在解决的限制。

@jieyouxu 于 2025 年 3 月 15 日发布的评论

更新 (2025 年 3 月 15 日)

• 正在对 compiletest 进行全面审查，以确保我对其有全面的了解。

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

经过进一步审阅，我决定最初限制范围，不超前行事，以便确保我正在处理的 schema 能够支持我们最终在不稳定特性使用度量指标的最终版本中所需的查询和图表类型。我希望通过限制范围，我能够提前完成此项目目标中概述的大部分事项，以便我可以在概念验证的基础上构建适当的基础，并开始设计更永久性的组件。因此，我选择了以下几点：

• 对当前所需的 JSON 格式进行最小改动，即包含时间戳
• 明确 unstable feature usage metrics 需要回答哪些具体问题，期望的图表和表格是什么，以及这如何影响我需要收集的信息以及如何在 graphana 中构建适当的查询。
• 从 docs.rs 收集样本数据集，而不是将其视为长期集成，因为初步与 docs.rs 交流发现该数据集中确实存在一些样本集偏差问题
  • 弄清楚在度量指标文件名中使用适当的哈希/ID，以避免同一 crate 在启用不同特性时产生的不同条件编译变体之间的命名冲突。

对于上面第二点，我需要与 @rust-lang/libs-api 和 @rust-lang/lang 进行更详细的交流。

@nikomatsakis 于 2025 年 3 月 17 日发布的评论

更新

@tiif 一直致力于将 const-generic 影响集成到 a-mir-formality 中，并取得了良好进展。

我已开始探索集成 MiniRust 对 MIR 的定义。这虽然不直接服务于建模一致性（coherence）的目标，但对于 const generic 工作有效开展是必需的。

我也正在考虑进行一些简化和清理工作。

@lcnr 于 2025 年 3 月 17 日发布的评论

之前更新中提到的两个循环处理 PR 已合并，使得 nalgebra 在启用新解析器的情况下能够编译。我现在又开始研究 borrowck 中的 opaque types。这是一个相当复杂的问题，可能还需要几周才能完全实现。

@veluca93 于 2025 年 3 月 17 日发布的评论

关键进展：已开始研究提出的 SIMD 多版本选项如何与 Rust effect system 形式化的努力相结合。

@blyxyas 于 2025 年 3 月 17 日发布的评论

月度更新！

• https://github.com/rust-lang/rust-clippy/issues/13821 已合并。这成功优化了从源代码中提取 MSRV 的过程。

在旧的 MSRV 提取过程中，Symbol::intern 的使用量非常高，约为其余编译过程总和的 3.5 倍。现在，已恢复到正常水平。请注意，Symbol::intern 是一个非常昂贵且带有锁的函数，因此这一点非常值得关注。感谢 @Alexendoo 完成这项了不起的工作！

总体来说，本月我们进行了很多实验。

• 开始并行化 lint 系统的努力。
• https://github.com/rust-lang/rust-clippy/issues/14423 开始深入研究我们对 libLLVM.so 的依赖以及严重的重定位问题。
• 我研究了堆分配优化，看起来我们做得不错。目前，rust-clippy#14423 是优先级。

@oli-obk 于 2025 年 3 月 20 日发布的评论

我提交了一个 RFC (https://github.com/rust-lang/rfcs/pull/3762)，并且我们召开了一次语言团队会议进行讨论。经过一些设计探索和反复讨论后，我们决定使用 (const) 而不是 ~const，同时在某些地方增加更多注解以提高清晰度，而在其他地方则减少注解。RFC 已相应更新。关于为了冗余和方便人工处理而重新引入“更少注解”的讨论仍在进行中。

@JoelMarcey 于 2025 年 3 月 14 日发布的评论

关键进展：正在准备一份公开声明，宣布 Ferrous 贡献 FLS。目标是尽快发布。同时也在解决贡献的技术细节，特别是关于如何将 FLS 初步集成到项目本身。

阻碍：暂无。

@JoelMarcey 于 2025 年 4 月 1 日发布的评论

关键进展：公开宣布将 FLS 捐赠给 Rust 项目。

阻碍：无

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

我们已向 Google Summer of Code 提出了一个项目构思，旨在实现本项目所需的重构和基础设施改进。我正在将工作分解成更小的任务，以便可以逐步实现。

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

我也很高兴地分享 @makai410 将加入这项工作！🥳

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

更新：二月份的目标更新已发布。我们对目标更新的准备方式进行了重大修订。如果您是目标负责人，值得阅读关于如何报告您的状态的说明，特别是关于寻求帮助和摘要评论的部分。

@nikomatsakis 于 2025 年 3 月 17 日发布的评论

更新：我们已发出三月份更新的第一轮通知（pings）。计划在3月25日创建文档，所以 @rust-lang/goal-owners 请在此日期之前提交您的更新。请注意，如果您想添加 2-3 个要直接嵌入最终博客文章中的要点，可以创建一个TL;DR 评论。

目标规划方面

• @nandsh 计划结合她在 CMU 的研究，对目标计划进行详细回顾。如果您有兴趣参与，请在 Zulip 上联系她（Nandini）。
• 我们计划按照此 hackmd 中所述彻底改革通知（ping）流程。简而言之，通知将在每月的第二个/第三个周一发出。如果您本月已发布评论，则不会发送通知。博客文章将在第三个周五准备。
• 我们一直在讨论如何构建 2025 年下半年的目标，并考虑进行一些调整。我们将目标分为三类（旗舰目标 / 核心目标 / 延伸目标），其中“核心”目标被认为是最重要的。在 RFC 开放之前，我们还将与团队负责人进行“预读”，以寻找跨团队协作的机会。至少，这是目前的计划。

@nikomatsakis 于 2025 年 3 月 17 日发布的评论

更新

我已邀请 @jackh726 与我共同领导该团队。我们一起制定了一份Rust 愿景文档行动计划。

该计划首先发布一篇博客文章（草稿在此处）宣布这项工作。我们正在与基金会协调创建一份调查问卷，该问卷将从博客文章中链接。该调查问题询问用户体验，同时也寻找可以与我们交流的志愿者。

我们正在组建将进行访谈的团队。我们已与 UX 研究人员联系，他们将向我们介绍 UX 研究的一些基础知识。我们现在正在确定团队成员以及重点领域，预计至少将涵盖用户/公司、Rust 项目维护者和 Rust 全球社区。更多详情请参阅Rust 愿景文档行动计划。

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

一个小更新，@Jamesbarford 与 @kobzol 就高层架构达成一致，并将开始充实细节并对 rustc-perf 进行一些小修补，以熟悉代码库。

@lqd 于 2025 年 3 月 24 日发布的评论

以下是本次更新的关键进展。

Amanda 继续进行占位符移除任务。特别是处理重写类型测试中剩余的问题。正在进行的工作导致在重写方案下发出了不正确的错误，并讨论了一种新的处理策略。这已在 PR 中实现，并且看起来符合预期。因此，该 PR 现在应该处于可以进行更深入审阅的状态，有望很快合并。

Tage 已经开始了硕士论文，重点关注借用检查过程的最早部分，以便试验分级借用检查、增量式处理、避免对未失效的借用进行不必要的工作等。这些部分已经取得了很大进展，并且在后期领域（活跃和活动的借用）也在讨论更多内容。

我专注于处理位置敏感分析中剩余的诊断和测试失败问题。特别是诊断方面，先前更新中提到的 PR 都已合并，我修复了一些 NLL spans，修复了 compare-mode 下所有剩余的差异，并批准了那些属于改进的差异。对于测试失败问题，在遍历中以不同方式处理 liveness 修复了大部分剩余失败，而有几个是由于与 mid-points avoidance scheme 的冲突。对于这些问题，我们有几种不同的前进路径，但各有权衡，我们将在近期讨论和评估这些方案。还有另外两个问题仍需深入分析，以了解具体情况。

我们近期的重点将是继续沿着正确的道路前进，同时扩展在某些非常细分领域感觉不足且我们希望改进的测试覆盖率。同时，我们也将努力找出更好的架构来简化整个端到端流程，以允许提前退出、避免不必要的工作等。

@lqd 于 2025 年 3 月 26 日发布的评论

这个项目目标实际上是从 2024 年下半年延续过来的，见https://github.com/rust-lang/rust-project-goals/pull/294

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

一个小的更新，我们已经为该功能的初步实现开启了一个草稿 PR - rust-lang/rust#137944。除此之外，我们只是继续处理 RFC 的反馈意见。

@davidtwco 于 2025 年 3 月 18 日发布的评论

• 我们一直在解决关于 rust-lang/rust#137944 中 Sized Hierarchy RFC 实现的审阅反馈意见。我们还在努力减少该 PR 中的性能退化，方法是避免不必要的 sizedness supertrait 展开，并扩展 type_op_prove_predicate 查询快速路径中现有的 Sized 情况。
• RFC 没有变化，有一些小的反馈意见尚未回复，但除此之外，它只是在等待 t-lang 团队的审阅。
• 我们一直在尝试将 rust-lang/rust#118917 rebase 到 rust-lang/rust#137944 之上，以确认 const sizedness 使我们能够移除 SVE 实现之前依赖的类型系统异常。我们很高兴确认它可以做到。

@Muscraft 于 2025 年 3 月 31 日发布的评论

尽管过去几个月我的时间有限，但取得了很大进展！我成功地将 annotate-snippets 内部与 rustc 的 HumanEmitter 对齐，并实现了新的 API。这些更改尚未合并，但可以在这里找到。作为这项工作的一部分，我让 rustc 使用 annotate-snippets 作为其唯一的渲染器。在此期间，我开始致力于让 rustc 使用 annotate-snippets 作为其唯一的渲染器，这被证明有巨大的好处。在解决渲染差异的同时，我熟悉了新的 API。截至撰写本文时，大约 18,000 个 UI 测试中，只有约 30 个未通过。

test result: FAILED. 18432 passed; 29 failed; 193 ignored; 0 measured; 0 filtered out; finished in 102.32s

大多数失败的测试是由几个原因引起的

• annotate-snippets 右对齐数字，而 rustc 左对齐
• annotate-snippets 对同一 span 的多个建议处理得不太好
• 处理 FailureNote 的问题
• annotate-snippets 目前不支持彩色标签和标题，例如 rustc 使用的洋红色高亮
• rustc 希望传递类似 error: internal compiler error[E0080] 的标题，但 annotate-snippets 对此支持得不太好
• rustc 和 annotate-snippets 在测试期间处理终端宽度的方式存在差异
  • 在测试时，rustc 使用 DEFAULT_COLUMN_WIDTH 且不减去代码偏移，而 annotate-snippets 会减去
• 处理“换行”/行尾高亮的方式略有差异
• JSON 输出渲染包含颜色转义码