Feedback needed: Solve c plugin, c++ plugin, CFamily plugin issues

[guwirth]

Hi,

I need your input to decide how to proceed with current c plugin, c++ plugin, SonarCFamily plugin issues.

Issue 1: c plugin is not working in parallel to SonarCFamily plugin because same language key is used.

I see different solutions:

1. Give c plugin an unique language key (e.g. cx).
2. Remove c plugin and support only cxx plugin. Parser is anyway the same; problem is that for c and c++ than no longer different repositories/rule sets can be used.
3. Merge both plugins in one plugin. One parser (squid) with different repositories. Also here we have to define an unique c language key.

Issue 2: cxx community plugin sensors cannot be used for commercial SonarCFamily.

I see different solutions:

1. Sensors should handle reports for community and commercial plugins. Easiest solution is to set onlyOnLanguages("c++", "cpp").
2. Use own language key for squid (c++) and same language keys as SonarCFamily for repositories (cpp). Means both plugins can use the repositories then.
3. Add a new configuration property sonar.cxx.SensorName.onlyOnLanguages to make the supported languages configurable. User can set then sonar.cxx.SensorName.onlyOnLanguages=c++,cpp

The two issues have an impact on each other.

• Do we need c support without c++ (or vice versa)?
• Do we like to add repositories (VC, Clang, Pclint, …) to the default SonarCFamily languages c and cpp?

Any other ideas / hints?

Regards,

[Kristouff]

Hi @guwirth ,
If you can remember, I have been busy on the topic some month ago (#1400). Unfortunately I could not go further in my investigations. I just saw this new thread by chance and if I can make some suggestions, these are the conclusions to which I came during my investigations :

If you look at SonarCFamily plugin, it uses a single plugin (key=cpp) for C, C++ and Objective-C languages. Sonar-cxx could match to this by using a single plugin with a unique key (key=cxx).

**Extract of SQ instance database through REST API (api/plugins/installed)**
{ 
"key":"cpp",
"name":"SonarCFamily",
"description":"Code Analyzer for C, C++, Objective-C",
"version":"6.5.0 (build 12506)",
"license":"SonarSource",
"organizationName":"SonarSource",
"organizationUrl":"https://www.sonarsource.com",
"editionBundled":true,
"homepageUrl":"https://redirect.sonarsource.com/plugins/cpp.html",
"issueTrackerUrl":"https://jira.sonarsource.com/browse/CPP",
"implementationBuild":"6f2aa9c968b3067a320d019a094b9e436b93bb9a",
"updatedAt":1574955498189,
"filename":"sonar-cfamily-plugin-6.5.0.12506.jar",
"sonarLintSupported":true,
"hash":"acf4d971efe071d71d42513ab6b05e2c"
}

For the rule repositories of all plugins (common-c++, valgrind, …), Sonar-cxx could use the same languages as the sonarCFamily plugin (language keys c and cpp, instead of key c++). This would allow sharing the same languages and enabling combining both plugins That's for example how some java plugins seem to be integrated.
Rules applicable to both C and C++ would then have to be duplicated in 2 rules repositories that's also how the SonarCFamily plugin is built.

**Extract of SQ instance database through REST API (api/rules/repositories)**
{ 
"key":"common-c",
"name":"Common C",
"language":"c"
},

{ 
"key":"common-cpp",
"name":"Common C++",
"language":"cpp"
},
{ 
"key":"common-c++",
"name":"Common C++ (Community)",
"language":"c++"
}

Problem is that only one plugin can create a given language. Easiest would be to let SonarCFamily create them but what happens if SonarCfamily plugin is not available on the SQ instance and sonar-cxx is used as a standalone plugin.
A solution would be at instantiation of Sonar-cxx to be able to detect if the SonarCFamily will be available and decide wether languages must be created By sonar-cxx or not. But I don't know if that's possible.
Another question to keep in mind is how to manage issues already present in the databases linked to these key changes on a running instance upgrade.

I hope the explanations are clear and of any help for you.
Regards,

[nathanaelg]

Could you explain a bit more how to use the current workaround for 2? At the moment it seems that if you assign *.cpp etc to the commercial plugin then the community one isn't even picked up by sonar-scanner (so reports from pc-lint, clang-tidy etc don't get in), and if you assign *.cpp to the community plugin you can't use the commercial plugin's analysis and rules.

[guwirth]

Hi @nathanaelg,

The point is that everything need an unique id.

• cxx plugin
• SonarCFamily plugin
• cxx language
• cpp language
• ...

That means scanning a .cpp file with SonarCFamily (language key=cpp) result in another language than scanning it with cxx plugin (language key=c++). At the moment the repositories are also assigned unambiguous to one language. This is why you can't scan a file with the SonarCFamily sensor and assign issues from a cxx sensor.

Regards,

[jmecosta]

imo opinion i dont think we should try to make the cxx and cfamiliy running at the same time. somehow, by braking language keys etc..

imo what people require is the external sensors only, since the gramar (are cxx checks are gone anyway) and metrics is handled by the sonarsource plugin. So if we just create a new plugin that ships the external sensors (no language or grammar or metrics) and attaches the rules to the sonarsource plugin i think its enough.
this way, people in community edition are not affected. and people in developer edition can use the external rules as they want. And, in this case this plugin can even be put in update center since its not competing with the payed plugin only complementing it....

To reduce the complexity of this setup, rules repositories could even be dropped and issues feeded into sonar via the custom issues plugin introduced in new version sonar.

[nathanaelg]

I tend to agree with @jmecosta - I haven't tried the commercial plugin enough to know whether it covers everything in the core community plugin but it does tend to be the external sensors that I'd want to use alongside the commercial plugin.

[guwirth]

PR #2018 is solving this issue:

• Sensors for external reports are supporting languages with keys: cxx, cpp and c now.
• For reading in (indexing) the files, you have to decide whether you want to use the cxx plugin or the SonarCFamily. With SonarQube, file types can only be uniquely assigned to one programming language via the file extension. Several plugins cannot define the same programming language (language key). Therefore the cxx plugin uses cxx as language key and SonarCFamily uses cpp for C++ and c for C. The file extension must be deactivated in the respective other plugin: Each file extension may be defined only once in the sonar.cxx.suffixes.sources, sonar.cpp.file.suffixes or sonar.c.file.suffixes settings.
• The rules are configured consistently in the Quality Profiles under CXX.
• all sensors are still in one plugin

V2.0: This is the simplest solution. Depending on whether "more" is needed, we can add this again in later versions.