SonarLint has/enables aditional rules that does not exist on SonarQube on premise server

[at185190]

Description

Happy to see that SonarLint now supports C++ connected mode, but it appears that SonarLint reports on issues/rules that doesn't exists on SonarQube server. I assume this is default behaviour to enable rule if it information about is not available from Sonar Cube, but I believe by default rule should be off.

It's great and all to get access to new rules, but if that's what we wanted, we would not have ability to enable or disable rules. Reason to use SonarLint is so you know you resolved or saw issues before they popped up on SonarQube, that is much harder when SonarLint reports on new rules, some of which I know we would disable, thus still making SonarLint hard to recommend to be used by the team

Repro steps

1. Install latest SonarLint

2. Connect to 7.9 (July 2019) LTS on premise hosted sonar cube server

Expected behaviour

Only issues for rules that are enabled on Sonar Cube server are displayed, new rules available to SonarLint, but not yet existing on SonarCube, should not be enabled.

Actual behaviour

Issues for rules which does not exists on Sonar Cube server are displayed. SonarLint is a year ahead, thus has access to new rules, 480 for c++ compared to 446 available on ours on premise SonarQube.

Known workarounds

None

Related information

• SonarLint for VS Version: 4.27.0.22695
• Visual Studio Version : Professional v15.9.26
• SonarQube server version: 7.9 (July 2019) LT
• Languages in your solution: C++

[duncanp-lseg]

@at185190 thanks for the feedback. cc-ing @marco-comi-sonarsource for info.

Yes, that behaviour is by design: if SonarLint is using a newer version of CFamily rules than SonarQube then any of the new rules that are enabled by default will be executed by SonarLint.

There isn't currently any simple way round this, short of not using connected mode and manually configuring the rules to execute. This would have to be done manually on each machine. The format of the local settings file is the same as the one generated in connected mode so at least you'd be able to use that as a starting point, but it's still not a great solution.

I can think of a few options we could implement:

1. disable all newer rules in connected mode;
2. add an option to allow users to choose to opt in/out of running newer rules. This is an all-or-nothing option; if there was one newer rule you didn't want then your only choice would be to opt out of all rules.
3. allow the standalone rules settings to override connected mode settings, either for all rules or just for new rules. This would give a fine-grained approach, but would require the configuration to be done on each machine. Combining (2) and (3) would allow fine-grained choices when required while minimising the amount of configuration to disable new rules.