For GemRB we happily switched to the automatic C++ analysis now that it became available, however we got a slew of odd new error reports.
I believe the change is due to the fact that automatic analysis is not actually doing a build, so I’m wondering if there’s anything better we can do than disable complaints for the problematic lines (3 custom headers with extra boilerplate is not better).
The reports all related to libfmt, which we include in its header-only form. If you want it without exceptions, you set a define before use:
We do this in the build system (cmake / xcode project file), so it’s not visible in the C++ source directly. Which is what I think trips up Sonar. Any ideas?
You are right about your analysis. Currently, the only way to force Sonar to pick up a specific macro is to define it somewhere in the code.
The automatic analysis preprocessor engine tries to construct one compilable configuration of your code and feed it to the analyzer. It favours the configuration that leads to the analysis of most code and that doesn’t contradict the source file content.
I suggest marking the issues as won’t fix. Modifying the code to make the tool happy defeats the purpose.
To improve the situation, we are working on a way to let the user force a config from the UI to cover such edge conditions(for example, by forcing some macros). It should be available in Q4.
In the long run, we will consider parsing CMake files to get closer to the user-preferred configuration.
Since it is a pretty recent feature, I’m interested in hearing your experience (if you have time):
Why did you decide to move to Automatic Analysis? Usually, users move from Automatic to manual analysis to gain more control.
How was the experience of setting up the project compared to manual analysis?
Thanks, we’ll take these extra details into account and maybe revisit once macros can be specified on the backend.
As for your questions:
Why did you decide to move to Automatic Analysis? Usually, users move from Automatic to manual analysis to gain more control.
It didn’t work for PRs from people without full repo permissions. It took ages (rare if any analysis caching), meaning it’s not only annoying on rapidly changing PRs, but also a waste of resources and more environmentally damaging.
In comparison automatic analysis is triggered and seemingly completed within a minute.
How was the experience of setting up the project compared to manual analysis?
Two clicks on the backend: I just had to click Rescan, because it initially thought more of the project is in other languages, and then the other button to enable it.
One commit to remove our Github Actions workflow.
The setup years ago was of course much more involved, but some of that needs to be done regardless what you start with, eg. the general configuration and weeding out useless rules.
Is the results close to the previous manual one?
Kind of, good enough. There were some things we’ve not seen before like the aforelinked exception handling stuff, I’ve reported 2 different obvious false positives … but it may all have the same underlying cause. Stats:
Yes, compared to the default GitHub action, automatic analysis is expected to be much faster.
I looked closely at the fixed issues in August(date of transition), and most of them are c++17/20 issues. It is due to analysing first with the default C++20 and then moving to C++14. So all the newer standard issues appear as fixed.
I looked at the issues marked as false-positives; some of them are related to different configurations like the one you reported here; the rest are true false positives that we are currently fixing.
As promised, the properties are now available on the project setting page for C++: you can specify the language standard and adjust the preprocessor to force the analyzed variant of your codebase.
For example, I privately analyzed your project after adding preprocessor directives to disable exceptions in FMT and the STL, and verified that all the issues related to throwing exceptions from destructors disappeared:
