C++: Set C++ version (14, 17, ...) to execute checks for

SonarQube Server / Community Build
,
1

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?

We are using SonarQube version 8.4.1.

2

Hello @Rene,

Welcome to the community!

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.

Thanks,

3

C++14/17: I will try.

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.

4

@Rene,

Don’t search for the issue message, search for the issue title which you can find by pressing “Why is this an issue?”

5

Thank you, that is really helpful.

1 Like
6

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-4.0.0.1744-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 …

7

@Rene,

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.

Thanks,

8

Hi Abbas

I did set the C++ standard to C++14, but the namespace issues are still reported.

“Prove” that C++ is set:

socket.cpp:28:11: warning: nested namespace definitions only available with -std=c++17 or -std=gnu++17 [-Wpedantic]
namespace six::foundation::comm {

But I still have the issues in the Sonar Analysis.

9

@Rene,
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.

Thanks

10

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
“version”:0,
“captures”:[
{
“compiler”:“clang”,
“executable”:“/opt/rh/devtoolset-8/root/usr/bin/c++”,
“stdout”:"#define DBL_MIN_EXP (-1021)\n…

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)

11

@Rene,

Can you zip the file to reduce the size before uploading? I would be interested in checking what is happening, even if you found a workaround by using set (CMAKE_CXX_STANDARD 14)

12

@Abbas

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.

I have attached the zipped json file.
build-wrapper-dump.zip (62.5 KB)

13

@Rene,

This macro is for C. For C++ we use __cplusplus and we dont store it in the JSON file.
To investigate further, can you please upload debug output of the scanner ( add -X to the scanner command).

Thanks,

14

@Abbas

Here is the output of the scanner. It shows
#define __cplusplus 201402L

sonar-build.log.zip (198.2 KB)

15

@Rene,

Thanks for providing all the requested files.

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 6.11.0.19130 (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

Let me know if you have further questions,

16

A post was split to a new topic: S3630 is raised on C++17 project

17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.