C++23 Support - Sonar-scanner: Unsupported value of __cplusplus macro

SonarCloud
, ,
1

Hi,

I’m trying to integrate sonarcloud into a C++23 application.

I’m facing an issue on sonar-scanner run.

#0 35.63 14:35:12.609 ERROR: Error during SonarScanner execution
#0 35.63 java.lang.UnsupportedOperationException: Unsupported value of __cplusplus macro: 202100L
#0 35.63        at com.sonar.cpp.analyzer.StdFlags.fromCppMacrosWithoutConditionalFeatures(StdFlags.java:56)

Do you have any solution to avoid this issue ?

Note: We don’t have any issue on MSVC but our target is gcc-12.

We must run sonnar-scanner with c++23 on linux. If not, we will have to drop sonar cloud unfortunately. :confused:

We wish that sonar support c++23 feature but for today, it’s not a must. We only wish that sonar-scaner does not fail. In other words, it will work for us if sonar ignores C++23 features but does not block at runtime.

Thanks for you help,

Jonathan

4

Hi @j-bruel ,

we currently don’t support C++23.

We don’t like this strategy which may lead to a poor analysis result. C++23 has not been released yet and compilers support is also far from it.

Out of curiosity, why? Is it some experimental project? Cannot you build it with c++20 for the analysis?

6

When can we expect C++23 support on SonarCloud?

7

Hello @juliojimenez

In SonarCloud, you can now enable experimental C++23 support by adding the property sonar.cfamily.cpp23.enabled=true

In SonarQube, this property is available starting at version 10.0.

1 Like
9

I should have clarified that by experimental, we mean that user support is limited, and the property may be modified or removed. We can not guarantee the results: the compiler support for C++23 is limited, and our rules have not yet been adjusted.

You are still welcome to use it, but please, keep this in mind :slight_smile:

1 Like
11

Just for the probe, would it be possible to let the scanner do the probe with a dummy “compiler” (i.e.: a script that just outputs a “compatible” __cplusplus version) instead?

12

I would advise against that workaround. If you are using C++23 features, but trick the C++ analyzer into thinking you are using, say, C++20, the analysis results will be unreliable at best.

C++23 language constructs (i.e. if consteval), will become parsing errors in C++20. C++23 standard libraries features will go missing (since they are usually enabled conditionally based on the value of __cplusplus). In summary, the code will “look” broken from the analyzer’s perspective.

If your code can be compiled with C++20, it would be better to do just so and analyze that version.

I hope this helps clarify why it is important for the analyzer to be aware of how the code is compiled.

14

There is (maybe) a little misunderstanding going on.

  • The creator of this topic does not intend to use c++23 features, but “accidentally” the build machine has a c++23 compiler installed.

  • In the given situation, Sonarqube gives no results at all, claiming it doesn’t know c++23.

  • The only way to tell Sonarqube not to worry about c++23 specifics is to fool it into believing that a compiler was used that it knows about.

Certainly a better result, than none at all.

(That all, assuming the original claim an experience was factual, which I cannot check myself)

15

I apologize for my previous answer…

In the meantime I saw that some of my readings/assumptions were “not quite accurate”:

  • as it seems from newer posts, c++23 may already be "experimental"ly supported in the meantime.

  • on reading the first post again, he doesn’t explicitly say that he isn’t using c++23 features.
    (only: “it will work for us if sonar ignores C++23 features but does not block at runtime.”)