Linus、Rustのフォーマットチェックを「無神経でクレイジー」と酷評

10月12日に予定されている「Linux 6.18」のマージウィンドウ終了と最初のリリース候補版（Linux 6.18-rc1）の公開に向け、プルリクエストのチェックに大忙しのLinusだが、マージウィンドウ期間中はプルリクエストに対するLinusの手厳しい批判が増える時期でもある。10月1日、LinuxグラフィクスメンテナーのDave Airlie（Red Hat所属）が提出したDRM（Direct Rendering Manager：GPUを制御/管理するカーネルサブシステム）のプルリクエストに対しては、コーディングのスタイルに加え、Rustのフォーマットチェック機能に対するLinusの不満があふれ出たものとなった。

Re: [git pull] drm for 6.18-rc1 -Linus Torvalds

Airlieが提出したDRMプルリクエストに対し、Linusはまず「説明文のインデントがおかしい。何が間違っているのかわからないけど、とにかく間違っている。まるですべてのインデントをなくしてしまっているかのようだ」と批判、その最たる例としてRust関連の記述部分を挙げている。

rust:
- drop Opaque<> from ioctl args
- Alloc:
- BorrowedPage type and AsPageIter traits
- Implement Vmalloc::to_page() and VmallocPageIter
- DMA/Scatterlist:
- Add dma::DataDirection and type alias for dma_addr_t
- Abstraction for struct scatterlist and sg_table
- DRM:
- simplify use of generics
- add DriverFile type alias
- drop Object::SIZE
- Rust:
- pin-init tree merge
- Various methods for AsBytes and FromBytes traits

Linusはインデントが不定だったりサブエリアが不明で見づらいメッセージを非常に嫌うことで知られているが、今回のAirlieの記述はLinusが嫌がる要素が多数含まれており、「⁠Alloc、DMA/Scatterlist、DRM、Rustといった複数のサブエリアがごちゃ混ぜになっていてインデントが抜け落ちている。いったいどんな壊れたエディタを使っているのか? Emacsやviとの争いを起こしたいわけじゃないけど、本当に壊れたエディタ使っているみたいだ。もしかしてEDLIN?」と、いつにも増してきびしい言葉で批判している（EDLINはMS-DOSで標準提供されていたコマンドラインエディタ⁠）⁠。

「いいかい、もう一度言うけど、君が書いたものは論理性がなく、おそらくどこかの時点で存在していたであろう多層インデントを完全に破壊している。なんでそんなことしたの? 僕は定期的に誰かの言語スキルを指摘することはある。それは必ずしも英語が母国語ではないことを理解しているからだ。だけど僕がこういうふうに“⁠元のメッセージを完全に破壊している⁠”というときは“⁠マジでうっとうしい（annoying）⁠”と感じているんだ。説明文は“⁠読みやすい⁠”ものにしてくれ。単なる言葉の羅列ではだめだ」（⁠Linus）

また、Linusは同じメッセージで、Rustで書かれたカーネルコードのフォーマットを自動でチェックするrustfmtcheckおよびそのアップストリームのrustfmtに対しても「より技術的な側面でいえば、Rustの無神経で完全にクレイジーなフォーマットチェックに心から嫌悪感を抱く」と強い不満を示しており、Rust for LinuxのメンテナーであるMiguel Ojedaに「rustfmtchekは完全に間違っている」と投げかけている。

今回のRust DRMコードにはuse crate::xyz;という表記が複数回使われていたのだが、Linusは「ほかのクレートを簡単に追加し、混乱を招かない」ためにこの表記を以下のように変更した。

  use crate::{
     xyz,
    abc,
  };

しかし、これをrustfmtcheckにかけるとuse crate::{xyz, abc};と「すべて逆の、ゴミのような提案」をされたことから、Linusは「⁠（⁠rustfmtcheckのガイドは）複数行にわたって表記するのか、それとも圧縮形式を使うのか、そのヒューリスティック（経験値ベースの判断基準）がまったくわからない。本当に腹ただしくてうっとうしい。自動化ツールが文字通り、保守性にとって誤った判断を下している」としている。

さらにOjedaに対して「rustfmtchekは完全に間違っている。その瞬間は正しいかもしれないが、(a)マージ時にルールがいったい何なのかわからないのでイライラする (b)“⁠新しい用途に1行追加する⁠”という明確なリストがないと長期的には悪影響 ―これに対するまともな解決策はある?」「⁠（⁠rustfmtcheckの）このランダムなヒューリスティックを修正してほしい。実際に共通のデータ構造をもつものなら理にかなっているかもしれないが、useディレクティブは文字通り使用される独立されたものについてであり、それらをすべてまとめてしまうのはまったくもって間違っている」とRustのフォーマットルールに対する批判と要望を綴っている。

Linusはrustfmtcheckに自動整形の実行を許さず、チェック機能だけにとどめているが、インデントなしのスタイルや自動整形のあいまいなルール、useの独立性を崩す記述、差分/マージのノイズ増加などLinusにとって受け入れがたい問題が解決されない限り、“⁠Rust for Linux⁠”への道のりはまだまだ長いものとなりそうだ。