You can create an empty C++ Quality Profile and assign it to a tour project.
That’s basically what I did to circumvent this. But then later when I re-enabled the C++ rules (“Sonar Way” quality profile) I did not see the issues detected again. I think the difference is that I attempted to exclude googletest code from the test root, though I did that in sonar-project.properties not .sonarcloud.properties, and my understanding is that is not used for Automatic analysis, so I am not sure if it had any effect.
.sonarcloud.properties
$ cat .sonarcloud.properties
# Define separate root directories for sources and tests
# See https://docs.sonarsource.com/sonarcloud/advanced-setup/analysis-scope/
sonar.sources=Src/
sonar.exclusions=Src/lib
# sonar.inclusions=
sonar.tests=tests/
sonar.test.exclusions=tests/lib
# sonar.test.inclusions=
# Source encoding
# sonar.sourceEncoding=
# Exclusions for copy-paste detection
# sonar.cpd.exclusions=
# Although we don't have any of our own Python code in here, it might be used
# by the testing framework or other tools, and explicitly setting the version
# here prevents warnings about that from littering the UI.
sonar.python.version=3
# C++ standard version (for C++ projects only)
# If not specified, it defaults to the latest supported standard
# sonar.cfamily.reportingCppStandardOverride=c++98|c++11|c++14|c++17|c++20
sonar-project.properties
$ cat sonar-project.properties
# I think this file gets used if sonarqube is run in CI,
# in contrast to .sonarcloud.properties (used for SonarCloud automatic analysis)
# Required metadata
sonar.projectKey=<my project>
sonar.organization=<my org>
# Define separate root directories for sources and tests
# See https://docs.sonarsource.com/sonarcloud/advanced-setup/analysis-scope/
sonar.sources = Src/
sonar.tests = tests/
# Exclude vendor-supplied library code from source & test scopes
sonar.exclusions = Src/lib,Inc/lib,tests/lib
Are you including your header in a source file with one of the following extensions …
No, except in tests, though some of my headers are vendor-supplied and are designed for compatibility with C++, e.g. they are surrounded with extern "C" { ... }. There are definitely .cc files inside my test root (from googletest). I also have some #ifdef DEBUG_UNIT_TEST_XYZ sections that insert some C++ code (std::cout << ...), but they are not enabled (erased by preprocessor since conditional is false), but I am guessing your tools are using only the file extensions to determine the language type.
Is there a way to view old/historic analysis results? When I go to “Activity” I can see created/fixed summary numbers, and when I view the analysis for the original pull request I can see the issue listed but it is no longer highlighted in the source code view.
See also Mixed C/C++ Project: C++ rules applied to included C headers