開発者が狂っていないのはコンパイラだった：Rust コンパイルの奇妙な誤動作と解決記

開発者はかつて、「これは俺のせいじゃない。コンパイラのせいだ！」と呟いたことがあります。しかし、今回は実際にその通りだったという稀な体験談です。

1. バグを発見する瞬間

JavaScript エンジンのパーサーをリファクタリング中、従来のコードパターンを改善しようとしていました。

元のコード（一般的なパターン）

impl LexerConsumer {
    #[inline]
    pub fn consume(&mut self) {
        self.0 += 1;
    }

    #[inline]
    pub fn consume_test(&mut self, store: &LexStore, expected: TokenKind) -> bool {
        if self.peek(store) == expected {
            self.consume();
            true
        } else {
            false
        }
    }
}

改善しようとしたコード

生成されるアセンブリコードが美しく、かつバイト数も減少しましたが、動作に問題が発生しました。

#[inline]
pub fn consume_test(&mut self, store: &LexStore, expected: TokenKind) -> bool {
    let x = self.peek(store) == expected;
    self.0 += x as u32; // ここで問題が発生
    x
}

発生したエラー

Bash ヒストリ上に

for

> joe parse - 'for (var lol; false; false) {}'
Error was found
Diagnostic { kind: E079, flag: Flag(11529215046068469773), byte: 5, current_token: Var }
Parse error

解決への試み（偽の解決）

x as u32

#[inline]
pub fn consume_test(&mut self, store: &LexStore, expected: TokenKind) -> bool {
    let x = self.peek(store) == expected;
    self.0 += if x { 1 } else { 0 }; // これなら正常に動作
    x
}

これで問題は解消されました。自信を持っていましたが、何か見落としていることに気づきました。

2. コンパイラが原因と判明

開発者は通常「bool を u32 として扱う仕組み」を理解しているはずですが、今回は**コンパイルの誤翻訳（Miscompilation）**が起きていることが分かりました。

自前のビルドシステムでアセンブリを確認

cargo asm

コマンド例:

> x -b --fn ForOrInOfStatement 1 --dry  
MKDIR ./out
RUN rustc src/main.rs ... # (略)
RUN mold -melf_x86_64 -o ./out/joe ...
RUN bash -c nm out/joe | rustfilt | grep ForOrInOfStatement ...

アセンブリコードの分析

Rust コードでは以下の構造になっています。

fn ForOrInOfStatement(...) -> Termination {
    // ... 
    if lex.peek_test(store, TokenKind::LParen) { ... }
    
    if !lex.consume_test(store, TokenKind::LParen) {
        return raise_diagnostic(...); // エラーhere
    }
    // match 文で分岐が行われるはずだが...
}

問題のアセンブリコードの箇所

ForOrInOfStatement

> x -b --fn ForOrInOfStatement 1
000000000021e290 <joe::fe::parser_handlers::ForOrInOfStatement>:
  21e290:              ff c6                    inc    esi       # lex.consume() // for
  21e292:              89 f0                    mov    eax,esi
  ...

重要な発見:

• inc esi

  (インクリメント) が呼ばれていました。
• しかし、その後の処理で

  TokenKind::LParen

  との比較が行われた際、インクリメントされなかった値が使用されていた迹象が見えた。
• 実際には

  consume_test

  内の

  self.0 += x as u32

  が正常に実行されたように見えたが、コンパイラがそれを誤って解釈していた。

疑問:

*   `# consume_test で self.0 += x as u32 と書かれなかったのか？`
*   `# WAIT.... WHO ATE MY INC ESI?! （誰が私の inc esi を喰らったのだ！）`

3. 調査と原因の特定

誤翻訳の可能性を裏付けるため、詳細な調査を行いました。

リバースエンジニアリングによる確認

• LLVM IR の最適化前を確認するために

  -Cno-prepopulate-passes

  を使用。
  • 初期化されていないメモリからのロードを検出可能。
• Rust/MIR の問題か LLVM の問題かを区別するため

  -Zmir-opt-level=0

  を使用。
  • これにより問題が解決し、原因は Rust コンパイラ側にあることが確認された。

ミニマルな再現例（MRE）の作成

単に「馬鹿なコードを書いたわけではない」ことを証明するために、最小化された再現例を作成しました。

Issue 登録

• タイトル:

  Suspected miscompilation

  (疑わしい誤翻訳)
  • 「コンパイルが正しいと断言している場合、自分自身を責めるための防御壁」として「suspected」を付加。
• 環境: Rust nightly 1.94.0-nightly
• 状況: Nightly で修正されているかもしれないと考えたが、依然として問題が発生していた。

4. 対応と解決

翌日、目覚めた時点でコミュニティによる迅速な対応が行われていました。

コミュニティの対応

1. Hanna Kruppe による修正 PR がオープンされていた。
2. Issue ラベル:

   • p-critical

     (重大)

   • i-miscompile

     (誤翻訳)
3. ステータス:
   • Rust の全問題のうち、これらのラベルを併せ持つのはわずか 7 つ（その 1 つ）。

   • p-critical

     ラベル自体も合計 247 件しか存在しない。

結論：コンパイラーの危険なバグ

この種の誤翻訳は「プログラマーと言語の間の契約」を破るため、最も危険なバグの一つとされています。安全に書かれたコードが必ずしも安全とは限らないことを示す典型例です。

• 解決までの期間: 問題が発生してから18 時間以内で修正がマージ（Landed）。
• 拍手を送りたい人:

  tmiasko

  および

  hanna-kruppe

  の迅速な対応に対して感謝する。

まとめ

この体験を通じて、以下のことを学びました。

• 「これは俺のせいじゃない。コンパイラのせいだ！」 という言葉は、実際には正しい場合がある。
• Rust コンパイラと戦い勝つことができた経験を得た。
• コミュニティの迅速な対応により、重大なセキュリティや安定性のリスクを早期に解消することが可能になった。

これからの Rust 開発において、コンパイルの振る舞いを疑うことは決して馬鹿げたことではないことを確認しました。