プロンプトとスコープ
Rust 1.97 では Cargo に build.warnings が導入されました。warn がデフォルトであり、allow は調整可能な lint を非表示にし、deny はローカルパッケージからの lint 警告でビルドを失敗させます。この動作は CARGO_BUILD_WARNINGS や --keep-going でも変更可能です。また、このリリースではリンカーが成功した場合の標準エラー出力（stderr）がデフォルトで表示されるようになり、特別な linker_messages lint も導入されました。
これは、Rust のワークスペース、コンパイラツールチェーン、またはリリースポリシーを保守するエンジニアを対象としています。複数のローカルクレート、サードパーティの依存関係、Linux および Windows のビルド、そして 1 つのクロスコンパイルターゲットが存在することを想定しています。目標は、すべての黄色い行（警告）を赤色（エラー）に変えることではありません。それぞれのシグナルには、担当者、失敗ゲート、および解決への道筋が必要です。
面接官が評価するポイント
- ローカルコードの lint、依存関係の出力、リンカー診断、コンパイルエラーを分離できるか？
RUSTFLAGS=-Dwarningsを唯一の解決策として扱うのではなく、warn、allow、denyの境界を説明できるか？- 高速なローカルフィードバック、CI での強制、およびターゲット間での再現性のバランスを取ることができるか？
- 例外を監査可能な状態に保ち、キャッシュ、ビルドスクリプト、ツールチェーンのアップグレードへの影響を説明できるか？
不十分な回答は「CI で -D warnings を使用する」と述べるだけです。優れた回答は、まずシグナルを分類し、Cargo レベルのポリシーを選択し、ベースライン、担当者、検証コマンドを使用して誤検知を制御します。
最初に明確にすべき質問
- ゲートはワークスペースのクレートのみを対象とすべきか、それとも依存関係やリンカー出力も対象とすべきか？Cargo の
build.warningsは主にローカルパッケージに適用されるため、依存関係の警告は別途監視する必要があります。 - CI は複数のターゲットをビルドするか？クロスコンパイルでは、リンカー、sysroot、SDK、およびターゲット固有の診断に対して別々の記録が必要です。
- 1 回の実行ですべての問題を収集する必要があるか？その場合、
--keep-goingは関連する警告やエラーを収集するのに役立ちますが、失敗したビルドを成功させるわけではありません。 - 一時的な例外は許可されるか？lint またはメッセージ、ターゲット、理由、担当者、およびレビュー日を記録しないと、
allowが恒久的な黙殺につながります。
30秒の回答
「出力をローカルの調整可能な lint、サードパーティの依存関係の警告、リンカー診断、コンパイルエラーに分類します。ローカル開発は高速なフィードバックのために warn のままにし、CI ではワークスペースクレートに deny を、完全な結果を収集するために --keep-going を使用します。依存関係は、アップストリームに警告があるからといってすべての変更をブロックするのではなく、可視化したままアップグレード対象として追跡します。リンカー出力はターゲットごとにベースラインを取得し、無害であることが確認されたメッセージのみを明示的に許可します。すべての例外には担当者と有効期限を設定します。このポリシーは、マルチターゲットビルド、キャッシュヒット率の測定、およびツールチェーンと依存関係のアップグレード訓練によって検証します。」
ステップバイステップの解決策
1. シグナルの境界を定義する
終了コード、標準エラー出力（stderr）、および lint レベルを分離します。コンパイルエラーは常にブロックします。build.warnings はローカルパッケージ内の調整可能な lint を制御します。アップストリームの保守責任がこのリポジトリに暗黙的に割り当てられないよう、依存関係の出力は詳細ログに残します。リンカー診断はツールチェーンおよびターゲットごとに記録されます。
2. 環境を階層化する
ローカル開発は warn に維持します。開発者は過去のバックログ全体に作業を止められることなく問題を確認できます。CI ではリポジトリ自体のパッケージに deny を使用し、新しいコードによって調整可能な lint が追加されないようにします。また、リリースパイプラインでは「自分のマシンでは動く」がリリースの基準にならないよう、ツールチェーン、ロックファイル、およびターゲットマトリックスを固定（pin）します。
[build]
warnings = "warn"
[lints.rust]
linker_messages = "allow"linker_messages = "allow" の行は、そのプラットフォームのメッセージが無害であることが示された後にのみ有効となります。すべてのリンカー stderr に対するワイルドカードではありません。CI は環境変数を使用してローカルパッケージの警告レベルを変更できます。
CARGO_BUILD_WARNINGS=deny cargo check --workspace --all-targets --keep-going3. 依存関係とキャッシュを処理する
依存関係の警告は、クレート、バージョン、ターゲット、および最初に確認されたビルドとともに、アップグレードボードまたは許可リストに登録します。アップストリームのリスクをグローバルに隠蔽しないでください。Rust 1.97 のリリースノートには、警告動作を変更しても基礎となるビルドキャッシュは無効化されないと記載されています。ただし、ターゲット、ツールチェーン、または rustflags を変更すると異なるキャッシュキーが作成される可能性があるため、ヒット率は継続して監視してください。
4. クロスコンパイルを説明可能な状態にする
ターゲットごとに、コンパイラのバージョン、リンカーのパス、sysroot、SDK、ビルドスクリプトの出力、および警告のベースラインを保持します。特定のプラットフォームで一時的なリンカー例外が必要な場合は、そのターゲットにスコープを限定し、リンカーが変更されたときに再確認します。「Linux で何も出力されない」ことは、「Windows が安全である」ことの証拠にはなりません。
5. 例外と出口戦略を設計する
例外には、正確な lint またはメッセージ、ターゲット、担当者、および有効期限の 4 つのフィールドを記録します。ツールチェーンのアップグレードやリリースカンジデートごとに警告レポートを再生成します。例外の数や再発率が増加した場合は、ビルドマトリックスの拡張を一時停止し、まず原因を解消します。
6. ポリシーが機能することを検証する
ローカルの lint を意図的にトリガーする一時ブランチを使用して warn と deny の違いを検証し、クロスプラットフォームのリンカーサンプルを使用してベースラインを検証し、依存関係のアップグレード訓練を実行してアップストリームの警告が可視化されたままであることを確認します。ターゲットごとの失敗原因、警告数、ビルド時間、キャッシュヒット率、および例外の経過期間を追跡します。成功の定義は、新しいローカル lint が CI をブロックし、依存関係の問題が隠されず、承認されたリンカーメッセージが追跡可能な状態に保たれることです。
質の高い回答例
「グローバルな -Dwarnings から始めることはしません。まず、ゲートが保護すべき対象がワークスペースのリグレッションなのか、それともすべてのツールのメッセージなのかを定義します。Rust 1.97 の build.warnings はローカルクレートにとって適切な境界です。開発環境は warn のままにし、CI では 1 回の実行でより多くの結果を収集するために CARGO_BUILD_WARNINGS=deny を cargo check --workspace --all-targets --keep-going と共に使用します。依存関係の警告はアップグレードキューに送られます。これらは可視化されバージョン管理されるべきですが、アップストリームの警告がアプリケーションコードを自動的にブロックすべきではありません。
ターゲットごとにリンカーのベースラインを維持します。メッセージが無害であることを確認した後にのみ、そのターゲットの設定で linker_messages を許可し、プラットフォーム、ツールチェーン、理由、担当者、およびレビュー日を記録します。クロスコンパイルターゲットは、リンカーと sysroot の記録を別々に保持します。リリース前には、意図的な lint、1 つの依存関係のアップグレード、および 1 つのツールチェーンのアップグレードを使用して、終了コード、完全なログ、キャッシュの挙動、および例外の有効期限を検証します。これにより、未知の出力を隠すことなく、説明責任のある新しいリグレッションをブロックするポリシーが実現します。」
よくある間違い
- 間違い: グローバルに
RUSTFLAGS=-Dwarningsを設定する。 → なぜ失敗するか: コンパイラ、ビルドスクリプト、および依存関係の境界が混ざり合い、アップグレードによって無関係な出力が原因不明のビルド失敗に変わる可能性があるため。 → 修正方法: Cargo のローカルパッケージ警告ポリシーを使用し、依存関係とリンカーを個別に追跡する。 - 間違い: すべての赤い行を消すために
allowを使用する。 → なぜ失敗するか: 調整可能な lint、コンパイルエラー、および lint 以外のリンカー stderr は異なるシグナルであるため。 → 修正方法: 検証済みの lint またはメッセージのみを許可し、生のログを保持する。 - 間違い:
--keep-goingを成功とみなす。 → なぜ失敗するか: 結果を収集するだけであり、エラーのあるビルドを成功に変えるわけではないため。 → 修正方法: 最終的な終了コードを確認し、レポートをクレートおよびターゲットごとに分類する。 - 間違い: デフォルトターゲットのみを検証する。 → なぜ失敗するか: リンカー、SDK、およびビルドスクリプトはプラットフォームごとに異なるため。 → 修正方法: リリース対象のターゲットごとに独立したベースラインとアップグレード訓練を構築する。
フォローアップの質問と回答
依存クレートがリリースログを警告で埋め尽くす場合はどうしますか？
非表示にするのではなく、クレート、バージョン、ターゲットごとに集約します。警告がアップストリームで修正された場合は、元に戻せるアップグレードをスケジュールします。アップグレードを待つ必要がある場合は、バージョン範囲とリスク担当者を記録し、リポジトリの lint と依存関係の監視を分離しておきます。依存関係が定められたリリースの安全ゲートに違反した場合にのみブロックします。
すべてを RUSTFLAGS=-Dwarnings で処理しないのはなぜですか？
グローバルな rustflags はビルドスクリプト、手続き型マクロ、およびターゲット選択に影響を与え、境界の説明を難しくし、クロスプラットフォームの動作やキャッシュキーを変更する可能性があるためです。Cargo の build.warnings はより限定的なルールを定めています。CI はローカルパッケージからの調整可能な lint をブロックし、その他の出力は独自の監査パスに従います。
あるターゲットのリンカー警告がビルドごとに変わる場合はどうしますか？
まずツールチェーン、リンカー、SDK、およびビルド環境を固定し、生の stderr を比較します。メッセージが安定しており無害である場合は、レビュー日を設定してそのターゲットに対して許可します。テキストが変更されたり、リンク失敗と共に出現したりする場合は、例外を削除してツールチェーンまたはビルド設定を修正します。