Operating system: Windows 10 Enterprise, 10.0.19042
SonarLint plugin version: 7.3.0.77872
Programming language: C/C++
Is connected mode used: Yes
Connected to: SonarQube Developer Edition 9.9.0.65466
I have a problem that SonarLint will use the C quality profile instead of the C++ quality profile for some header files. The verbose log shows this (sensitive information redacted):
[ThreadId 17] [DEBUG] [CompilationConfigProvider] Reading compilation database from '***\compile_commands.json'
[ThreadId 17] [DEBUG] [CompilationConfigProvider] Header file detected, searching for matching code file. File: ***\ABC.h
[ThreadId 17] [DEBUG] [CompilationConfigProvider] Header file: using first entry: ***\EFG.c
[ThreadId 17] Loaded settings from "***\AppData\Roaming\SonarLint for Visual Studio\Bindings\***\c_settings.json".
As far as I understand SonarLint will look for a .c or .cpp file with the same name as the .h file. If none is found it will take the first entry from the compile_commands.json file and whatever language the first file has, this language will be used for the analysis of this .h file.
The first entry in my compile_commands.json file is unfortunately a .c file. The header file has C++ code in it and is then checked against the C quality profile which is wrong. No findings are found with SonarLint but in SonarQube the right quality profile is applied and the C++ issues are found.
What is the exact algorithm if no .c/.cpp file with the same name is found and how can I fix this?
I am very grateful for any help!
Header files don’t have an entry in the compilation database, so we built a basic heuristic to deduce one reasonable entry. Here is how it works in Visual Studio CMake mode:
An entry with the same filename and different extension in the same directory a.h + a.cpp -> a.h is C++ and a.h +a.c -> a.h is C.
An entry with the same filename and different extension in a different directory
Entry with the same directory
If all fails, we use the first entry in the compilation database
There are ways to improve this heuristic, but in the end, it can never be perfect for everyone. I suggest working around It by leveraging the information I shared or by adding a fake entry.
Thank you @Abbas for the clarification. What if I renamed my .h files to .hpp and change my code accordingly. Would they then be analyzed with the C++ quality profile since these files are in the C++ file suffixes list?
@tabbse, I had a quick look at the implementation, and no unfortunately the extension of the header file isn’t taken into consideration. It is the same logic I described above independent of the unfound entry extension.