sonar-cxx: a SonarQube plugin that imports the C++ tools you already run

What the plugin is, and the focus it declares

SonarQube is an open platform to manage code quality, and this plugin adds C++ support to it with the focus on integration of existing C++ tools.

That single clause is the design. The plugin is not a C++ analyser. It is an adapter layer that reads the output of the analysers you already use and turns it into SonarQube issues, so that C++ findings live alongside the rest of a project's quality data.

There is a second, less obvious design decision in the same paragraph. The sensors for reading reports can be used with this plugin or with the SonarCFamily plugin. So the sensors, the part that knows how to parse a cppcheck XML file or a Clang-Tidy output, are usable in either host, which is a deliberate separation between the parsing machinery and the analysis rules.

The licence is the GNU Lesser General Public License, version 3 or later, and the README says the plugin is free software that you can redistribute and modify under those terms.

The project is run by the SonarOpenCommunity, the primary language is Java, and the repository is not archived with the last push on 2026-10-13. The releases are `latest-snapshot` from 2026-10-08, cxx-2.3.1 from 2026-10-06 and cxx-2.3.0 from 2026-05-18, and the CI badge covers Windows and Linux.

The parser and the dialects it has to survive

The first feature is parser support, and the list of dialects is the clearest statement of how hard the problem is.

For C++ the parser supports C++03, C++11, C++14, C++17, C++20 and C++23. For C it supports C89, C99, C11 and C17.

Then the compiler specific extensions. The Microsoft ones are C++/CLI and Attributed ATL. There are the GNU extensions, and the CUDA extensions.

Those last three are the interesting ones, because they are the cases where the language is not the language. C++/CLI is a Microsoft extension that mixes managed and native code, Attributed ATL is a Microsoft COM extension with its own syntax, and CUDA is a parallel language that the host compiler parses. A parser that claims to handle all of them is doing considerably more than tracking a standard number.

The runtime environment is Microsoft Windows and Linux, which follows from the two Windows-specific extension families.

And this parser is the part that matters most for the whole plugin, because everything else in the feature list depends on it. A static analyser that emits a warning against a construct the parser cannot read produces a finding at a location the plugin cannot map to a file and line, and the report is lost. The dialect list is therefore not a compatibility note, it is a statement of where the plugin's findings will and will not land.

Eleven static and dynamic analysers, each with its own sensor

The plugin's sensors for static and dynamic code analysis are the core of the feature set, and each is a separate sensor with its own configuration property.

Cppcheck has `sonar.cxx.cppcheck.reportPaths`. GCC and G++ have `sonar.cxx.gcc.reportPaths`. Visual Studio and the Core Guideline Checker have `sonar.cxx.vc.reportPaths`. The Clang Static Analyzer has `sonar.cxx.clangsa.reportPaths`. Clang-Tidy has `sonar.cxx.clangtidy.reportPaths`. Infer has `sonar.cxx.infer.reportPaths`. PC-Lint has `sonar.cxx.pclint.reportPaths`. RATS, the rough auditing tool for security, has `sonar.cxx.rats.reportPaths`. Valgrind has `sonar.cxx.valgrind.reportPaths`. Vera++ has `sonar.cxx.vera.reportPaths`. And Dr. Memory has `sonar.cxx.drmemory.reportPaths`.

Then the escape hatches, which are the most useful part of the design for anything not on that list. There is support for the generic issue import format, for importing issues from SARIF reports, and a `sonar.cxx.other.reportPaths` property for any other tool.

The SARIF support is the significant one. SARIF is the static analysis results interchange format, and a tool that emits SARIF can be integrated without the plugin knowing anything about it. For a team whose analyser is not one of the eleven, that is the difference between using the plugin and not using it.

And the split between static and dynamic analysis in that heading is real. Valgrind and Dr. Memory are dynamic analysers, and their output is a runtime finding, not a source-level defect.

Test framework sensors, and the XSLT escape hatch

The test framework sensors cover a long list of formats, and the pattern in the configuration is instructive.

XUnit file format, Google Test, Boost.Test, ctest from cmake, CppTest, CppUnit, VSTest from Microsoft and NUnit are all supported, and each is configured through a report path property. Most of them use `sonar.cxx.xunit.reportPaths`.

That is the interesting part. Rather than writing a separate parser for each framework's XML dialect, the plugin reuses the XUnit reader for most of them, and the few that do not fit are handled with an XSLT stylesheet through the `sonar.cxx.xslt` property. ctest is the clearest example, where the README tells you to use the ctest option `--output-junit <file>` to produce a file the plugin can read.

The philosophy is consistent with the rest of the plugin. Instead of growing a bespoke reader for every test framework, the plugin reuses one reader and gives you a transformation step for the rest.

For the frameworks that have a dedicated property, such as VSTest with `sonar.cxx.vstest.reportPaths` and NUnit with `sonar.cxx.nunit.reportPaths`, the property is separate because the report format is different enough to be worth naming.

And the general escape hatch is there as well: any other tool can be integrated through the generic test execution report format, with adaptations possible via XSLT.

Coverage sensors and the plugin's own structure

The coverage sensors are listed with the same shape as the rest, and the first entry visible in the README is Visual Studio coverage reports with `sonar.cxx.vscoveragexml.reportPaths`.

The repository layout is where the plugin's internal structure becomes visible, and the directory names are the SonarQube plugin vocabulary.

There is `sonar-cxx-plugin/`, which is the plugin packaging, and `cxx-sensors/`, which is where the report readers live. Then `cxx-squid/`, which is the rule implementation, and `cxx-squid-bridge/`, which is the layer that exposes those rules to the SonarQube API. The `cxx-checks/` directory holds the checks themselves. And `cxx-sslr/` and `cxx-sslr-toolkit/` are the semantic analyser and its toolkit, which is the part that does the syntactic and semantic analysis of the source in order to map findings onto the code.

Two build files point at what the project is built with. There is a `pom.xml` for the Maven build, and the root `integration-tests/` directory, which pairs with the `.behaverc` file at the root. Behave is the Python behaviour-driven testing tool, and its presence tells you that the integration tests are written in Python even though the plugin itself is Java. That is a common arrangement for SonarQube plugins, where the test harness drives the scanner as a process and asserts on the issues it produces.

There is also a `.deepsource.toml`, a static analysis configuration for the project's own source, and a `.dcignore`.

Where the plugin is the wrong tool

The first wrong case is a team that wants SonarQube to analyse C++ on its own. The plugin's stated focus is the integration of existing C++ tools, and the sensors for reading reports can also be used with the commercial SonarCFamily plugin, which is the product that does the analysis itself. If you want rules that SonarQube applies without a separate analyser, this is not the route.

The second is a team whose analyser emits a format the plugin cannot read and cannot be adapted to. The eleven analysers and the generic and SARIF routes cover a lot, but the plugin still has to parse the source to place the findings, and the dialect list is where that shows.

The third is a build that does not run any of the supported analysers. A C++ project that only compiles and tests has nothing for the plugin to import, and the plugin's value is proportional to the number of tools you already have in the pipeline.

The fourth is a team that wants the findings to drive fixes. The plugin imports issues, and a finding imported from a report is a finding with a location, and the remediation advice in the original tool's output is not carried over. SonarQube's own quick fixes are a property of the rules, and imported external issues do not have them.

The fifth is a team that needs the plugin to be the primary gate on a large codebase. The plugin is community maintained, and while the SonarCloud quality gate badge in the README header shows it is checked against a quality gate, that is the plugin's own project, not yours.

Editorial conclusion

sonar-cxx suits a team that already runs a C++ linter, a static analyser or a sanitiser in its build and wants those findings in the same place as the rest of its quality data, without reimplementing any of them. It does not suit a team that wants SonarQube to analyse C++ itself, because the plugin's stated focus is the integration of existing tools, and the sensor for reading reports can also be used with the commercial SonarCFamily plugin. Before adopting it, check that the analyser you run emits a format the plugin has a sensor for, and note that the parsing work is the plugin's own, so the dialect coverage it lists is what governs whether your code parses at all.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. SonarOpenCommunity/sonar-cxx on GitHub