【问题初现】每个程序员至少都曾暗自想过“不是我的问题是编译器的问题”通常情况下大家都想错了但这次这位程序员真的是对的。某个周六晚上他正在重构自己 JavaScript 引擎的解析器之前写的一段代码他不太喜欢其结构于是动手重写了一个版本单独看生成的汇编代码他对美观度很满意代码短了几个字节还没有分支。【解析出错】然而当他试着解析一条简单的语句时却出现了错误。这让他怀疑是不是自己把函数写坏了也许 x as u32 的语义和记忆中的不一样于是他把代码写得更明确些结果这个版本居然正常工作了。他很确定自己知道 bool as u32 的作用自己写过几百次这样的类型转换了于是说出了每个绝望又有点困惑的程序员都会说的话“不是我的问题是编译器的问题”【检查代码】他得看看 for 语句解析器到底在做什么幸运的是他有自己的自定义构建系统查看任何函数的汇编代码只需一条命令。言归正传他开始检查汇编代码还先看了 Rust 代码的简化版本。现在揭晓答案查看汇编代码后他发现自己的 match 语句不见了仔细看能看到和 TokenKind::LParen 的比较这几乎可以确定是来自 consume_test(store, TokenKind::LParen)。【确定问题】通过对解析器的 ABI 分析汇编代码很好理解了但他发现 consume_test 里的 self.0 x as u32 对应的 INC ESI 不见了这基本可以确定是编译器的问题。接下来他要写一个最小可复现示例发现问题在 1.94.0 - nightly 版本里未修复。为确定是 Rust/MIR 问题还是 LLVM 问题他使用 -Zmir - opt - level 0问题就解决了。【提交问题与修复】他提交了一个问题标题写的是“ **疑似** 编译错误”。第二天醒来他发现 [Hanna Kruppe](https://github.com/hanna - kruppe) 已经提交了一个[修复 PR](https://github.com/rust - lang/rust/pull/158214)响应速度简直无敌。这个问题被标记为 p - critical 和 i - miscompile在超过 6.1 万个 Rust 问题中只有 7 个包括这个同时具备这两个标签。总共也只有 247 个 p - critical 问题。最棒的是社区对这个问题的响应非常迅速不到 18 个小时就修复了。现在他可以自豪地讲述自己和 rustc 战斗并获胜的故事啦2026 年 6 月 22 日