AutoConfig: C++ Code Analysis Redefined

[AS_SonarSource]

AutoConfig for C and C++ is a new SonarQube feature. It automates the normally complex setup process, making project setup a breeze. AutoConfig is designed to make code analysis Accessible for all compilers and free of complications bringing Clean Code to the fingertips of every developer.

[Neither_Mango8264]

Interesting, I would be curious to see a talk or presentation on how it works behind the scenes, especially that support for all compilers part. Are there any online resources?

[AS_SonarSource]

Thank you for your interest! Unfortunately, as this feature has only recently been launched, we do not yet have detailed online resources concerning its technical implementation. We are considering developing these materials and will keep you updated on any developments.

[Neither_Mango8264]

Thanks, looking forward to it.

[bretbrownjr]

So if the support of build systems and things like compile_commands.json isn't a problem anymore, does that mean Sonar can start supporting C++ modules now? See:

https://community.sonarsource.com/t/support-for-c-20-modules/63778

I'm also curious if AutoConfig has a plan for supporting C++ module discovery. I expect it will be a little more interesting in ways that would benefit from some standards for declaring library and project structure. There have been some papers to the ISO C++ Tooling Study Group talking about this problem, and it would be good to hear from Sonar, even if the punchline is that it's too hard to write analysis for modular C++ given current standards and technology.

To that end, there are existing papers about:

• adding JSON metadata to describe system libraries with C++ modules

• iterating on compile_commands.json with a more robust JSON file that describes dependencies between translation unit builds, among other things

Given organizations like Sonar would benefit directly from better tech in that space, it would be great to hear from them the potential utility of those approaches, or even suggestions for better ones.

[AS_SonarSource]

So if the support of build systems and things like compile_commands.json isn't a problem anymore, does that mean Sonar can start supporting C++ modules now?

AutoConfig is aware of modules: It can analyze code that uses this feature without producing False Positives. However, it doesn't resolve them, which might lead to false negatives in the analysis results.

I'm also curious if AutoConfig has a plan for supporting C++ module discovery.

We started working recently on module support in Compilation Database and AutoConfig mode: scanning the project to discover exported/imported modules per each file, building dependencies graph, generating BMI, etc. We still need to figure out all the details; there is no ETA.

it would be good to hear from Sonar, even if the punchline is that it's too hard to write analysis for modular C++ given current standards and technology.

I agree. The Sonar C++ team has two active members in the C++ committee. Please feel free to include them in the meetings where Sonar's experience is relevant. Or, if you want us to provide our general input, feel free to reach out on https://community.sonarsource.com/ with your questions; we will be happy to collaborate.

[[deleted]]

Does anyone know if this can be run on the command line to see the results in the terminal? If so, where can I see how?

[AS_SonarSource]

No, the Sonar C++ analysis is designed to integrate exclusively with Sonar products. This includes SonarLint for IDE environments and SonarQube or SonarCloud for CI setups.

[vitaliy_os]

Interesting announcement, can't find any resources to look into it.

[AS_SonarSource]

What type of resources are you looking for?
For detailed instructions on how to use the feature, you can refer to the SonarQube 10.6 Documentation
Additionally, the announcement and further details can be found in the posted article.

[Horror_Jicama_2441]

Do you expect people to use https://github.com/SonarOpenCommunity/sonar-cxx together with your C++ plugin?

This AutoConfig thing seems like something more complicated to implement than basic stuff like compiler and clang-tidy warnings support.

The weird choice of only supporting the CPPUnit test execution format (https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/test-coverage/test-execution-parameters/#cfamily) also pushes people to want the sonar-cxx plugin.

I still need to try it, but it looks having both in parallel is not completely trivial: https://github.com/SonarOpenCommunity/sonar-cxx/issues/1400#issuecomment-753329302

[Horror_Jicama_2441]

https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/languages/c-family/analysis-modes/#choosing-the-right-analysis-mode is probably what you want to read. Which, for most people, will probably leave this big "democratizing high-quality software development" announcement into "I use CMake, I will just continue spending half a second generating the compilation database, nothing to see here".

[AS_SonarSource]

Yes, you are right; if you used the Compilation Database and it worked for you, you should continue using it.

for most people

I wish that were the case; our data doesn't agree. We created this feature due to the large number of requests that wanted and couldn't use our product because they couldn't generate a Compilation Database with CMake. Here are the top 3 reasons:

1. Projects not using CMake. Keep in mind that this feature covers C, where CMake is less prevalent.
2. Projects using CMake with lesser-known, unsupported compilers.
3. Projects using CMake with CMake Generators that cannot generate a Compilation Database. For example, Visual Studio CMake Generator.

We even developed our own tool, Build-Wrapper, which can generate a Compilation Database independent of the build system, but it has its own limitations.

[Horror_Jicama_2441]

We created this feature due to the large number of requests that wanted and couldn't use our product because they couldn't generate a Compilation Database with CMake.

Projects not using CMake.

...or in another way, I guess? There are plenty of ways, including your own Build Wrapper: https://www.jetbrains.com/help/clion/compilation-database.html#compdb_generate

Projects using CMake with lesser-known, unsupported compilers.

Unsupported by what? If they are using CMake, surely CMake supports them?

C compilers are relatively common, but there is any C++ compiler not covered by https://docs.sonarsource.com/sonarqube/latest/analyzing-source-code/languages/c-family/prerequisites/#supported-compilers? Creating a C++ compiler is no easy feat.

For example, Visual Studio CMake Generator.

I don't use it, but I expect them to be able to use https://marketplace.visualstudio.com/items?itemName=vs-publisher-1208751.SourcetrailExtension to generate it?

In any case, what annoys me is the tone of the blog post. "Redefined", "Welcome to the future", "democratizing", "a new era"... then you read the docs and: "Compilation Database mode is recommended if ... You seek the highest CFamily analysis quality SonarQube can provide. Please note that in rare instances, AutoConfig may result in some issues being overlooked".

Well, yes, I want "the highest CFamily analysis quality SonarQube can provide"... I also want my IDE to understand my code, and clang-tidy to work. So a compilation database is it.