Hi,
Information required:
- versions used -sonar-scanner-4.2.0.1873, sonarqube-8.2.0.32929
- error observed -
ERROR: Error during SonarQube Scanner execution java.lang.IllegalStateException: An error occurred while analyzing the following compilation unit: <test>.cpp A file named "sonar-cfamily.reproducer" has been generated to help the problem investigation. Please contact SonarSource support providing the following file to help improving the analyzer: <sonar-cfamily.reproducer>
- It is happening with C++ 17
- Workaround- need to try with ignoring the specific file.
It started flagging since we moved to C++ 17 with our C++ projects .Let me attach the log file for reference, let me know how to send sonar-cfamily.reproducer for further investigation.
Sonar_Runtimes_Errors.txt (11.2 KB)
Thanks,
Jenifer
Hi @Jenifer_Rajendren ,
I sent you a private message for this.
Thanks
Hi I have zipped due to 4MB size restriction here, let me know if the file has issues due to compression.
sonar-cfamily.zip (3.2 MB)
Thanks,
Jenifer
Hi Jenifer,
No problem to read it, you were right to zip the file!
Can you confirm that the code is compiling correctly when you don’t use the scanner?
Thanks,
Hi,
I tried excluding the directory, for some weird reasons it dint consider. I am commenting the specific files for getting build temporarily. Without sonar scanner it passes.
Thanks.
Hi @Jenifer_Rajendren ,
There is indeed an incompatibility between the Magic Enum library under Windows and our analyzer.
If your project is multi platform, the problem should not happen under GCC or clang.
If Magic Enum is used by only a small part of your codeline, you can try to exclude it from the analysis.
Otherwise, the only solution I can see would be to have a #ifndef SONAR_SCAN
around all calls to magic-enum, and to run the analysis with -DSONAR_SCAN in the compiler line.
Thanks,
Hi ,
When you say compiler line is it on sonar specific files?
In our azure devops based build system:
-
We use powershell based config file to build our TFS based source files
-
Sample sonar analysis cpp- command line is as:
$sonarCppParameters = “/d:sonar.cfamily.build-wrapper-output="$clientOutputFolderPath\buildwrapper_output
”. Should I add /dSONAR_SCAN something like that in this config file or in build configuration file make file or somewhere?
-
Our projects are built using makefile for your reference
Important question from my team is:
-
When can you add support to Magic-Enum from sonar -scanner itself?
-
If you want our reference server id:F3D24742-AWrUbuyXfl3ku7PkrZ_e for providing further support.
Update: I tried adding -DSONAR_SCAN or /dSONAR_SCAN in the above mentioned $sonarCppParameters in configuration powershell, it complained back saying unsupported command.
Hi @Jenifer_Rajendren ,
Regarding the -DSONAR_SCAN
, what I’m talking about is changing your code to wrap all the calls to magic enum with a macro of your choice. Then you can define the macro in the compiler, when running the scan. That’s a change that needs to be done in the code, not in the configuration of your CI.
Regarding when we can add support magic-enum, I created a ticket that you can follow here. But we cannot tell when it will be handled.
Thanks
Hey @Fred_Tingaud ,
I am very particular about this line, We have already made changes in the code with #ifndef SONARSCAN that includes all the magic enum code, when you say add the line to compiler it means adding it to Visual Studio Pre-processor directives. That won’t compile those code & all, our requirement here is just to exclude from scanning for not compilation.
Thanks
Hi @Jenifer_Rajendren ,
You will need the code to compile correctly if you want the best results. For example if you have code that does
std::string name = magic_enum::enum_name(something);
You can replace it with
#ifndef SONAR_SCAN
std::string name = magic_enum::enum_name(something);
#else
std::string name = "";
#endif
That way the project will compile correctly even with the SONAR_SCAN flag.
Next, you can change the line that calls build-wrapper from
./build-wrapper --out-dir build_wrapper_output_directory make all
to
./build-wrapper --out-dir build_wrapper_output_directory make all CFLAGS=-DSONAR_SCAN
(or you can create a new Makefile target that does include the macro).
I know this approach is not ideal, but I hope it will allow you to analyze the project as well as possible.
Thanks,
Hi @Fred_Tingaud ,
Thanks for your time & effort.
But the way we use make is, inside the project file not externally from build-wrapper. I think calling via:
./build-wrapper --out-dir build_wrapper_output_directory make all CFLAGS=-DSONAR_SCAN
should be equivalent to adding pre-processor directive in the project’s nmake setting.
In this code snippet
#ifndef SONAR_SCAN std::string name = magic_enum::enum_name(something); #else std::string name = ""; #endif
since we check if the preprocessor is not defined, then compile else the second part. So here only the second part will get executed not the first one.
I think sonar.exclusion might be better than this option.
Thanks
Hi @Jenifer_Rajendren ,
Just to be clear, the SONAR_SCAN macro should only be passed when building for the Sonar analyzis, not when building for execution. Otherwise it will indeed break your application.
But sonar.exclusion might be simpler option if the magic enum library usage is localized enough in your code.
Thanks