トラブルシューティング

よくある問題とその解決策。エディタ固有の問題についてはエディタ統合を、「なぜこの診断が（発火しな）かったのか」についてはハンドブック第8章を参照してください。

症状から探す command not found · checkが何も解析しない · すべてがuntyped · 診断が多すぎる · 診断が誤っている · 結果が古く見える · 実行が遅い · バグの報告

rigor: command not found

RigorはインストールされているがPATH上にありません。バージョンマネージャーを使用している場合、通常はシェルが有効化されていないことを意味します——Rigorのインストールを参照してください。応急処置としてmise exec gem:rigortype -- rigor …で明示的に実行できます。

rigor checkが何も解析しない

コマンドラインでパスが指定されない場合、Rigorは設定ファイルのpaths:を解析します。paths:が間違っているか、設定ファイルが見つからない場合、実行は空になります。プロジェクトルートに.rigor.ymlまたは.rigor.dist.ymlがあることを確認するか、明示的にパスを指定してください: rigor check lib app。

すべてがuntyped / Dynamic[Top]になる

Rigorは問題のコードに対する型情報を持っていません。よくある原因:

• gemがRBSを同梱していない。rbs collection installでシグネチャをインストールするか、dependencies.source_inferenceを有効にします（設定を参照）。
• フレームワークにプラグインが必要。Rails、RSpec、dry-rbなどはプラグインを通じてのみRigorに認識されます。
• プロジェクトのモンキーパッチが見えない。パッチを当てるファイルをpre_eval:の下に列挙して、Rigorが先に走査できるようにします。

rigor type-of FILE:LINE:COLはある時点での正確な型を報告するため、情報が失われている場所を絞り込めます。

対処できないほど多くの診断が出る

大規模な型なしプロジェクトへの最初の実行では、数百の診断が報告されることがあります。一つずつ抑制することから始めないでください:

1. rigor triage — どのルールとファイルが支配的か、考えられる原因のヒントとともに確認する。
2. triageが指摘する体系的な原因を修正する——欠けているプラグイン、欠けているRBSバンドル。
3. rigor baseline generate — 残りをスナップショットしてCIが新しい診断のみを追跡するようにする。ベースライン（baseline）を参照。

rigor-project-initスキルがこの手順を自動化します。

診断が誤っている（偽陽性）

Rigorは動作するコードにフラグを立てないことを目指しているため、真の偽陽性は報告する価値のあるバグです。それまでの間、# rigor:disable <rule>コメントで単一のサイトを抑制してください（診断を参照）——実際のインスタンスも隠してしまうプロジェクト全体のdisable:より優先します。

診断が正しいが修正する準備ができていない場合、ベースラインが適切なツールです。

結果が古く見える

そうなるべきではありません——キャッシュエントリーはコンテンツをキーとして自己無効化します（キャッシュを参照）。それでもキャッシュを疑う場合は、rigor check --clear-cacheで除外できます。クリアされたキャッシュでも残る結果は、キャッシュのアーティファクトではなくアナライザーの本来の動作です。

実行が遅い

• キャッシュをウォームアップしてください——最初の実行が最も遅いものです。
• paths:を狭め、exclude:を広げて、Rigorが生成されたまたはベンダーされたコードを走査しないようにします。
• 大きなプロジェクトでは、rigor check --workers=Nでファイルごとの解析を並列ワーカープロセスに分散します。

バグの報告

Rigorバージョン（rigor version）、実行したコマンド、最小限の再現手順、および偽陽性が疑われる場合はRigorに推論してほしかったものを添えてGitHub issueを開いてください。