概要

このproposalは、go test が go.vet ファイルで指定されたアナライザ（静的解析器、リンターとも呼ばれます）を実行できるようにする開発中の機能を、フラグで有効化したときだけ動くようにするものです。対象の機能は別のproposal（#82464）で提案されています。そちらがまだ採否未定のため、既存の動作は変えずに、試したい人だけが試せる状態にすることが目的です。

ステータス変更

（新規） → likely_accept
2026年11月11日のProposal Review Meetingで、@aclements が次の点を整理しました。

• このフラグは、古い動作を残すための本来の意味の「互換性GODEBUG」ではありません。
• cmd/go のビルド時に設定するGOEXPERIMENTにすると、使い勝手が明らかに悪くなります。
• GOEXPERIMENTを go コマンドの実行時に参照する方式には前例がありそうです。
  この整理を踏まえて、次の結論でlikely acceptとなりました。
• 第一案: GOEXPERIMENT=vetfiles を go コマンドの実行時に参照して有効化する。
• 代替案: 実行時のGOEXPERIMENTが技術的に使えない場合は GODEBUG=vetfiles を使う。初期値は0とし、将来のリリースで1に変え、その2年後に削除する。
  タイトルにはGODEBUGとありますが、実際に優先されるのはGOEXPERIMENTの案です。なお、フラグ名は10月31日に goanalysis から vetfiles に変更されています。

技術的背景

現状の問題点

現在の go test は、go vet のアナライザのうち一部だけを固定で実行します。この一覧はツールに組み込まれているため、対象は公開された汎用的なアナライザに限られます。その結果、次のようなチェックは go test の中で動かせません。

• 自分のコードベースの約束事を守らせるためのアナライザ（「housekeeping」）
• 自作ライブラリの利用者がAPIを正しく使えているかを確かめるアナライザ（printf アナライザが fmt.Printf の呼び出しを検査するのと同じ発想です）
  こうしたチェックは、CIの段階で初めて実行されることが多いのが実情です。

提案された解決策

#82464 で提案されている主な変更は次のとおりです。

• go.vet ファイルの導入: モジュール内の任意のディレクトリに置けて、go.mod と同じパーサーで読み込まれます。
• go test の動作変更: go.vet で指定されたアナライザをその場でリンクして解析ツールを生成し、テストの前に実行します。診断が報告されるとテストは失敗します。
  この仕組みを支えるために、#82465 ではアナライザAPIの型を標準ライブラリの新パッケージ go/analysis として公開することが提案されています。
  本proposalは、これらの新しいインターフェースと動作変更のすべてを vetfiles フラグの裏側に置くというものです。
• #82464 が承認された場合は、フラグを有効にしたうえで削除します。
• 却下された場合は、フラグと、その裏にあるコードをすべて削除します。

これによって何ができるようになるか

本体のproposalが決まる前でも、関心のある開発者が実際の動作を試してフィードバックを返せるようになります。新しいインターフェースが確定してしまうことはありません。想定される用途は次のとおりです。

• 社内コードベースの規約チェック: go test の実行中にローカルで強制できます。
• ライブラリ作者による誤用検出: 自作のアナライザを importers スコープで配布し、そのパッケージをインポートする側のコードを検査できます。
• フィードバックの早期化: 人間の開発者もコーディングエージェントも、編集とテストを繰り返すループの中で、CIを待たずに問題に気付けます。
• 設計の検証: 性能の測定や設計上の問題の洗い出しを、プロトタイプで進められます。設計ドキュメントの性能測定も GODEBUG=vetfiles=1 で行われています。

コード例

# Before: go test は組み込みの vet サブセットのみ実行
$ go test ./...
# After: フラグを有効化すると go.vet に記載したアナライザも実行される
# （GOEXPERIMENT が使えない場合は GODEBUG=vetfiles=1）
$ GOEXPERIMENT=vetfiles go test ./...

// go.vet（設計ドキュメントの例を組み合わせたもの）
// ./... 配下の全パッケージで Housekeeping スイートを有効化
enable ./...     example.com/db/internal/check.Housekeeping[*]
// このパッケージをインポートする側のコードで SQLQuery を有効化
enable importers example.com/db/internal/check.SQLQuery
// バグがある、または遅いチェックを無効化
disable ./... example.com/db/internal/check.Housekeeping[buggy,slow]

議論のハイライト

• GODEBUGが本来の用途に合わない点: GODEBUGは通常、互換性のために古い動作を残す仕組みです。新機能を試験的に有効化する今回の用途とは性質が違うことが指摘されました。
• ビルド時GOEXPERIMENTは不採用: cmd/go を再ビルドしないと試せないため、使い勝手の面で採用されませんでした。
• 実行時GOEXPERIMENTを優先: go コマンドが実行時にGOEXPERIMENTを参照する前例があると考えられることから、この方式が第一案になりました。実現できない場合に限りGODEBUGに切り替えます。
• GODEBUG案の段階的な移行計画: 初期値は0、将来のリリースで1に変更、その2年後に削除という流れが明示されました。
• 完全に元に戻せる実験: 本体の #82464 が却下されれば、関連コードはすべて削除される前提です。関連する #82465（go/analysis パッケージの公開）も同様に、実験フラグの裏で進める方針が示されています。