rust-code-review

Rust コードレビュー

孤立したスニペットや一般的なチェックリストではなく、実際の差分とその呼び出し元をレビューしてください。動作を変える、不変条件に違反する、データを露出する、デッドロックを起こす、予期せずパニックする、または公開 API を壊す可能性のある欠陥を優先してください。

対象範囲とルーティング

以下をレビューする場合は、このスキルを使用してください。

• 所有権、借用、ライフタイム、ドロップの動作
• unsafe の前提条件と安全なラッパーの健全性
• エラー伝播、パニック経路、部分更新、ロールバック
• 並行処理、キャンセル、ロック順序、タスクのライフサイクル
• 公開 API、semver、機能、ターゲット、MSRV との互換性
• 割り当て、クローン、ブロッキング、シリアライズ、ホットパスのコスト
• テスト、ドキュメント、依存関係、運用上の障害経路

フォーマットと lint の設定は rust-style-clippy に、詳細な unsafe または ABI の分析は rust-unsafe-ffi に、並行処理の設計は rust-concurrency に、依存関係の解決は rust-cargo-build に、テストの実装は rust-testing に、API の形状に関する判断（トレイトのシーリング、ニュータイプ設計、エラー分類、ビルダーパターン）は rust-api-design にルーティングしてください。

ワークフロー

1. レビューの前提を確立する

リポジトリの指示、変更されたファイル、周辺のシンボル、呼び出し元、テスト、マニフェスト、ロックファイル、宣言されている MSRV、有効な機能、サポート対象のターゲットを確認してください。この変更がプライベートな実装、公開ライブラリ API、永続データ、ワイヤーフォーマット、データベーススキーマ、またはセキュリティ境界に影響するかを判断してください。

関連する範囲を絞ったコマンドを使用してください。

git diff --check
cargo metadata --format-version 1
cargo check --workspace --all-targets --all-features
cargo test --workspace --all-targets --all-features
cargo clippy --workspace --all-targets --all-features -- -D warnings

コマンドを実行していない場合、そのコマンドが成功したと主張しないでください。コンパイルの成功を、動作の正しさの証明として扱わないでください。

2. 境界をまたいで動作を追跡する

変更された各経路について、入力、状態遷移、副作用、エラー、クリーンアップ、観測可能な出力を追跡してください。以下を確認してください。

• 参照のライフタイムが、それらの所有者やガードを超えていないか
• ムーブ、クローン、割り当てがコストやセマンティクスを変えていないか
• Option と Result が不在と失敗の情報を保持しているか
• 早期リターン、キャンセル、パニック、シャットダウン時にリソースが解放されるか
• 複数段階の変更やトランザクションが、必要な箇所でアトミックか
• リトライの回数に上限があり、操作に対して安全か
• ログ、Debug 出力、メトリクス、エラーがシークレットを露出していないか

3. Rust 固有の危険をレビューする

Unsafe と FFI

• すべての unsafe API と実装について、安全性の不変条件が文書化されていることを求めてください。
• unsafe ブロックを最小限にし、unsafe_op_in_unsafe_fn を明示的に有効にしてください。
• プロベナンス、有効性、アラインメント、初期化、エイリアシング、レイアウト、アンワインド、所有権の移転、解放の対称性を検証してください。
• 手動の Send または Sync 実装は、マーカーボイラープレートではなく unsafe の契約として扱ってください。

並行処理

• ロック順序と、ガードが .await、コールバック、ブロッキング I/O、またはユーザーコードをまたいで保持されるかを確認してください。
• キューの容量制限、過負荷時の動作、キャンセルの所有権、監視対象のタスク、決定的なシャットダウンを求めてください。
• I/O の並行処理と CPU の並列処理を区別してください。タスクやワーカーを追加しても、自動的にパフォーマンスが改善するわけではありません。

エラー処理

• ユーザー入力や外部入力から到達可能な場合、unwrap、expect、インデックスアクセス、アサーション、整数オーバーフローの仮定、到達不能分岐を指摘してください。
• 構造化されたライブラリエラーを保持してください。アプリケーションの境界でコンテキストを追加し、内部情報を漏らさないでください。
• クリーンアップやロールバックの失敗が黙って破棄されていないかを検証してください。

API と互換性

• 可視性、トレイト境界、自動トレイト、オブジェクト安全性、#[non_exhaustive]、機能の組み合わせ、ターゲット固有のコード、MSRV を確認してください。
• 生成されたメソッド、シリアライズ形式、エラーバリアント、公開された機能名を API サーフェスとして扱ってください。
• 永続化形式や転送形式を変更する場合は、明示的な移行を求めてください。

3a. API ガイドラインのレビュー観点

変更が加えられたすべての公開項目について、差分を Rust API Guidelines チェックリストの 4 つの章に照らして確認します。指摘を挙げる前に、具体的な呼び出し元で該当することを確認し、設計レベルの修正は rust-api-design に回します。各章の全項目、重大度、推奨コメントについては、API Guidelines Checklist を参照してください。

• 信頼性 — 呼び出し元の入力を受け取る公開メソッド内で、panic!、unwrap、expect、unreachable!、スライスのインデックスアクセス、transmute が使われている場合は指摘します（C-PANIC、C-UNWRAP、C-TRANSMUTE）。
• 型安全性 — bool パラメーターを複数受け取る関数や、列挙型またはニュータイプを使えば引数の順序ミスを防げるのに、互換性のあるプリミティブ型をそのまま受け取る関数を指摘します（C-BOOL、C-NEWTYPE）。
• 相互運用性 — Debug／Clone／PartialEq が実装されていない公開型、およびメソッドを借用するために Deref を実装するスマートポインター以外の型を指摘します（C-COMMON-TRAITS、C-CONVERT）。
• 将来への備え — 拡張可能な公開トレイトがシールされていない場合、およびライブラリのエラー型や設定用の列挙型に #[non_exhaustive] が付いていない場合は指摘します（C-SEALED、C-NON-EXHAUSTIVE）。

#[cfg(test)] モジュール内の unwrap／expect、不変条件が文書化された FFI シムにおける慣用的で失敗しない unsafe、単一の目的を持つ bool セッターは指摘しないでください。チェックリストの誤検知一覧も参照してください。

4. 根拠に基づいてパフォーマンスをレビューする

割り当て、クローン、ロック、アルゴリズムをパフォーマンス上の指摘として報告するのは、変更された経路において実質的な影響が見込まれる場合に限ります。見た目を整える書き換えより、測定を優先してください。非同期エグゼキューター上のブロッキング処理、意図しない二次的な処理量、繰り返し行われる解析、サイズの大きすぎる列挙型バリアント、不要なバッファリング、上限のない増大を確認してください。

追加の解析ツールを選ぶ際は、Review Tools and Checklist を読んでください。指摘の期待される形式については、Review Scenarios を読んでください。公開 API の表面に C-PANIC／C-UNWRAP／C-TRANSMUTE／C-BOOL／C-NEWTYPE／C-COMMON-TRAITS／C-CONVERT／C-SEALED／C-NON-EXHAUSTIVE の各ルールを適用する際は、API Guidelines Checklist を読んでください。

指摘の形式

要約より先に指摘を記載してください。各指摘には次の内容を含めてください。

1. 重大度と簡潔なタイトル。
2. 対象を絞ったファイル名と行範囲。
3. 具体的な失敗条件または呼び出し元の経路。
4. ユーザー、セキュリティ、互換性、または運用への影響。
5. 最小限の修正、または修正を証明するテスト。

正しさに関わる指摘として、スタイルだけの好みを報告しないでください。対応可能な指摘が残っていない場合は、その旨を述べ、検証上の未確認事項を明示してください。

完了条件

• 差分、呼び出し元、テスト、マニフェスト、関連する機能またはターゲットの境界を確認する。
• 再現可能な指摘を、対象を絞った位置情報とともに重大度順で報告する。
• 確認済みの不具合と、さらなる証拠が必要なリスクを分ける。
• 関連するチェックを実行するか、実行しない場合は明示的にその理由を示す。
• 依頼がない限り、変更範囲を黙って広げたり、修正を実装したりしない。

上流ソース

• Rust API Guidelines
• Rust Style Guide
• Rustonomicon
• Clippy documentation
• RustSec Advisory Database

データのプライバシー

このスキルはユーザーデータを収集、保存、送信しません。非公開レジストリーや外部レビューシステムに問い合わせる前に、許可を確認してください。