Sonar-scanner reports files which are not collected by build-wrapper.exe

SonarQube Server / Community Build
, ,
1

I scan C++ projects. When I look at report, Code tab, I see files which are not built when build-wrapper.exe was running. Files are in subfolder of sonar.sources. I checked content of build-wrapper-dump.json and reported file is not present in dump file.
Why sonar-scanner scans file which are not part of Visual Studio project but they are present in source tree?
FYI
VS Solution consists of about dozen projects. Code is scattered over directory tree but all projects are in same top folder. As a workaround, I could go through source and add exclusion pattern to sonar.exclusions. I was having impression that sonar-scanner collects list of files from build-wrapper-dump.json.

2

Hey there.

You already raised this thread in February, and received an answer.

3

Answer I got is unacceptable.
Now I did new test. Created solution with single project and single cpp file.

#include <iostream>
int main() {
    std::cout << "Hello World!\n";
}

Run build-wrapper.
build-wrapper-dump.json contains ONLY one file reference. It is correct.
I created new Sonar project and specified its key to upload scan. I run sonar-scanner.
I was expecting 4 lines in result but got 91,047 lines of code reported.
I checked dump file. It contains environment, cl.exe command line options and as last argument to cl.exe, filename.cpp.
Hundred of files are scanned even not been compiled. Lot of
#ifdef directives in those files. Since files are not compiled, dump file does not show anything about cl.exe and pre-processor directive. Before compiler compiles file, it is preprocessed. sonar-scanner completely ignores preprocessing step since it checks file content on file system.

Answer I got in March is not true:

  • A file is not fully ignored when the build wrapper has no data for it, but no C++ analysis will be done
    I see report
    Debt: 5d 2h , 68 Code smells, Duplication of 91k lines, 186 Duplicated blocks.

I know how to exclude files. Point is not to exclude file but do correct analyse of the source based on what was compiled by compiler.
Q: How sonar-scanner knows which code block is active?
Each project, or even file could have on preprocessor definition. Some files in VC++ projects may be excluded from build. And so on. Those information can be obtained from build-wrapper dump. json

4

Hello,

I am seeing the same behavior as Zdenko.

In my build, I am compiling a few files from a submodule, which are referenced correctly in the build-wrapper-dump.json but once I run the sonar scanner, the results I see include all source files that are within the submodule, although most of them I am not using in my project and are not included in the compilation process.

According to SonarQube’s documentation:

At the end of your build, a build-wrapper-dump.json file should be generated in the specified output directory. This file contains information about the translation units that were built by your build command. Any file that doesn’t end up in a compiled translation unit will not be analyzed. As a consequence, source files that are not compiled and header files that are not included in any compiled source file will not be analyzed.

So why are all the source files of that submodule analyzed if it specifically mentions that only complied source files and headers will be part of the analysis?

Thanks and best regards,
Dan

5

Hello @Dan_OM,

I’m going to try and reiterate the previous explanation, with the hope that it will be clearer.

When we analyze source code, we analyze it for different purposes:

When we mention the build-wrapper, and the fact that only compiled files are analyzed, this is true, but this applies only to the hearth of the analysis.

For the rest of the analysis, all files in the source folder that are not explicitly excluded are “analyzed” (I say this word in quotes there, because what is done with those is very small compared to what is done in the hearth of the analysis). And by the way, only the hearth of the analysis needs to know preprocessor directives, include paths, compiler version… So it’s not a problem to “analyze” all other files without any information from the build-wrapper.

I hope this is more clear now.

Let me then ask a question too: It looks like you are having an issue with the fact that some files that you don’t compile are still processed (in a very simplified way). Can you explain me what is the problem with that?

Thank you!

7

Hello Loïc Joly,

Thanks for the quick response and thorough explanation! I completely get it now and see it reflected in the static code analysis results: the compiled files do present at least one issue in the report, whereas the non-compiled ones don’t. If I may, I would suggest for the sonar team to specify this in the documentation, to avoid further misunderstanding from us, users.
The problem is mainly focused on the report’s readability for leadership: they would ask why it was reporting “issues” in the unused source files, which back then I didn’t know that they were not analyzed in depth, but now I know and have a good explanation to give about this matter.

Thanks and best regards,
Dan