Page Item: Running an analysis

SLUG: getting-started-running-an-analysis

COMMENT: an important feature that comes with standalone mode is that users can customize the ruleset to use (active/inactive rules, parameters).

Lorum ipsum

tabbed

PLACE ECLIPSE CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

tabbed

By default, new analyses are automatically triggered as you type, following a change on the code. You can disengage automatic analysis by going to IntelliJ Settings > Tools > SonarLint; in the Settings tab, deselect Automatically trigger analysis.

There are additional ways to trigger a SonarLint analysis in IntelliJ:

• On the Fly (default): When the file is autosaved or manually saved. Issues found during the analysis are highlighted in the SonarLint view window under the Current file tab.

• On-Demand: Single files can be analyzed by right-clicking over a file in the project tree, then selecting SonarLint > Analyze with SonarLint. You can also click the green arrow in the sidebar of the SonarLInt View window or, analyze all project files by right-clicking in the explorer window and selecting Analyze with SonarLint. At any time you can use the keyboard shortcut Cmd+Shift+S/Ctrl+Shift+S on your Mac/Windows machine to analyze all project files.

• By selection: Use this method to get feedback on issues found in a set of files. Select one or more files in the Project Tree, then right-click > SonarLint > Analyze with SonarLint. The Report tab will open automatically in the SonarLint view window where you can view issues found in multiple files. Note that you can also click the Analyze All Project Files button from the Report tab, without having to select them from the Project Tree.

To perform JavaScript or TypeScript analysis, you must set the file path to your Node.js. Go to IntelliJ Settings > Tools > SonarLint > Settings tab, and click the three dots to bring up a navigation window.

In addition, it’s possible to limit the analysis using this same navigation path by selecting Exclude from SonarLInt analysis; more details about File Exclusions can be found here.

callout info A custom change to the configuration such as initializing Connected Mode or when modifying your selected rule set, a new analysis will be triggered because it could lead to different results.

It is possible to trigger an analysis on demand by clicking the green arrow in the sidebar of the SonarLint view window; conversely, there is a Cancel SonarLint Analysis button shown in red. Also, the Current file tab offers a shortcut to the Project Settings and a Clear SonarLint Issues button to help manage the report of issues.

SonarLint for IntelliJ allows you to complete an analysis on all project files and an option to review issues found in other files without having to open them.

From the Report tab of the SonarLint view window, click on the Analyze VCS Changed Files button to analyze files that are not yet committed but have changed since the last commit.

In addition to right-clicking on the project folder to select SonarLint > Analyze with SonarLint, you can click on the folder icon in the left toolbar of the SonarLint view window to Analyze All Project Files. Likewise from the explorer window, entering the keyboard shortcut Cmd+Shift+S/Ctrl+Shift+S on your Mac/Windows machine will trigger an analysis on all project files and automatically open the Reports tab to view the report.

tabbed

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

SonarLint can analyse .vcxproj projects that use the standard Visual Studio compilation tools. Projects that use third-party tools (such as Unity projects) are not supported.

Visual Studio 2017 and later support opening CMake projects in the IDE (see the Microsoft documents for more information).

Starting with v4.38, SonarLint can analyse a subset of CMake project types that meet the following requirements:

• Visual Studio 2017 Update 3 or later is used
• Visual Studio is configured to use the Ninja generator (the default), and
• the CMakeLists.txt file contains the following command: set(CMAKE_EXPORT_COMPILE_COMMANDS ON).

See the Getting Started with analyzing CMake projects in Visual Studio for more information.

C/C++ analysis is triggered when a file is opened or saved. Any existing issues for the document will immediately be removed from the Error List. New issues will be added to the Error List incrementally as they are detected.

The status bar will be updated to show the file is being analysed...

... and again when analysis has finished:

Additional detailed information will be shown in the SonarLint pane of the Output Window.

Note: SonarLint only displays status information in the status bar, as shown in the the above screen shots. Some versions of Visual Studio provide other C++ analysis rules from Microsoft that display progress information in the background tasks pop-up window. These messages do not relate to SonarLint analysis. See here or more information on the Microsoft C++ rules.

SonarLint has 450+ rules for C++ and 280+ rules for C. Most run very quickly and will return issues in under a second. However, some of the more advanced rules that involve semantic analysis can take more than ten seconds to run.

Analysis is performed in the background in a separate process. It should not have a noticeable impact on the user experience in Visual Studio. If the analysis is taking too long for a particular file then the analysis process will be terminated. If an analysis is being re-triggered (e.g. via a re-save of the file), the previous analysis will be cancelled and a new analysis will start.

Prior to v4.22, issues were only displayed in the Error List after all rules had finished processing. As of v4.23, issues are displayed in the Error List as soon as they are available. This means that most issues will appear within a few seconds. However, the status bar may still continue to display the analyzing xxx.cpp message for some time until all of the rules have finished processing.

By default, an analysis that has not completed within one minute will be stopped and a message logged in the Output Window. We expect such timeouts to be very rare, and probably indicates a problem in one of our analysis rules. If you do encounter timeouts when analysing files, please open an issue in the SonarLint section of the Community Forum and tag it with cfamily.

collapse

The SonarC# and SonarVB rules are implemented as Roslyn VSIX analyzers, and you can configure which rules are executed using the normal ruleset mechanism in VS.

SonarLint itself does not have any special behaviour in relation to configuring the set of Sonar C#/VB.NET to rules. The Sonar C# and VB.NET rules are implemented as Roslyn analyzers and use the standard Visual Studio features to enable and disable rules.

For VS2015 and VS2017 this means ruleset files. VS2019+ users can use .editorconfig files instead.

The simplest approach is just to reference the ruleset directly from the project and check the ruleset file in to source control. This won't have any adverse impact on machines that don't have SonarLint installed; Visual Studio will load the ruleset file, but it won't have any impact on build or in the IDE because the analyzers are not available.

There are a number of ways to achieve this, depending on the version of VS you are using. Some of the possible solutions are as listed below. There may be others - see the Microsoft documentation Customize your build for more ideas.

The Visual Studio will search up the directory tree from the solution folder to locate a .editorconfig file. Create a .editorconfig file containing the required settings and drop it in a folder above the solution that is not under source control. See Set rule severity in an EditorConfig file in the Microsoft documentation for more information (setting a severity to "none" will disable a rule).

• this will only work in VS2019 or later
• it won't work if your solution already references a .editorconfig file

The Directory.Build.props file will automatically be imported by MSBuild (and by extension Visual Studio). The file can be in the project directory or any parent directory so it should be possible to put it in a folder above the project/solution that is not under source code control.

Example:

<!-- Sample Directory.Build.props content -->
<Project>
  <PropertyGroup>
    <CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)Example.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>
</Project>

• this will only work on VS2017 or later.
• it won't work if your solution has a Directory.Build.props file checked in.
• it won't work if your solution already references a ruleset file.

Example:

<!-- Snippet to conditionally set the ruleset to file that might not exist on all dev machines -->
<PropertyGroup>
  <CodeAnalysisRuleset Condition="Exists('$(LocalAppData)\Example.ruleset')">$(LocalAppData)\Example.ruleset</CodeAnalysisRuleset>
</PropertyGroup>

• this does involve changing the project file(s), but only to add a single property.

Project files that use the standard Microsoft build targets will automatically import any targets files that are exist in a well-known location. You can use this feature to conditionally import a ruleset.

This is similar to option (2) above but works with all versions of MSBuild.

Example:

<?xml version="1.0" encoding="utf-8"?>
<!-- Example props file to drop in %LocalAppData%\Microsoft\MSBuild\[VERSION]\Microsoft.Common.targets\ImportBefore -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <CodeAnalysisRuleset Condition="Exists('$(LocalAppData)\Example.ruleset')">$(LocalAppData)\Example.ruleset</CodeAnalysisRuleset>
  </PropertyGroup>
</Project>

Notes:

• the location of the ImportBefore folder varies depending on the version of MSBuild, based on the following standard pattern: %LocalAppData%\Microsoft\MSBuild\[VERSION]\Microsoft.Common.targets\ImportBefore. The [VERSION] values for MSBuild 14 and 15 are 14.0 and 15.0 respectively. MSBuild 16 and latter use Current.
• the ImportBefore folder does not exist by default so you might have to create it.

• it won't work if your project already references a ruleset file.
• the location of the ImportBefore folder varies according to the version of MSBuild, so if you are using multiple versions of Visual Studio you will need to drop the same file in multiple locations.

collapse

See Choosing which C, C++, JavaScript, TypeScript or Secrets detection rules to run in Standalone mode

In standalone mode, it is possible to enable or disable rules, configure rule parameters, and change the reported rule severity. However, not all options are supported for all languages. See the table below for more information:

To disable a rule, select an instance of the rule in the Error List and click the Disable SonarLint rule command on the context menu:

You can view and change the current rule settings by clicking the "Edit rules settings" on the SonarLint Tools, Options page:

When the rule settings are changed (either by using the Disable SonarLint rule command or by directly editing and saving the settings.json file), SonarLint will automatically re-analyse all open documents.

The SonarLint Output window tab contains text output describing the processing that has taken place e.g.:

The settings.json file is stored in user's roaming profile %APPDATA%\SonarLint for Visual Studio. It applies to all supported versions of Visual Studio. If the machine is domain-joined, then the settings file will be automatically copied to any other machine in the domain that the user logs on to.

The format of the settings file is as follows:

{
  "sonarlint.rules": {
    "c:S1135": {
      "level": "On",
      "severity": "Info"
    },
    "cpp:S1199": {
      "level": "Off",
      "severity": "Minor"
    },
    "cpp:SingleGotoOrBreakPerIteration": {
      "level": "On",
      "parameters": {
        "maxNumberOfTerminationStatements": "1"
      },
      "severity": "Major"
    },
    "javascript:S1135": {
      "level": "Off"
    },
    "typescript:S1854": {
      "level": "On"
    }
  }
}

The format of the rule key in the file is [c|cpp|javascript|typescript]:[rule id]. The full list of rules is available at https://rules.sonarsource.com/.

Valid severity values are Blocker, Critical, Major, Minor and Info. Changing the severity of a rule only affects the label in the Category column in the Error List.

If the settings file does not contain an entry for a rule then the default setting for the rule in the SonarWay Quality Profile will be used.

Note: if the solution is in Connected Mode then the settings file is ignored. Connected Mode is not currently for JavaScript or TypeScript - see #770. It is also not available for Secrets detection rules, which are only run in the IDE and so cannot be configured on the server.

tabbed

PLACE VISUAL STUDIO CONTENT HERE TO ENTERED INTO THE KONTENT.AI-SPECIFIC ASSET

Lorum ipsum

NOTE THAT THIS SECTION HAS COLLAPABLE ASSETS WHICH SHOULD BE USED

To analyze C and C++ code, you need to Generate a compilation database and be on one of the supported enviroments as is described below-

Compilation Database is a JSON file format introduced by the LLVM project. It contains the compile commands used to build a project.

collapse

collapse

collapse

collapse

collapse

collapse

collapse

The analysis can be activated by simply pointing to a compilation database that describes the project to be analyzed. This can be done through a notification that pops up when a folder that contains a file named compile_commands.json is opened, or through the SonarLint embedded action that lists all compilation database files in the folder, or by manually assigning the sonarlint.pathToCompileCommands option in the settings to the full path of the compilation database.

Note that the SonarLint embedded action can be used to switch the active compilation database.

In case the analysis is not working or obvious false positives are raised, here are the recommended actions in order:

collapse

collapse

collapse

collapse