悪いのは私じゃない、コンパイラのせいだ：不可解なバグに直面した時の言い訳

「コードは完璧なはずなのに動かない」…そんな時、私たちはついコンパイラのせいにしてしまいがちですよね。しかし、本当にコンパイラのバグなのか、それともあなたの見落としか？エンジニアなら誰もが一度は通る、この「終わらない犯人探し」について語り合いましょう。

面白い話ですね。余談ですが、元のif文があるコードの方が分かりやすいしデバッグも楽だったんじゃないかな。少し長くなったとしても。

いい記事だね。コンパイラのバグを報告するのは勇気がいることだから、よくやったと思うよ。ちなみに、ブログの左側にある進捗インジケーターの色がすごく気に入った！

そもそもこれは最適化じゃなくて、警告にすべきだったんじゃないかな。個人的には、デッドコードの削除は、プログラム全体を見てブランチが通らないことが証明できるリンク時最適化の段階で行うべきだと思う。どのブランチでも使われていない代入があるなら、コンパイラは警告を出して、ユーザーが自分で削除するか、無視するかを選べるようにすべき。コンパイラにとって最悪なのは、サイレントに誤った最適化を適用することだよ。もちろん、他のほとんどの最適化についても同じように感じてる。コンパイラが最適化できるなら、どう最適化すべきかをユーザーに提示して、ユーザー自身が書き直せるようにすればいい。そうすれば、このような誤コンパイルを防げるし、コンパイラ側が無理な処理をする必要もなくなってビルド時間が爆発するのも防げる。人間が読めるコードをマシンコードに変換するだけで済むはずだからね。

特に面白いのは（コンパイラチームのメンバーがZulipで指摘していた通り）、これがセーフコードの中でも比較的簡単に遭遇してしまう誤コンパイルだったってことだね（やばいね）。MIRの最適化パイプラインの後半のパスが原因みたいだけど、このあたりのパスは健全性が慎重に検証されているはずだと思ってたから、こんなのが入り込んだのは驚き。

筆者がここを見てたら教えてあげたいんだけど、2段落目にタイプミスがあるよ。「eariler」じゃなくて「earlier」が正しいはず。

8歳くらいからプログラミングを始めたけど、子供の頃は「コンパイラが間違ってる」って確信しがちで、実際はそんなこと一度もないんだよね（一度だけあったかもしれないけど、うろ覚えだ）。でも何年かして、ベータ版だった頃のNimで遊んでたら、数週間で3つもコンパイラのバグを見つけた！全部報告して、全部直してもらったよ。その後数年して、RustとSIMDイントリンシックをいじってたら今度はLLVMにバグを見つけた。何が起きているのか説明するのすら大変だったけど、なんとか報告して確認してもらうことができた！

30年くらい前、Java SDKの初期の初期のバージョン、v1.0.1を触ってた時のこと。GridBagLayoutを使ってカレンダーを作ろうとしてたんだけど、日付のマス目が全部ぐちゃぐちゃになって重なって表示されたんだ。「コンパイラのバグではない」っていう基本ルールを信じて、自分が何か重要なことを見落としてるんじゃないかと思って、メーリングリストやUSENETで自分が何を間違えてるのか聞き回ったよ。自分では「正しく使っている（ドキュメントの推奨通りに使っている）」と思ってたけど、それでも何か勘違いしてるんだろうって思ってたんだ。結果として、それはJavaランタイムのバグで、v1.0.3で修正されたよ。