I am using “automatic analysis” for some embedded C (firmware targeting ARM) projects and am seeing recommendations that only apply to C++, e.g. cpp:S3642. Is there any way to disable all C++ rules rather than disabling them on a rule-by-rule basis?
Hi @jacobq,
You can create an empty C++ Quality Profile and assign it to a tour project.
At the same time, the behavior you are describing is unexpected. header files are analyzed in the context of source files where they are included.
Are you including your header in a source file with one of the following extensions:
".cc", ".cpp", ".cxx", ".c++", ".C" ?
Thanks,
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
You are right, automatic analysis uses .sonarcloud.properties and ignores ``sonar-project.properties`.
C&C++ analyzer currently doesn’t analyze tests, so if you explicitly specify the test directory, your header won’t be included in the C++ file, and no C++ rules will be triggered:
C/C++/Objective-C | SonarCloud Documentation. Another possible solution if you want to analyze your test files, is to exclude only the .cc files that include the culprit file.
See also Mixed C/C++ Project: C++ rules applied to included C headers
If you are using extern C, I expect C+±specific rules to be smart and not trigger, if you face an issue where a C++ rule is triggering on extern C, please report it separately.
You can only see statistics about the old results.
To show older issues we need to store every analyzed version of your source code:
We do not store all the source code from your repository, only the source code from your most recent scans
Thanks,
I’m not sure why the links in your post didn’t go through, but I found them both:
- Mixed C/C++ Project: SonarLint applying C++ rules to C headers
- Data Security section of the Trust Center page
You can only see statistics about the old results.
To show older issues we need to store every analyzed version of your source code:
We do not store all the source code from your repository, only the source code from your most recent scans.
That makes sense. Thanks for confirming.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.