I get a lot of “Concatenate this namespace with the nested one.” issues. The problem is that this project is a library that is used by other projects which are still compiled with C++ 14, so I cannot change the library yet.
Is there a way to set the C++ version to apply for a project? SonarQube “nows” that this feature was introduced with C++ 17 only, so if I could set the version to C++ 14 for the project, I expect these issues to disappear. The only thing I found related to C++ version(s) was the setting for the “c++ family = c++20”, the opposite of what I need.
I could not find this rule in the C++ list of rules, so I cannot deactivate it myself. Why are there rules that are not shown in the list of rules?
You are seeing C++17 rules because the command you are passing to build-wrapper builds with C++17. You can pass to build wrapper a command that forces to build with C++14 then you won’t see C++17 issues.
You should be able to find it. The rule id is S5812.
Finding the rule:
The problem I see is that the text in GUI does not match the text of the rule, which is “Concise syntax should be used for concatenatable namespaces”. Which makes it hard to find, obviously.
Okay, so the C++ version issue is still not resolved. How or where am I supposed to pass this information to the Sonar tools? Neither the build wrapper nor the scanner have an option for the C++ version.
I’m calling the two programs like this:
sonar/cmake/tools/build-wrapper-8.4.1-linux-x86/build-wrapper-linux-x86-64 --out-dir sonar/build/sonar/out make -j40
sonar/cmake/tools/sonar-scanner-184.108.40.2064-linux/bin/sonar-scanner -Dproject.settings=“sonar/build/sonar/sonar-project.properties” -Dsonar.cfamily.threads=40
The documentation says that multiple language standards are supported, but it does not say how to specify which language standard to use …
It is not an option to be provided to “Sonar tools”. build-wrapper is checking which standard is used by your compiler and use it for the analysis.
So in short, if make is calling GCC with -std=c++17 option… changing your compilation command to use -std=c++14 would fix the problem. We detect what standard you are using in your compilation and we use it to decide which of the enabled rules are going to be triggered.
Are you running a clean build between each analysis? The command passed to build-wrapper should clean build your project(you should do something like make clean before calling sonar/cmake/tools/build-wrapper-8.4.1-linux-x86/build-wrapper-linux-x86-64 --out-dir sonar/build/sonar/out make -j40).
If you are already running a clean build, can you share the generated build-wrapper.json file? Let me know if you prefer to share it in private.
Yes, the build directory is deleted before every build, so it’s always a new, full build.
I found a build-wrapper-dump.json file, but this is over 3 MBytes. A bit difficult to share …
I checked the contents of the file, what I find is several lines of "-std=gnu++14",
but I also find #define __STDC_VERSION__ 201710L
in the first block in the file
Looks like the compiler acts upon the -std argument, while SonarQube uses the version define?
I use this statement in the CMakeLists file to set the version: set (CMAKE_CXX_STANDARD 14)
Oh, this is not a workaround. It is the setting I had all the time for setting C++ 14, but even with that I still have the issues with the “nested namespaces” warnings.
Like I wrote, the compiler compiles using the standard C++ 14 as it should, but it looks like SonarQube evaluates the define, which says C++ 17.
Yes, and we are detecting C++14.
I noticed from the log that your SonarQube embeds a very old version of the CFamily analyzer: CFamily Code Quality and Security 220.127.116.1130 (cpp)
We started running rules based on compilation standard starting CFamily 6.14. We also added tags to rules to point to the C++ standard from which they start to run. Before that feature, all rules ran on all standards. You had to disable rules manually by removing them from your quality profile.
Consider upgrading to the latest SonarQube LTS. It embeds CFamily 6.20