One of the main problems when using a static analyzer is the necessity to spend much time on analyzing project files after each project modification. It is especially relevant to large projects that are actively developing.
Total analysis can be launched regularly in separate cases - for instance, once a day during night builds. But the greatest effect of using the analyzer can be achieved only through earlier detection and fix of found defects. The earlier you can find an error, the less amount of code you will have to fix. That is, the most proper way to use a static analyzer is to analyze a new code right after it is written. Having to launch analysis of all the modified files manually and waiting for it to finish each time surely complicates this scheme. It is incompatible with the intense development and debugging of new code. It's just inconvenient, after all. But PVS-Studio offers a solution of this issue.
The main task, solved when using incremental analysis is the analyzer run automation on the developer's machine immediately after the code is compiled. This mode virtually makes PVS-Studio similar to the '/analyze' switch in certain Visual Studio versions regarding usability. It also provides you with a more convenient interface and use cases. Now you can just work on your code, compile it and get messages from time to time about possible issues. Since the analyzer works in background (you can set the number of processor cores to perform analysis using the 'ThreadCount' option), PVS-Studio doesn't interfere with work of other programs. And it means that you can easily install the tool on computers of many (or all) developers in your department to detect issues in the code right after they appear.
You can turn on the afterbuild incremental analysis in the PVS-Studio menu: "PVS-Studio -> Analysis after Build (Modified Files Only)" (Figure 1). This option is on by default.
Figure 1 — Managing PVS-Studio's incremental analysis mode
Once the incremental analysis option is enabled, PVS-Studio will automatically perform background analysis of all the modified files after building the project. If PVS-Studio detects such modifications, incremental analysis will be launched automatically, and an animated PVS-Studio icon will appear in the notification area (Figure 2). Note that new icons may be often hidden in Windows's notification area.
Figure 2 — PVS-Studio performing incremental analysis
The notification area's shortcut menu allows you to pause or abort current check (commands 'Pause' and 'Abort' respectively).
If the analyzer detects errors in code while performing incremental analysis, the number of detected errors will be shown in the title of the PVS-Studio's window tab in background. Clicking on the icon in the notification area (or the window itself) opens the PVS-Studio Output window where you can start handling the errors.
Figure 3 – The result of incremental analysis: 15 suspect fragments of code are found
Keep in mind that after the first total check of your project you should review all the diagnostic messages for the required files and fix the errors found in your code. Regarding the rest messages, you should either mark them as false positives or disable those messages or analyzer types which are not relevant to your project. This approach will allow you to get a message list clear of meaningless and unnecessary messages.
Working from the IDE there is a possibility to set a limit on the work of the incremental analysis. This setting can be configured in the setting menu of PVS-Studio in the 'Specific Analyzer Settings' ('IncrementalAnalysisTimeout').
Upon the timeout efflux, the file analysis will be aborted and all the found warnings will be displayed in PVS-Studio output window. Additionally, there will be issued a warning that the analyzer didn't have time to process all the modified files and the information about the total and analyzed number of files.
To determine the presence of modifications in the source code files, PVS-Studio controls the state of object files (obj/o files), generated by the C++ compiler for every C/C++ file, or the state of assemblies for C# projects. Before the actual build in the environment, the PVS-Studio plugin for Visual Studio captures the object files and their modifications for all the compilable files of the project. To determine the modified files in the C/C++ projects, which require incremental analysis, the analyzer uses MSBuild tools to work with the file tracking logs (*.tlog files). This approach, firstly, enables us to obtain modified files to be analyzed incrementally, in the same way as MSBuild does, and secondly, eliminates the need to make the correspondence between the header files and the source code. The file tracking logs aren't created for C# projects. That's why, to determine the files which require the incremental analysis, the plugin makes the correspondence between the source code and the binary assembly file, which is the result of the project compilation and captures those files that were modified after the assembly was built. After the build, the incremental analysis starts automatically in the background mode.
The incremental analysis mode for Visual Studio solutions is also available in the command line module (PVS-Studio_Cmd.exe). This mode allows increasing the speed of the static analysis on the continuous integration server. Consider the following scenario of using the static analyzer. PVS-Studio static analyzer is installed on the machines of the developers, who do the incremental analysis after the local build of the solution, and on the continuous integration server, where the static analysis is performed for the whole code during the night build. Suppose, that also the system of continuous integration is configured for the automatic incremental build of the solution after the changes get detected in the version control system. In other words, the build of the solution on the continuous integration server occurs several times a day. In this case, performing the static analysis of the whole code will significantly increase the build time, which will make the use of static analysis during numerous daily builds almost impossible. Then we may have a situation when a developer makes an error in the code and commits it to the version control system without checking the code with the static code analyzer; the same say the build goes to the testers who detect this defect. In this case, the cost of eliminating this defect goes up. The incremental analysis mode that implements the approaches similar to the approaches of MSBuild for the incremental build, allows to solve this problem.
There are following modes of incremental analysis available:
The arguments of the command line module (PVS-Studio_Cmd.exe) to start the incremental analysis are given in the section "Analyzing Visual C++ (.vcxproj) and Visual C# (.csproj) projects from the command line".
In case of necessity of performing the incremental analysis when using the Compiler Monitoring system, it is enough to "monitor" the incremental build, i.e. the compilation of the files that have been changed since the last build. This way of usage will allow to analyze only the modified/newly written code.
Such a scenario is natural for the Compiler Monitoring system, as it is based on the "monitoring" compiler runs during the project build, which helps to get all needed information for the analysis run on source files, compilation of which has been monitored. Consequently, analysis modes depend on the build that is monitored - full or incremental.
Compiler Monitoring system is described in more detail in the article "Compiler Monitoring System in PVS-Studio".
As it was noted at the beginning of the article, fixing the bug is cheaper when it is found at the early stage of writing the code. To perform this task (the earliest detection of defects in code) the mechanism for incremental analysis is designed, as it was described previously. However, someone might think that only incremental analysis is enough to detect potential errors in your code because they will be detected directly in the development process. This statement is wrong.
There are various reasons why a developer might provide the erroneous code under version control system: incremental analysis has been disabled on this machine, he did not wait for the results of the analysis, did not notice notifications, etc. As a result, the error gets into a version control system, and how quickly it will get fixed it is an open question (for example, another developer who discovered the same error, cannot do anything, because it is not his code).
From the above situations, there is an important conclusion - static analysis should be divided into several phases that will detect errors which somehow passed the previous phase.
The optimal scenario for using PVS-Studio analyzer is applying the analyzer both locally on developers' machines and on a build server. This way there is a two-phase system of analysis.
The first phase is static analysis directly when developing. For this phase, incremental analysis is ideal, which enables to analyze the code the developer is working with. Most of the bugs (ideally all) are made by the developer, must be fixed at this stage, before getting into the version control system.
The second phase - static analysis on a build server. Full analysis on a build server should be implemented regularly, as this will help to identify those bugs that for whatever reasons were set out in a version control system, and as a result, timely fix them. You can also configure additional actions, such as sending mails with the analysis results to the persons concerned; publish analyzer reports in CI systems, etc.
If necessary, you can also enter an intermediate phase, which will run between the two described - incremental analysis on the build server. When configured properly, this will help to detect errors got into version control system, before conducting static analysis during the night build.
In more detail, the process of configuration for a build server is described in the article "Integrating PVS-Studio into the Continuous Integration Process".