Sensor to read reports from the Clang Static Analyzer tool. The goal of the Clang Static Analyzer is to provide a industrial-quality static analysis framework for analyzing C, C++, and Objective-C programs that is freely available, extensible, and has a high quality of implementation.

Note: The cxx plugin itself does not run the tool, you have to do that yourself beforehand. The sensor only reads the report generated by the tool!

• Link to the tool page: https://clang-analyzer.llvm.org/
• The sensor supports rules from Clang Static Analyzer with version LLVM 16.0.0.
• plist output format is supported

In order to run Clang Static Analyzer and generate a fitting report, make sure:

• to call it from the projects root directory, so that the paths in the report fit
• that the parameter matches the sonar.sources list in sonar-project.properties

Run clang from your project root. Select the plist as an output format. To generate the plist output there are two options:

• -analyzer-output plist
• -analyzer-output plist-multi-file

Both options will generate a report file in plist format. The difference is that in the case of plist-multi-file bug reports across multiple files will be generated if the bug execution path goes through multiple files. For example: the issue is in a function in a header file called from a .cpp file. In this case the report will contain the relevant parts from the .cpp file too to help to understand the reported issue (analyzer assumptions during the analysis on a possible execution path).

$ clang -cc1 -analyze -analyzer-checker=core.DivideZero src/divzero.cc -I src -analyzer-output plist-multi-file -o divzero.plist

To list the available checkers use this command:

$ clang -cc1 -analyzer-checker-help

See help for further details on how to configure the analysis.

$ clang -cc1 --help

Use scan-build to analyze a project

To run the static analysis on your project the scan-build tool can be used.

There is an alternative rewritten version of the original tool which is available here. See the used guide how to install the tool and for further usage examples configuration options.

Run scan-build in your project root. The sample is using the rewritten version to analyze your project:

Sample command lines:

$ scan-build -plist --intercept-first --analyze-headers -o analyzer_reports make

If the tool was executed successfully, a report like the example below should be generated:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>clang_version</key>
<string>clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)</string>
 <key>files</key>
 <array>
  <string>src/lib/component0.cc</string>
  <string>src/lib/component1.cc</string>
 </array>
 <key>diagnostics</key>
 <array>
  <dict>
   <key>path</key>
   <array>
    <dict>
     <key>kind</key><string>event</string>
     <key>location</key>
     <dict>
      <key>line</key><integer>3</integer>
      <key>col</key><integer>9</integer>
      <key>file</key><integer>1</integer>
     </dict>
     <key>ranges</key>
     <array>
       <array>
        <dict>
         <key>line</key><integer>3</integer>
         <key>col</key><integer>13</integer>
         <key>file</key><integer>1</integer>
        </dict>
       </array>
     </array>
     <key>depth</key><integer>0</integer>
     <key>extended_message</key>
     <string>Value stored to &apos;i&apos; during its initialization is never read</string>
     <key>message</key>
     <string>Value stored to &apos;i&apos; during its initialization is never read</string>
    </dict>
   </array>
   <key>description</key><string>Value stored to &apos;i&apos; during its initialization is never read</string>
   <key>category</key><string>Dead store</string>
   <key>type</key><string>Dead initialization</string>
   <key>check_name</key><string>deadcode.DeadStores</string>
   <!-- This hash is experimental and going to change! -->
   <key>issue_hash_content_of_line_in_context</key><string>ec3497e24cb3e11eacfd34c540fcba71</string>
  <key>issue_context_kind</key><string>C++ method</string>
  <key>issue_context</key><string>do_valgrind_errors</string>
  <key>issue_hash_function_offset</key><string>13</string>
  <key>location</key>
  <dict>
   <key>line</key><integer>3</integer>
   <key>col</key><integer>9</integer>
   <key>file</key><integer>1</integer>
  </dict>
  </dict>
 </array>
</dict>
</plist>

1. First check if the file extensions read in by the cxx plugin are set (sonar.cxx.file.suffixes).
2. The rules for which you want to generate issue must be activated in the Quality Profile of your project. You can find instructions on how to do this under Manage Quality Profiles.
3. Set the analysis parameter sonar.cx.clangsa.reportPaths in the configuration file sonar-project.properties of your project. The Report Paths link describes the configuration options.
4. Execute the SonarScanner to transfer the project with the report to the SonarQube Server.

Sample for sonar-project.properties:

sonar.cxx.clangsa.reportPath=*.plist

• If no results are displayed after a successful scan, check Manage Quality Profiles first.
• If scanning is failing, check items listed under Troubleshooting Configuration.
• If no issues are displayed for your source code in SonarQube, check the items listed under Troubleshooting Reports.
• In the case of incomplete scans, Detect and fix parsing errors gives advice on how to fix this.