Clippyにcontributeするn個の理由

• 発表者はここ数カ月Rustの公式linterであるClippyにパッチを日常的に投げている
• 最近だと日常的にClippyにパッチを投げている日本人はほぼいない
  • （と思っている）
  • （なんなら1人ではと思っている）

• ClippyはRustのコードを解析して，潜在的な問題を指摘する言語公式のlinter
• lintルールが個別に定義されていていて，各ルールに引っかかると指摘が飛ぶ
  • 参考: ルール一覧
• lintルールによっては，修正後のコードも提案する
  • 「この部分が問題ですよ～」の指摘にとどまらず，「この部分が問題なので，こう書くと良いですよ～」の提案をする

• 本来lintという行為はコンパイルと相性が良い
  • AST（抽象構文木）などをコンパイラとlinterで別々に持つのは無駄だから
    • 特にRustのような中間表現を介する言語を対象とするならなおさら
  • だからコンパイラ（rustc）にも小さなlinterが入っている
    • Clippyはrustcがカバーしない範囲を（前衛的に）カバーする（前衛的という自覚はあるらしい）

ところで...

• 真に"良い"Rustのコードを書くにはコンパイラの内部構造を知っていると良い場合がある
  • 「内部的には各トークンはどの様な単位で分割されている?」
  • 「asyncはどのレイヤーでどの様に脱糖される?」
• いきなりコンパイラのソースを読むのは大変...
• ClippyはrustcとASTやHIRなどを共有している & 本質的には賢いパターンマッチ

• Clippyは言語公式のもの
  • issueには安定化前の言語機能についての要望も出される
  • 変な書き方をしたりしてバグった例も出される
• lintルールが細かく分かれているので，ユースケースに応じてベストプラクティスを学びやすい

• lintはメタ的な行為
  • アプリケーションコードが存在して，それに対して指摘を行う
• Clippyは広く使われているので，例えば「こう書くことでパフォーマンスが上がる」類のlintルールを実装すると，それに基づいて世界中のRustアプリケーションを速くすることができる（！）
  • 詳細は割愛するが，以前特定の処理を10倍程度速くするlintルールを実装したことがある
• コードスタイル等に関するlintの改善をすると，コンパイラのレイヤーではできない効率化も可能

• Clippy，その欠点
• 他の検査ツールとの比較
• Rustのエコシステムとの関わり
• etc...

• ClippyのリポジトリはRust本体のリポジトリと分けられている
• しかし，（実は）ClippyはRustのリポジトリのsubtree
  • 大体2週間に1度のペースでsyncが行われる
• よってClippyにコミットを積んでいるとRust本体のリポジトリにもコミットがいつの間にか積まれている$^1$

1: こういったリポジトリは他にもあります．ここを見ると分かりやすいです