Filtering and handling the analyzer output through diagnostic configuration files (.pvsconfig)

• How to add/use configuration files in IDE and other analysis tools
  • .pvsconfig in Visual Studio
  • .pvsconfig in CLion
  • .pvsconfig in Rider
  • .pvsconfig in PVS-Studio_Cmd.exe and pvs-studio-dotnet
  • .pvsconfig in CLMonitor.exe
  • .pvsconfig in CompilerCommandsAnalyzer.exe
  • .pvsconfig in Standalone.exe
  • The use of the global .pvsconfig file
• General functionality of configuration files
  • Adding entries to the configuration file
  • Filtering the analyzer messages
  • Excluding files from the analysis
  • Excluding projects from analysis
  • Ignoring configuration files
  • Isolating settings for directories
  • Ignoring global configuration files
  • Specifying the file analysis timeout for a project/solution/system
  • Changing a certainty level of a diagnostic warning
  • Changing the text of the analyzer messages
  • Manage synchronization of suppress files
  • Selecting the PVS-Studio C++ core version for analysis
  • Configuration files prioritization
  • Executing commands from the CustomBuild task before running the analysis
  • Suppressing parsing errors
  • Ignoring analysis settings from Settings.xml
  • Using the solution directory as the SourceTreeRoot value
  • Using the solution directory to create relative paths in the compilation dependency cache
  • Managing sorting of suppress files
  • Settings sections in .pvsconfig
  • The output of initial position of the shifted line (for V002)
  • Configuring the compilation dependency cache
  • Dependency cache source file tracking mode

A configuration file is used to display and filter analyzer messages. The configuration file also allows you to set additional parameters for the analysis. You can use configuration files only for projects written in C, C++ or C#.

Plugins for the following IDEs support configuration files:

• Visual Studio;
• Rider.

Utilities that support configuration files:

• PVS-Studio_Cmd.exe;
• CLMonitor.exe (only in analyze or analyzeFromDump mode);
• C and C++ Compiler Monitoring UI (Standalone.exe);
• CompileCommandsAnalyzer.exe (in analyze mode).

How to add/use configuration files in IDE and other analysis tools

.pvsconfig in Visual Studio

To use a configuration file in Visual Studio, add the file at the project or solution level. Choose the necessary project or solution in the Solution Explorer window inside Visual Studio IDE. Select the Add New Item... context menu item. In the window that appears, select the PVS-Studio Filters File file type.

You can add multiple configuration files for each project/solution.

Configuration files added at the project level apply to all files in a given project. Configuration files added at the solution level apply to all files of all projects in a given solution.

.pvsconfig in CLion

There is no special template for adding a configuration file for CLion.

You can add a configuration file for CLion only at the project level. To use the file in CLion, add a new file with the .pvsconfig extension to the .PVS-Studio folder using the New > File context menu.

.pvsconfig in Rider

There is no special template for adding a configuration file for Rider.

You can add a configuration file for Rider only at the project level. To use the diagnostic rule configuration file in Rider, add a new file with the .pvsconfig extension to the project via Solution Explorer.

.pvsconfig in PVS-Studio_Cmd.exe and pvs-studio-dotnet

When you run analysis through PVS-Studio_Cmd.exe or pvs-studio-dotnet, the configuration files from the project or solution being analyzed are automatically used. You can also specify the path to the additional .pvsconfig file using the ‑‑rulesConfig (-C) parameter:

PVS-Studio_Cmd.exe -t ProjName.sln -C \path\to\.pvsconfig
pvs-studio-dotnet -t ProjName.sln -C /path/to/.pvsconfig

In this case, the settings both from the files in the project/solution and the file passed as an argument are taken into account in the analysis.

.pvsconfig in CLMonitor.exe

You can specify the path to the configuration file as a command-line argument (the -c parameter):

CLMonitor.exe analyzeFromDump -d /path/to/compileDump.gz -c /path/to/.pvsconfig

.pvsconfig in CompilerCommandsAnalyzer.exe

If you use the CompilerCommandsAnalyzer.exe utility, you can specify the path to the .pvsconfig file via the -R parameter:

CompilerCommandsAnalyzer.exe analyze ... -R /path/to/.pvsconfig

.pvsconfig in Standalone.exe

In Standalone.exe, you can specify the path to the file when you start monitoring.

The use of the global .pvsconfig file

The global diagnostic rule configuration file is used during all project checks. There can be several global .pvsconfig configuration files and the PVS-Studio tools will use them all.

To add a global configuration file, create a file with the .pvsconfig extension in the folder:

• For Windows: %APPDATA%\PVS-Studio;
• For Linux and macOS: ~/.config/PVS-Studio.

General functionality of configuration files

Adding entries to the configuration file

To set the settings in the configuration files use special directives that start with the // characters. Each directive is written on a new line.

The example:

//-V::122
//-V::123

You can add comments — write the # character at the beginning of the line.

The example:

# I am a comment

Filtering the analyzer messages

Complete warning disabling

To completely disable a certain diagnostic rule, use the following syntax pattern:

//-V::number

number is the number of the diagnostic rule you want to turn off (for example, 3022).

The example:

//-V::3022

In this case, the V3022 warnings will be ignored.

To disable a number of diagnostic rules, you can list their numbers separating them by commas:

//-V::number1,number2,...,numberN

The example:

//-V::3022,3080

This use of this directive will completely disable V3022 and V3080 diagnostic rules.

Disabling a group of diagnostic rules

To disable diagnostic rules of a certain group, use the following directives:

//-V::GA
//-V::X64
//-V::OP
//-V::CS
//-V::MISRA
//-V::OWASP

Definition for each of the group:

• GA (General Analysis) is general analysis rule set. The main set of PVS-Studio diagnostic rules;
• OP (Optimization) is diagnostic rules of optimization. These are tips to improve the code efficiency;
• X64 (64-bit) is diagnostic rules that allow you to identify specific errors related to the development of 64-bit applications and migrating the code from a 32-bit platform to a 64-bit one;
• CS (Customers' Specific) is highly specialized diagnostic rules, developed by user requests. By default, this set of diagnostic rules is disabled;
• MISRA is the set of diagnostic rules, developed according to the MISRA standard (Motor Industry Software Reliability Association). By default, this set of diagnostic rules is disabled;
• OWASP is the set of diagnostic rules that allow you to find security issues and check code for compliance with OWASP ASVS standard. By default, this set of diagnostic rules is disabled.

You can disable several groups of diagnostics — list them separating by commas.

The example:

//-V::GA,MISRA

Disabling all C++ or C# diagnostic rules

To turn off all diagnostic rules of C++ or C# analyzer use the following directives:

//-V::C++
//-V::C#

Excluding warnings for certain diagnostic rules at specific levels

If you need to turn off warnings of a certain level, use the following syntax pattern:

//-V::number1,number2,...,numberN:level

• number1, number2, etc. are the numbers of diagnostic rules that need to be excluded from the analysis results (for example, 3022).
• level is the warning level (1, 2 or 3).

The number 1 corresponds to warnings of High level, the number 2 to the Medium level warnings, the number 3 to the Low level warnings.

You can filter out warnings of several levels at once. To do this, list the levels and separate them by commas.

The example:

//-V::3022,5623:1,3

This directive will filter out the warnings of V3022 and V5623 diagnostic rules of High and Low levels.

Excluding warnings by the substring in a message

The analyzer supports the ability to exclude warnings by the diagnostic rule number and substring contained in a message.

The syntax pattern is as follows:

//-V::number::{substring}

• number is the number of diagnostic rules which message needs to be suppressed (for example, 3080);
• substring is a substring contained in the analyzer's message.

When using this template, the analyzer will ignore the diagnostic rule with the following number and containing substring.

The syntax pattern to suppress warnings by the substring:

//-V::3022::{always true}

In this case, the V3022 warnings with the always true substring in the message will be suppressed.

Excluding warnings by the certainty level and the substring

You can filter warnings by the certainty level and the substring simultaneously. The syntax pattern is the following:

//-V::number1,number2,...,numberN:level:{substring}

• number1, number2, etc. are the numbers of diagnostic rules that need to be excluded from the analysis results (for example, 3022);
• level is the warning's level (1, 2, or 3);
• substring is a substring contained in the analyzer's message.

The number 1 corresponds to warnings of High level, the number 2 is the Medium level warnings, and the number 3 is the Low level warnings.

You can filter out warnings of several levels at once. To do this, list the levels and separate them by commas.

The example:

//-V::3022,5623:1,3:{always true}

This directive will filter out the warnings of V3022 and V5623 diagnostic rules of High and Low levels with the always true substring in the message.

Excluding warnings from specific groups at different levels

To exclude warnings from specific groups at different levels, use the following command:

//-V::category1,category2,...,categoryN:level

• category1, category2, etc. are the names of the groups you need to exclude (e.g. GA). For a list of groups and their descriptions, consult the Disabling a group of diagnostics section of the documentation.
• level is the warning level (1, 2, or 3).

You can combine the group and level filters by separating them with a comma.

The example:

//-V::GA,MISRA:1,3

High and Low level warnings that fall into the GA and MISRA groups will be excluded.

Enabling individual diagnostic rules

Note. This setting is only available for C, C++ and C# projects.

To enable a certain diagnostic rule, use the following syntax pattern:

//+V::number

number is the number of the diagnostic rules you want to turn on (for example, 3022).

The example:

//+V::3022

In this case, the V3022 diagnostic rule will be enabled.

To enable a number of diagnostic rules, you can list their numbers separating them by commas:

//+V::number1,number2,...,numberN

The example:

//+V::3022,3080

This use of this directive will enable V3022 and V3080 diagnostic rules.

Enabling a group of diagnostics

Note. This setting is only available for C, C++ and C# projects.

To enable diagnostic rules of a certain group, use the following directives:

//+V::GA
//+V::X64
//+V::OP
//+V::CS
//+V::MISRA
//+V::OWASP

You can enable several groups of diagnostic rules, listing them separating by commas.

The example:

//+V::GA,MISRA

Marking warnings issued for code fragment that includes the specified fragment as False Alarm

You can mark warnings issued for certain string that includes the specified fragment as False Alarm. Use the following directive:

//-V:substring:number

• substring is the substring in the string indicated by the analyzer;
• number is the number of diagnostic rules which messages need to be suppressed (for example, 3080).

Note 1. The substring you are looking for (substring) must not contain spaces.

Note 2. Messages filtered in this way will still appear in the report. They will be marked as False Alarm (FA).

The example:

public string GetNull()
{
  return null;
}

public void Foo()
{
  string nullStr = GetNull();
  Console.WriteLine(nullStr.Length);
}

For this code, the analyzer will issue a warning: "V3080 Possible null dereference. Consider inspecting 'nullStr'."

Use the following directive in .pvsconfig to add the FA mark for warnings issued on such code:

//-V:Console:3080

This directive adds a False Alarm mark to all V3080 warnings issued on the code lines containing Console.

You can also add the False Alarm mark to multiple warnings at once. To do this, list their numbers separated by commas:

//-V:substring:number1,number2,...,number

The example:

//-V:str:3080,3022,3175

The V3080, V3082, V3175 messages will be marked as False Alarm if there is the str substring in the code line indicated by the analyzer.

Appending a hash code to the False Alarm mark

With PVS-Studio version 7.28 it is now possible to appending an additional hash code to the False Alarm mark. If the line with this hash code is changes, the warnings issued for this line will not be marked as False Alarms. This is because the hash code of the changed line differs from the hash code of the mark.

This setting helps recognize situations where a string with a False Alarm mark is modified.

To enable this feature, add the following flag to the configuration file:

//V_ENABLE_FALSE_ALARMS_WITH_HASH

In the code, the False Alarm mark with hash code looks like this:

//-V817 //-VH "3652460326"

Since PVS-Studio 7.30 it is possible to suppress only those messages that have an additional hash code added to the False Alarm mark:

//V_HASH_ONLY ENABLE 
//V_HASH_ONLY ENABLE_VERBOSE

If this setting is applied, the lines that have the False Alarm mark without a hash code will not be suppressed.

The ENABLE setting will result in one V018 message for the entire project being reported. If the ENABLE_VERBOSE setting is applied, such a warning will be issued for each line of code that contains the False Alarm mark without a hash code.

The setting can be disabled as follows:

//V_HASH_ONLY DISABLE

This situation may arise if the application of this setting is required only for a certain part of code.

Excluding files from the analysis

To exclude a file or a group of files from analysis, use the directive:

//V_EXCLUDE_PATH fileMask

Several examples of masks:

//V_EXCLUDE_PATH C:\TheBestProject\thirdParty
//V_EXCLUDE_PATH *\UE4\Engine\*
//V_EXCLUDE_PATH *.autogen.cs

Starting with PVS-Studio 7.34, you can use the //V_ANALYSIS_PATHS comment with the skip-analysis mode.

The example:

//V_ANALYSIS_PATHS skip-analysis=C:\TheBestProject\thirdParty
//V_ANALYSIS_PATHS skip-analysis=*\UE4\Engine\*
//V_ANALYSIS_PATHS skip-analysis=*.autogen.cs

The process of how the masks are specified is described in the documentation.

Excluding projects from analysis

Starting with 7.32, the PVS-Studio_Cmd.exe utility and the plugin for Visual Studio support excluding projects from the analysis in the following way:

//V_EXCLUDE_PROJECT projMask

projMask is the project mask.

The example of using some masks:

//V_EXCLUDE_PROJECT C:\TheBestProject\thirdParty\3rdparty.vcxproj
//V_EXCLUDE_PROJECT *\TOCSharp.csproj
//V_EXCLUDE_PROJECT *\elsewhere\*.*proj

The mask generation syntax is the same as the syntax used to exclude files from analysis. Only .vcxproj and .csproj projects can be excluded from analysis.

You can also exclude a project from analysis by setting the same path for the //V_EXCLUDE_PATH flag.

Ignoring configuration files

Note: This setting is available only for C and C++ projects.

Starting with version 7.34, PVS-Studio enables you to ignore the settings located in the source files and diagnostic rule configuration files .pvsconfig.

To do this, you can use the //V_ANALYSIS_PATHS flag with the skip-settings mode.

The example:

//V_ANALYSIS_PATHS skip-settings=*\path\to\folder\*

If you need to exclude files from the analysis and at the same time ignore the settings for these files, you can use the //V_ANALYSIS_PATHS flag with the skip mode.

The example:

//V_ANALYSIS_PATHS skip=*\path\to\source_or_pvsconfig

Check out the documentation on the syntax for creating masks.

Isolating settings for directories

Note: This setting is available only for the pvs-studio-analyzer utility.

Starting with version 7.36, the pvs-studio-analyzer utility supports a mode that searches for configuration files of diagnostic rules (.pvsconfig) in each directory and its parent directories for every translation unit. Each found *.pvsconfig file will be applied to all translation units in the directory and its subdirectories. To enable this mode, use the ‑‑apply-pvs-configs command line flag. You can learn more about this mode in the documentation about the pvs-studio-analyzer utility.

You can isolate settings in a directory from settings in parent directories. This is useful if you need to isolate settings in subprojects or third-party libraries. In this case, no configuration files of diagnostic rules from parent directories will be applied to the specified directories and their subdirectories.

To isolate settings via the configuration files of diagnostic rules, you can use:

• The V_ANALYSIS_PATHS flag with isolate-settings mode. You can specify this option in any configuration file. Both absolute and relative paths are supported. Relative paths are expanded via the path to the configuration file of diagnostic rules, for example:

//V_ANALYSIS_PATHS isolate-settings=path/to/isolate;isolate-settings=ThirdParty

• The //V_ISOLATE_CURRENT_DIR flag. This option enables the directory isolation where the configuration file with this flag is located.

Ignoring global configuration files

Before running the analysis, PVS-Studio_Cmd generates the configuration of diagnostic rules from:

• global configuration files (in the %AppData%\PVS-Studio\' folder for Windows and in the '~/.config/PVS-Studio folder for Linux or macOS);
• the file passed through the ‑‑rulesConfig (-C) option;
• files added to the solution;
• files added to the project.

There may be a situation when the global configuration should not be applied during analysis of some projects or solutions. If you need to ignore global configuration files, add the following flag to the corresponding .pvsconfig file:

//IGNORE_GLOBAL_PVSCONFIG

Starting with version 7.36, the pvs-studio-analyzer utility also supports this flag.

Specifying the file analysis timeout for a project/solution/system

If you run the analysis with the plugin interface (Visual Studio, Rider and CLion) or in the C and C++ Compiler Monitoring UI (Standalone.exe) you can specify a timeout after which the file analysis is terminated. If the analysis timeout is exceeded, the V006 warning is added to the analysis results. The warning contains information about the file that exceeded the timeout.

You can specify the file analysis timeout in .pvsconfig. For example, you can set a 10-minute (600-second) timeout with the following line:

//V_ANALYSIS_TIMEOUT 600

If the timeout value specified in the .pvsconfig file is 0, the files are analyzed with no time limit.

You can limit file analysis time in certain projects/solutions/systems by specifying a timeout in .pvsconfig files of different levels:

• use the ‑‑rulesConfig (-c) parameter in PVS-Studio_Cmd.exe (to redefine the file analysis timeout for the current solution/project analysis);
• system (%AppData% in Windows, ~/.config for Linux, macOS);
• solution (.sln);
• project level (.csproj, .vcxproj).

Changing a certainty level of a diagnostic warning

The analyzer classifies warnings according to three certainty levels: High, Medium, and Low. Depending on the constructs used in the code, the analyzer evaluates the certainty of warnings and assigns them to the appropriate level in the report.

In some projects, it is important to find specific types of errors without considering the certainty level. However, there is also an opposite case when messages are of little use, but you don't want to turn them off completely. In such cases, you can manually set the High/Medium/Low level for diagnostic rules. To do so, use the following directives:

• The //V_LEVEL_1 directive changes the certainty level to High;
• The //V_LEVEL_2 directive changes the certainty level to Medium;
• The //V_LEVEL_3 directive changes the certainty level to Low.

To change the certainty level, use the following directive:

//V_LEVEL_1::number

where number is the diagnostic rule number.

For example, to assign the third certainty level to the V3176 diagnostic rules, use the following directive:

//V_LEVEL_3::3176

Changing the text of the analyzer messages

To change the substring in the analyzer message, use the following syntax:

//+Vnnn:RENAME:{originalString:replacementString}, ...

• Vnnn is the name of the diagnostic rule whose message you want to modify (for example, V624);
• originalString is the original substring;
• replacementString is the string that will replace the original one.

Let's consider The example of how the directive works. Suppose the code contains the number 3.1415 that triggers the V624 diagnostic rule. As a result, you get the message explaining that you need to replace 3.1415 with M_PI from the <math.h> library. However, the project uses a special mathematical library that requires you to use only its mathematical constants. To make it work properly, add the directive to the configuration file.

The directive will look like this:

//+V624:RENAME:{M_PI:OUR_PI},{<math.h>:"math/MMath.h"}

Then you will be informed to use the OUR_PI constant from the math/MMath.h header file.

You can also add a line to the message.

Here is the directive that helps you to do this:

//+Vnnn:ADD:{message}

• Vnnn is the name of the diagnostic rule whose message you want to modify (for example, V2003);
• message is a string you need to add;

Let's look at The example. Here is the V2003 diagnostic rule message: "Explicit conversion from 'float/double' type to signed integer type.".

To add more information to this message, use the following directive:

//+V2003:ADD:{ Consider using boost::numeric_cast instead.}

Now the analyzer will output a modified message: "Explicit conversion from 'float/double' type to signed integer type. Consider using boost::numeric_cast instead.".

Manage synchronization of suppress files

If you run the analysis with the plugin for Visual Studio or in the C and C++ Compiler Monitoring UI (Standalone.exe) you can disable the synchronization of suppress files by setting Specific Analyzer Settings/DisableSynchronizationOfSuppressFiles.

You can disable synchronization using .pvsconfig file of the solution level. To do this, add the following flag to the corresponding configuration file:

//DISABLE_SUPPRESS_FILE_SYNC

To enable synchronization via .pvsconfig, regardless of the value of the DisableSynchronizationOfSuppressFiles setting, you must use the flag:

//ENFORCE_SUPPRESS_FILE_SYNC

This flag is only enabled at the .pvsconfig level of the solution.

Selecting the PVS-Studio C++ core version for analysis

Starting with version 7.24, PVS-Studio_Cmd.exe utility and the plugin for Visual Studio support the ability to specify the PVS-Studio core version for analyzing C++ projects in case several versions of PVS-Studio are installed on the computer.

Starting with version 7.36, PVS-Studio_Cmd.exe utility and the plugin for Visual Studio support the ability to specify the PVS-Studio core version for analyzing C# projects in case several versions of PVS-Studio are installed on the computer.

For PVS-Studio_Cmd.exe to run the analysis on the required version of the PVS-Studio core, the //PVS_VERSION::Major.Minor flag should be added to the solution-level .pvsconfig file, where

Major is a major version number, and Minor is a minor number.

The example:

//PVS_VERSION::7.24

PVS-Studio_Cmd.exe calculates the path to the core using information from the system registry which is written by the installer when installing PVS-Studio.

For C++ projects, the minimum supported value of PVS_VERSION is 7.24. This means that when using this setting for C++ project analysis, you can run PVS-Studio core version 7.24 or newer.

For C# projects, the minimum supported value of PVS_VERSION is 7.15. This means that when using this setting for C++ project analysis, you can run PVS-Studio core version 7.15 or newer.

If a new PVS-Studio version is installed into an already existing directory containing another PVS-Studio version, the version number in the registry for this directory will be updated.

The latest installation of PVS-Studio is considered default. This means that if the latest PVS-Studio 7.22 was installed, all the plugins and PVS-Studio_Cmd.exe will be of the same version. Consequently, you will not be able to use the mechanism of selecting the PVS-Studio core versions. Therefore if you want to use old versions of PVS-Studio (7.23 and older), you need to install them first and only then install the latest PVS-Studio 7.24 or newer version.

For all versions older than 7.24 you need to specify in the registry the correlation of the version and the path to the installation directory of this version, so that PVS-Studio_Cmd.exe could find the path to PVS-Studio's core. The information is written into Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ProgramVerificationSystems\PVS-Studio\Versions.

Configuration files prioritization

Starting with PVS-Studio 7.25, the PVS-Studio_Cmd.exe utility and the plugin for Visual Studio support the feature of explicitly setting the priority of configuration files on the same level. To do this, use the //CONFIG_PRIORITY::number flag, where number is the priority number.

Starting with version 7.36, the pvs-studio-analyzer utility also supports this flag.

The example:

//CONFIG_PRIORITY::1

The smaller the number, the higher the priority of the configuration file. Files that do not have this flag have minimal priority. Files having the same priority are treated in alphabetical order. For example, among the files Filter1.pvsconfig, Filter2.pvsconfig, and Filter3.pvsconfig, the Filter3.pvsconfig file will be given priority.

The //CONFIG_PRIORITY flag affects only configuration files of the same level. In ascending order of priority, the configuration files are treated as follows:

• Global Configuration file;
• Solution Level configuration files;
• Project Level configuration files;
• File passed to the PVS-Studio_Cmd utility via the ‑‑rulesConfig (-c) argument.

Executing commands from the CustomBuild task before running the analysis

If you want PVS-Studio to execute commands from the CustomBuild task before running the analysis, add the following directive to the .pvsconfig file:

//EXECUTE_CUSTOM_BUILD_COMMANDS

This directive only applies to the .pvsconfig files passed via the command line and located at the global or solution level.

Let's look into the case where the directive might be useful.

Some Visual C++ projects can generate source code at build time using commands from the CustomBuild task. Running the analysis without generating the files can lead to errors. If you only need to generate the files, a complete build is useless (since it may take a long time).

In this case, it would be useful to specify the corresponding directive for PVS-Studio so that the analyzer could first execute the file generation commands and then perform the analysis.

Suppressing parsing errors

Sometimes the analyzer may issue a parsing error warning for a project that compiles perfectly. These errors may not be critical to the quality of the analysis. In this case, you can suppress them.

The parsing error has the following code:

• the C# analyzer: V051
• the C and C++ analyzers: V001

Suppressing the V051 warning (the C# analyzer)

The C# analyzer issues V051 if there is at least one compilation error. To see all errors, run the command-line version of the analyzer with the ‑‑logCompilerErrors option. The syntax for suppressing the errors looks like this:

//V_EXCLUDE_PARSING_ERROR:V051:{"ProjectName": "MyProject", "ErrorCode": "CS0012", "Message": "Some message"}

In this case, a compilation error that has the CS0012 code and the "Some message" message is suppressed for the (.csproj) MyProject project.

You do not need to combine information for suppression:

• //V_EXCLUDE_PARSING_ERROR:V051:{"ProjectName": "MyProject"}: Suppresses errors in the MyProject project.
• //V_EXCLUDE_PARSING_ERROR:V051:{"ErrorCode": "CS0012"}: Suppresses all errors with the CS0012 code for all projects.
• //V_EXCLUDE_PARSING_ERROR:V051:{"Message": "Some message"}: Suppresses all errors with the "Some message" message.

You can use masks when specifying the message, for example:

//V_EXCLUDE_PARSING_ERROR:V051:{Message: "Some*"}

Note. Currently, parsing error suppression is available only for V051 (the C# analyzer).

Ignoring analysis settings from Settings.xml

The global Settings.xml file contains a number of options that affect the analysis result. For example, you can turn off diagnostic rule groups.

Use the //V_IGNORE_GLOBAL_SETTINGS ON flag to ignore the settings from Settings.xml during the analysis. In this case, all diagnostic rule groups are enabled, and no path filters are applied.

To customize analysis settings, use configuration files (.pvsconfig).

This option is available only in the configuration file of the solution level, and it affects only PVS-Studio_Cmd.exe, and plugins for Visual Studio.

Using the solution directory as the SourceTreeRoot value

You can use the //V_SOLUTION_DIR_AS_SOURCE_TREE_ROOT flag to enable the solution directory as the SourceTreeRoot value.

To learn more about the SourceTreeRoot setting, please consult the separate documentation.

The parameter has higher priority than UseSolutionDirAsSourceTreeRoot from the Settings.xml file.

This option is only available for the .pvsconfig level of the solution and affects only PVS-Studio_Cmd.exe and plugins for Visual Studio.

Using the solution directory to create relative paths in the compilation dependency cache

Starting with PVS-Studio 7.34, you can use the //V_SOLUTION_DIR_AS_DEPENDENCY_CACHE_SOURCE_TREE_ROOT flag to enable the usage of the solution directory as the root part of the path that is used to create relative paths in the compilation dependency cache.

This flag should be used in file list checking mode and modified file analysis mode. The setting allows you to generate a compilation dependency cache, which can then be used on machines with different locations of the source files being analyzed.

This setting is similar to //V_SOLUTION_DIR_AS_SOURCE_TREE_ROOT, only relative paths for files will be created in compilation dependency cache files instead of in the analyzer report.

This option is only available for the .pvsconfig level of the solution and affects only PVS-Studio_Cmd.exe.

Managing sorting of suppress files

Starting with PVS-Studio 7.27, the inner content of suppress files is sorted. This is required for proper use of files in the version control system and to prevent merge conflicts.

Messages are sorted in the following order: source file name, diagnostic rule code, string hash, diagnostic rule description.

If you need to save old behavior and disable sorting mode, you can specify the //V_DISABLE_SUPPRESS_FILE_SORTING parameter.

Settings sections in .pvsconfig

You can specify specific rules for a certain PVS-Studio version.

The syntax:

//V_SECTION_BEGIN
//V_WHEN_VERSION: <CONDITION_SEQUENCE>
....
//V_SECTION_END

Each section contains three mandatory components:

• //V_SECTION_BEGIN — the section start;
• //V_WHEN_VERSION: — the condition for defining the section applicability;
• //V_SECTION_END — the section end.

The condition syntax:

<CONDITION_SEQUENCE> ::= <CONDITION> | <CONDITION_SEQUENCE> "|" <CONDTION>
<CONDITION> ::=  <SINGLE_VERSION_COMPARISON> | <RANGE_VERSIONS_COMPARISON>
<SINGLE_VERSION_COMPARISON> ::= <OP> <VERSION>
<RANGE_VERSIONS_COMPARISON> ::= "IN" <VERSION> "," <VERSION>
<OP> ::= "EQ" | "NE" | "LT" | "LE" | "GT" | "GE"
<VERSION> ::= <NUMBER> [ "." <NUMBER> ]

Conditions in V_WHEN_VERSION can be combined using the | character (analogous to the logical OR operator). Each subexpression is evaluated individually. If at least one of them is true, the section with all the directives inside it is applied. Otherwise, it is discarded.

If you need to specify a range rather than the exact version, you can use the IN operator. Values are comma-separated. For example, all versions from 7.20 to 7.25 (inclusive) can be specified this way:

....
//V_WHEN_VERSION: in 7.20,7.25
....

The supported operators in conditions, their aliases and description:

The text operators are case-insensitive. This condition entry will also be correct:

....
//V_WHEN_VERSION: == 7.17 | In 7.20,7.25 | GT 8
....

Restrictions:

• each open section must be closed properly (the end of a file is not the correct termination of a section);
• nested sections are not allowed;
• when comparing versions, it is allowed to use only the Major and Minor versions of the analyzer, separated by a dot;
• conditions can only be used after the section has been opened;
• control directives may be used only after the condition.

Notes:

• directives outside of sections apply to all versions;
• if only the Major version is specified, the Minor is implicitly treated as 0;
• when using an old version of the analyzer (before 7.31), all directives apply regardless of the section presence;
• in case of incorrect work with sections, a corresponding error is issued.

The section example:

//V_SECTION_BEGIN
//V_WHEN_VERSION: eq 7.30 | in 7.32,7.35 | gt 8
//+V::860
//V_ASSERT_CONTRACT
//-V::1100
//V_SECTION_END

The output of initial position of the shifted line (for V002)

Starting with version 7.35, PVS-Studio enables to output of the approximate initial shift position. The mechanism is useful if the analyzer warnings indicate incorrect line positions.

To output the initial shift positions, add the //+V002,VERBOSE flag. The analyzer issues the extended V002 message for every first potential shift in the file. The message includes the line expected at the specified position.

An example:

#include <iostream>
//+V002,VERBOSE
#pragma \
\
warning(push)
// The message V002 will be output here
void bar(int i) // This is the first line for which we detected a shift
{
  auto x = i % 5;
// This would be the wrong position for V609
  if ( i/x) // This is the correct position of V609
    std::cout << "bar" << std::endl;
}
void x()
{
    bar(5);
}

Note: The analyzer cannot always correctly evaluate the shift start position because the source and preprocessed files are compared in a special way. They require an expanded macro and additional information that the preprocessor substituted for the .i file.

Configuring the compilation dependency cache

Starting with PVS-Studio version 7.35, you can configure the save directory and the directory is used to create relative paths for the compilation dependency cache files.

To specify the directory for saving the cache files, use the //V_DEPENDENCY_CACHE_ROOT flag. It enables you to centralize the storage of compilation dependency caches for different projects.

To specify the root directory which will be used to create relative file paths in the compilation dependency cache, use the //V_DEPENDENCY_CACHE_SOURCE_ROOT flag,. This setting enables you to obtain compilation dependency cache files that can be used on machines with different locations for the analyzed source files.

These flags should be used in the file list checking mode and modified file analysis mode.

The example:

//V_DEPENDENCY_CACHE_ROOT C:\Project\cache
//V_DEPENDENCY_CACHE_SOURCE_ROOT C:\Project

Dependency cache source file tracking mode

Starting with PVS-Studio 7.35, you can specify the mode for tracking source files in the compilation dependency cache via the //V_DEPENDENCY_CACHE_TRACKING_MODE flag. There are several options:

• ModifiedFilesOnly: Tracks only modified source files in the hash.
• ModifiedAndWarningsContainingFiles: Tracks both modified files and those that contain warnings of previous analysis runs. Source files will be analyzed as long as they contain analyzer warnings.
• Disabled: Disables file tracking and dependency cache updates.

If the flag value is not Disabled, the plugin for Visual Studio allows you to run the modified file analysis mode via either Extension > PVS-Studio > Check > Modified Files in the menu or the Analyze Modified Files with PVS-Studio item in the context menu of solutions and projects.

When this flag is used, the compilation dependency cache is always updated regardless of the analysis mode (standard or modified file analysis).

Was this page helpful?

Message submitted.

Your message has been sent. We will email you at

If you do not see the email in your inbox, please check if it is filtered to one of the following folders:

• Promotion
• Updates
• Spam

If you can’t find an answer to your question, fill in the form below and our developers will contact you