Sonar failing to identify issues in PRs

SonarQube Cloud
1
  • ALM: GitHub
  • CI: Jenkins
  • Scanner: sonar-scanner-cli-5.0.1.3006
  • Languages: C++, Python, SQL, Rust, C#
  • Observed issue:

Sonar fails to detect obvious issues, even though the rules is activated, and the code is detect as changed. For instance:

// This should be flagged as code smell, as we require `enum class`
enum TestEnumWhichShouldBeFlaggedAsError
{
    INVALID_ENUM
};
inline int foo() {
    auto test = new int[10]; // should also be flagged
    return test[0]; //TODO remove this
}

This should raise multiple issues. The code is detected by Sonar as changed, but no issue is raised.

Note that non C++ issues are correctly flagged.

2

The file in question (Foo.h) is part of a mixed C/C++ project. I find that that file turns out to be classified as “C” code by Sonar, not C++ (which it is). This is suprising, because it is included by a file correctly classified as C++ (Foo.cpp).

Thoughts:

  • Sonar has access to compile_commands.json, so it should get the language right
  • The header won’t appear in the compile_commands.json though
  • The PR in question only changed the header file. Could it be that SONAR isn’t even scanning Foo.cpp, and thus doesn’t scan that included header as C++, but as C, and this is the issue?
3

Update: even if I force Sonar to treat .h files as C++ rather than C code doesn’t fix the problem.

4

Hi,

My understanding is that whether headers are analyzed as C or C++ depends on the files they’re included in. So is your .h file being used only by C files? By C++ files? Both?

 
Ann

5

The project contains a mix of C and C++, but the files in question is C++ only, and are included by C++ code, not C.

I’ll try to send you further information per private message, as I’m not authorized to share this in public.

7

Hi,

I’ve flagged this for the language experts.

 
Ann

8

Thank you Ann,

FYI: I have now deleted the project on SonarCloud, and recreated it with the same settings. I did that because maybe the cache on SonarCloud was corrupted, and doing this allows me to test that.

I’ll report back.

10

@ganncamp : So deleting the project and running the scan on main (baseline) and a PR introducing issues that are properly flagged in the VSCode Sonar-Lint extension, and which are neither accepted nor disabled in our profile, still fail to be flagged on the PR.

12

Thanks to @michael.jabbour’s analysis, it was established that the culprit was the compile_commands.json file. We were using so-called “unity builds” for CMake to speed up compilation. In this configuration, CMake will bundle several source files by including them into generated temporary sources. It turns out this is not compatible with SONAR (because these temporary source files aren’t even in the source folder).

Switching to a special, non-unity build, setup for SONAR seems to fix the issue.

Thank you.

1 Like
14

Thanks @dgehriger for following up, we appreciate it.

This seems related to this CMake issue: CMAKE_UNITY_BUILD and CMAKE_EXPORT_COMPILE_COMMANDS (#19826) · Issues · CMake / CMake · GitLab.

As far as I could see, there are no workarounds other than invoking cmake twice: once to generate a compilation database with CMAKE_UNITY_BUILD=OFF, then once to actually build with CMAKE_UNITY_BUILD=ON.

Best regards,
Michael