Why did you need a static analyzer message suppression system
Each software product has its own history of origin and development. A project can be small or new, or be commercially successful for decades and have thousands of source files. When introducing a static analyzer, in addition to the technical issue of integration into the project, other important questions arise: how to properly process the analysis results? Is it worth editing all analyzer warnings? ... This article will talk about a new way to process the results of static analyzers.
The role of the standard static code analyzer is performed by the compiler used. A small number of its diagnostic rules cover only the most common cases of suspicious code writing, almost all of which are not just recommended to be fixed, but are mandatory for correction in many companies.
Nevertheless, there are not many compiler messages generated, among which it will not be difficult to see a new warning and, if necessary, fix it. Specialized static analyzers have many diagnostic rules, and even on small projects they can generate a huge number of warnings.
A third-party static code analyzer is not a tool for which all warnings need to be fixed. Some diagnostic rules are based on heuristic methods and often give false positives. Some suspicious places may be a special idea of the programmer, writing code had its own reasons and it is not planned to fix this place.
Disabling these diagnostic rules is not a good solution. Using them, you can detect errors that are extremely difficult to notice when reviewing the code. And, despite the false positives, a real error may appear in the future. The question then becomes how to skip some warnings and see only new ones.
In such situations, you can use warning suppression by writing the appropriate comment at the end of the line so that the analyzer skips this place. But this method often causes distrust, since it involves automatic markup of a large amount of source code, and manual markup in large projects is out of the question.
Thus, it required the ability to suppress messages from static code analyzers on large projects. It was necessary to highlight new warnings among all, based only on previous runs of the analyzer.
One diagnostic message contains the following information: the name of the diagnostic, the type and level of warning, an explanatory message, the name of the checked file, the line number of the file, and the hash of several lines.
To compare warnings when changing the source code, it is necessary to take into account all the parameters of the diagnostic message, with the exception of the line number, because it changes unpredictably and at the slightest modification of the file.
In the PVS-Studio static analyzer, the use of this functionality is implemented in the form of the “Analyzer Message Suppression” dialog box (Fig. 1).
Figure 1 - Alert suppression control dialog box
The “Suppress Current Messages” button performs initial marking of analyzer messages and saves the result to local * .suppress files. After that, during subsequent checks of the source code, the received messages will be compared with messages from these files and only new warnings will be displayed in the output window of the PVS-Studio plug-in IDE (Fig. 2).
Figure 2 - Several new analyzer warnings
The “Display Suppressed Messages in PVS-Studio Output Window” checkbox in Figure 1 allows you to enable the display in the PVS-Studio output window and filtered messages, the status of which can be changed if necessary (Fig. 3).
Figure 3 - All analyzer warnings
The new mechanism implemented in the PVS-Studio static analyzer is an addition to the existing way of marking up comments with source code. If a false warning indicates a line in the header file, which is included in many source files and various projects, then it is better to mark this place once with a comment. Thanks to these features, regular use of static analysis becomes more convenient to use.