新しいアナライザー抑制メカニズム

現時点では、PVS-Studioアナライザーにはすでに誤検知を抑制するメカニズム（False Positive）があります。 このメカニズムは、機能的な観点から私たちに完全に適合しています。 彼の作品の信頼性について不満はありません。 ただし、一部のユーザーとクライアントは、「新しい」メッセージのみでアナライザーメッセージを操作できるようにしたいと考えていました。 新しく書かれたコード。 大規模なプロジェクトでは、アナライザーが既存のコードに対して数千または数万のメッセージを生成する可能性があり、もちろん編集されないことを考えると、この要望は完全に理解できます。



何らかの意味でメッセージを「偽」としてマークアップする可能性は、「新しい」メッセージでのみ動作するという欲求と交差します。 理論的には、見つかったすべてのメッセージを「偽」としてマークすることを妨げることはなく、将来的には新しく作成されたコードのメッセージのみを処理します。

ただし、「誤ったメッセージ」をマークアップする既存のメカニズムには、基本的なユーザビリティの問題があり（これについては後で説明します）、この問題を解決するために実際のプロジェクトで使用すると障害になる可能性があります。 特に、この既存のメカニズムは、大量のマークアップの使用を意味するものではありません。大量のマークアップは、数千のアナライザーメッセージを処理する際に避けられません。

上記の問題は既存の方法論の基本であるという事実により、同じ方法論を維持しながらそれを排除することはできません。 したがって、この問題を解決するための代替方法を実装する可能性を考慮することは理にかなっています。

誤検知を抑制するタスクと、以前の起動の結果を抑制するタスク。

ソースコードとアナライザー診断を比較するメカニズムは、ソースコードの行を特定のアナライザー診断と一致させる機能を意味します。 この場合、この接続を長期間維持することが重要です。その間、ユーザーコードとアナライザーの診断出力の両方が変更される可能性があります。

ソースコードと診断を比較するメカニズムを使用して、2つの問題を解決できます。

1. 誤検知を抑制するタスク。 ユーザーには、特別な方法で偽と見なされるアナライザーメッセージをマークする機会が与えられ、その後、そのようなメッセージをフィルターに掛けることができます（たとえば、それらを非表示にします）。 このマークアップは、ソースコードが変更された後も含め、その後のアナライザーの起動時に保持される必要があります。 この機能はPVS-Studioで長い間利用されてきました。
2. 前回の起動の結果を抑制するタスクは、ユーザーにアナライザー起動の「新鮮な」結果のみを表示する機会を提供することです（つまり、以前の起動ですでに見つかった結果は表示されません）。 このタスクは、以前はPVS-Studioに実装されていなかったため、記事の次のセクションで説明します。

PVS-Studioには、ソースコード内のマーカー（特別な種類のコメント）に基づいて、ソースコードと診断を一致させるメカニズムがあります。 このメカニズムは、アナライザーコアレベル（PVS-Studio.exe）およびIDEプラグインで実装されます。 IDEプラグインは、コード内のマーカーの初期配置を実行し、このマーカーによって分析結果をフィルター処理することもできます。 アナライザーコアは、コードに既に存在するマーカーを「ピックアップ」してその出力にマークを付けることができます。これにより、以前の起動からのコードのマークアップが保持されます。

既存のメカニズムの長所と短所を考慮してください。

利点：

• 簡単なカーネルとプラグインの実装
• ツールのユーザーの直感的な使用、手動でマークアップする機能。
• ユーザーによるコードのその後の変更に対する接続「コード-診断」の保存を保証します。
• チーム開発の「無料」サポート-as マーカーはソースファイルに格納されます。ファイル自体の同期と同じシステムを使用してマーカーを同期できます（バージョン管理システムなど）

欠点

• このコードのロジックに関連しない特別なコメントでコードを詰まらせます。
• 問題は、バージョン管理システムを使用する場合、特別な種類のコメントをリポジトリに配置する必要があることです。
• グローバルマスマークアップでのソースコードの破損の可能性。

上記の問題により、既存のマッチングメカニズムを使用して以前の起動の結果を抑制するタスクを実装することは、実用的な観点から不可能になります。 既存のコードベース上のメッセージの「質量」マークアップ用。

つまり、既存のメッセージを圧倒するコードに20,000のコメントを追加し、これらの変更をすべて見ずにバージョン管理システムに入れたいと思う人はいません。

メッセージデータベースファイルに基づくソースコードと診断を一致させるための新しいメカニズム。

前に示したように、既存のメカニズムの主な問題は、ユーザーのソースコードを変更するというコミットメントです。 この事実から、このアプローチの流れに特徴的な疑い​​の余地のない利点とマイナスの両方があります。 代替アプローチを実装するためには、ユーザーコードの変更を中止し、リンク「アナライザー診断-ユーザーコード」に関する情報をソースファイル自体ではなく、外部ストレージに保存する必要があることが明らかになります。

このような比較のマークアップの長期保存は、アナライザー自体の診断とユーザーのソースコードの両方で、長期間にわたる変更を考慮する基本的なタスクです。 アナライザー出力での診断の消失は根本的な問題ではありません。そのような診断のメッセージはすでにfalse /不必要とマークされているためです。 ただし、ユーザーコードの変更により、以前にマークアップされたメッセージの「再来」が発生する可能性があります。

コードマークアップメカニズムを使用する場合、この問題は恐ろしくありません。 コードセクションがいくら変更されても、ユーザーが（意図的な決定または無知によって）それを削除するまでマーカーは残ります。 さらに、経験豊富なユーザーは、アナライザーがここで誓うことを知っている場合、そのようなマーカーを新しい（または変更された）コードに追加できます。

アナライザーの診断メッセージを正確に識別するには何が必要ですか？ アナライザーメッセージ自体には、ファイル名、プロジェクト、ファイル内の行番号、およびこれらの診断が見つかった前、現在、および後続のコード行のチェックサムが含まれています。 ソースコードを変更するときの診断を比較するには、行番号を考慮しないことが絶対に必要です。 予期せず、文書のわずかな変更で変更されます。

上記の診断「リンク」のストレージをユーザーコードで実装するために、ローカルの「データベースファイル」を作成するパスに沿って進みました。 このようなファイル（抑制拡張子のファイル）はプロジェクトファイル（vcproj \ vcxproj）の隣に作成され、マークされた「不要な」診断のリストが含まれます。 診断は行番号なしで保存され、これらの診断が識別されたファイルへのパスは、プロジェクトファイルに関連する相対形式で保存されます。 これにより、プロジェクトが別の場所に展開されている場合でも（ファイルシステムの観点から）、開発者のマシン間でこのようなファイルを転送できます。 ほとんどの場合、プロジェクトファイル自体は同じ相対形式でソースファイルへのパスを保存するため、これらのファイルはバージョン管理システムに保存できます。 ここでの例外は、CMakeの場合のように生成されたプロジェクトファイルです。たとえば、「ソースツリー」は「プロジェクトツリー」とは独立して配置できます。

次のフィールドを使用して、抑制ファイル内のメッセージを識別しました。

• アナライザーの診断メッセージのテキスト。
• メッセージエラーコード。
• メッセージが見つかったファイルの相対名。
• メッセージが見つかったコードを含む行と、コードの前後の行の合計のハッシュ。

ご覧のように、ソースコードの行の合計のハッシュが格納されているため、アナライザーメッセージをユーザーコードと関連付けたいと考えています。 同時に、ユーザーコードが「シフト」された場合、アナライザーメッセージもシフトしますが、このメッセージの「コンテキスト」（つまり、それを囲むコード）は変更されません。 ユーザーがメッセージが生成された場所でコードを修正した場合、そのようなコードを「新規」とみなし、アナライザーメッセージをこのコードに表示することは論理的です。 同時に、アナライザーがメッセージで指摘したエラーをユーザーが本当に「修正」した場合、メッセージは単に「消失」します。 それ以外の場合、疑わしい場所が修正されない場合、ユーザーには再びアナライザーメッセージが表示されます。

ユーザーファイル内のコード行のハッシュに依存することにより、多くの制限が発生することは明らかです。 たとえば、ユーザーがファイル内に複数の同一のコード行を持っている場合、そのうちの1行だけがマークされていても、そのような行のすべてのメッセージは抑制されていると見なします。 説明した方法論を使用するときに遭遇した問題と制限についての詳細は、次のセクションで説明します。

PVS-Studio IDEプラグインは、メッセージの最初のマークアップで抑止ファイルを自動的に作成し、新しく生成されたすべての診断を抑止データベースに含まれる診断と比較します。 また、再確認後にデータベースで新しく生成されたメッセージが識別された場合、ユーザーには表示されません。

新しい抑制メカニズムの使用に関する統計

新しいメカニズムの最初の実行可能なプロトタイプを実装した後、実際のプロジェクトで作業するときにこのメカニズムがどのように表示されるかを自然に見たかったのです。 そのようなプロジェクトで十分な数の変更が蓄積されるまで数ヶ月から数年待たずに、いくつかの大規模なオープンソースプロジェクトで過去の修正をいくつか行いました。

何を見たかった？ プロジェクトのかなり古いリビジョン（開発者の活動に応じて、1週間または1年になる可能性があります）を取り、アナライザーで確認し、受信したすべてのメッセージを非表示データベースに入れました。 その後、プロジェクトは最新のヘッドリビジョンに更新され、アナライザーによって再度チェックされました。 理想的には、「新しい」コードでのみ見つかったメッセージが表示されるはずです。 検討中の期間に作成されたコード。

最初のプロジェクトをチェックするときに、方法論の多くの問題と制限に遭遇しました。 それらをより詳細に検討しましょう。

まず、原則として、メッセージ自体が発行された場所、または前/次の行でコードが変更された場合に、メッセージが「再表示」されることを想定していました。 さらに、メッセージ自体の行の変更が、予想どおり、そのようなメッセージの「復活」につながった場合、周囲の行の変​​更は、一見、これにつながるべきではありません。 これは、特に、選択した手法の主な制限の1つです。これら3行でソースファイルのテキストに添付されます。 さらに、1行だけに添付するのは不便に思えます-あまりにも多くのメッセージが「混同」される可能性があります。 後で提供されるプロジェクトの統計では、このようなメッセージを「ペア」として指定します。 メッセージは、すでに抑制ベースにありますが、再び表示されます。

次に、新しいメカニズムの別の機能（または、別の制限）が明らかになりました。これらのファイルが他のプロジェクトの他のソースファイルに含まれていた場合のh（ヘッダー）ファイルのメッセージの「復活」です。 この制限は、データベースがプロジェクトIDEレベルで生成されるという事実によるものです。 同様の状況は、ヘッダー/ソースファイルを再利用するソリューションの新しいプロジェクトの場合にも発生します。

さらに、アナライザーメッセージのテキストに焦点を合わせてデータベース内のそのようなメッセージを特定することは良い考えではないことが判明しました。 アナライザーメッセージのテキストには、ソースコードの行番号（シフトの場合に変化する）およびユーザーコードに表示される変数の名前が含まれることがあります。 不完全なアナライザーメッセージをデータベースに保存することにより、この問題を解決しました-すべてのデジタル文字が切り取られます。 しかし、変数の名前を変更するときにメッセージの「復活」を考慮することにしました。名前だけでなく、定義も変更される可能性があるため、これを「新しい」コードと見なします。

最後に、いくつかのメッセージが「移行」されました-コードが他のファイルにコピーされたか、ファイルが他のプロジェクトに含まれていたため、原則として、最初に説明した方法論の問題と交差します。

新しいシステムをテストしたいくつかのプロジェクトの統計をリストします。 多数の診断メッセージは、すべてのメッセージが考慮されたという事実によって引き起こされます。 残念ながら一般的に多くの誤検知を生成する64ビットエラーの診断を含め、それについては何もできません。

1. LLVMは、プログラムの分析、変換、最適化の普遍的なシステムのための大規模なプロジェクトです。 このプロジェクトは数年にわたって積極的に開発されてきたため、わずか1.5か月で変更のダイナミクスを取得して、多数のコード変更を取得するのに十分でした。 有名なClangコンパイラはこのプロジェクトの一部です。 1600-1800プロジェクトファイルの場合、52,000のメッセージが不要としてマークされました。 1.5か月後、18,000個の新しいアナライザーメッセージが検出されました。そのうち500ペアのメッセージと500メッセージが他のファイルに移行しました。
2. Mirandaは、Windows用の有名なメッセージングプログラムです。 Mirandaには最初のリリース以来11のバージョンがあります。 最新のMiranda IMを取りました。 残念ながら、ミランダ開発チームの競合により、このバージョンはあまり頻繁に変更されませんでした。最大2年の間隔で変更を行う必要がありました。 700ファイルの場合、51,000のメッセージが不要とマークされました。 2年後、41の新しい投稿のみが表示されました。
3. ffdShowは、ビデオストリームの高速かつ高精度のデコードに一般的に使用されるメディアデコーダーです。 ffdShowはかなり完成したプロジェクトです。執筆時点では、最新リリースは2013年4月でした。 変化のダイナミクスを1年間取りました。 570個のファイルのうち、21,000個のメッセージが迷惑メールとしてマークされました。 1年後、120の新しい投稿が登場しました。
4. Torque3Dはゲームエンジンです。 現在、プロジェクトは実際には開発されていませんが、最初はすべてが異なっていました。 執筆時点での最新リリースは2007年5月1日でした。 活発な開発の時点で、1週間の間隔での変化のダイナミクスは43,259のメッセージを発行しました。 この期間中に、222の新しいものが登場しました。
5. OpenCVは、コンピュータービジョン、画像処理、汎用数値アルゴリズムのアルゴリズムのライブラリです。 かなり動的なプロジェクト。 変更のダイナミクスを2か月と1年の間取りました。 50948のジャンクメッセージにフラグが付けられました。 これらのうち、2か月後の1174件の新しいメッセージと1年後の19471件の新しいメッセージ。

結果からどのような結論を導き出すことができますか？

活発に開発されていないプロジェクトでは、1年ほどの長い期間であっても、多数の「新しい」メッセージが表示されないことが予想されます。 そのようなプロジェクトでは、「ペア」に移行されたメッセージの数を考慮しなかったことに注意してください。

しかし、もちろん、私たちにとって最大の関心は「生きているプロジェクト」です。 特に、LLVMの例を使用すると、「新しい」メッセージの数は、バージョンでタグ付けされたメッセージの34％であり、わずか1.5か月遅れていることがわかります。 ただし、これらの18,000の新しいメッセージのうち、1000（移行された500 + 500ペア）のみが、方法論の制限に属します。 新しい投稿の総数のわずか5％。

私たちの意見では、これらの数値は新しいメカニズムの実行可能性を非常によく実証しました。 もちろん、新しい抑制メカニズムは決して「万能薬」ではないことを覚えておく価値がありますが、抑制/フィルタリングの既存の多くの方法を使用する機能をキャンセルすることはできません。 たとえば、hファイル内のメッセージが頻繁に「ポップアップ」し始めた場合、行に//-Vxxxのようなコメントを追加することで、メッセージを永久に「殺す」ことに何の問題もありません。

新しいメカニズムは既に完全にデバッグされているという事実にもかかわらず、次のリリースでユーザーに公開する準備ができていますが、LLVM / Clangプロジェクトの定期的な（毎晩の）チェックを整理してテストを続行することにしました。 新しいメカニズムにより、「新鮮な」プロジェクトコードからのメッセージのみを見ることができます-理論的には、開発者が発見する前であってもエラーを見つけることができます。 これは、静的解析を定期的に使用することの本当のメリットを非常によく示しています。毎日50,000を表示するのは非現実的であるため、これは新しい抑制システムなしでは不可能です。 ツイッターでClangで見つかった新しいバグの報告をお待ちください。