sonar.cfamily.reportingCppStandardOverride handling with SonarLint

Must-share information (formatted with Markdown):

  • Running Sonarqube 10.4.1
    I am trying to make analysis on server and in IDE return the same results.

My configuration file has reportingCppStandardOverride set up to C++14 since our code currently needs to compile for both C++14 and C++17. However, when analyzing using Sonarlint this setting is not available. The setting would probably carry through if I set it up in the web interface but…
Eventually we will switch our main branch to only use C++17 but from time to time we will have to do work on old branches. In those cases the results from Sonarlint will be polluted with C++17 findings. Is there a way to make sonarlint pick up the settings from the configuration file?

Hey there.

Which IDE are you using SonarLint with?

A minor detail :slight_smile:
We are using Visual Studio Code.

Thanks!

Unfortunately, what you have set in a sonar-project.properties file (regarding sonar.cfamily.reportingCppStandardOverride) won’t be taken into account for analysis. You can, however, edit your settings.json file found below:

{
    "sonarlint.analyzerProperties": {
        "sonar.cfamily.reportingCppStandardOverride" : "c++14"
    }
}

I recognize this isn’t ideal for sharing configuration amongst your team or on-the-fly when switching between branches, but at least it should kill some noise.

Thanks for the answer Colin.
Wouldn’t it make sense to take these settings from the sq configuration file which is most likely contained in most repositories?
I had the same issue as this with excluded folders and although that is quite static, changing the settings in the web interface makes it impossible to have version control of the settings.

Kristian

Hey @kkroier

That’s a fair question! I asked our developers.

  • Today, we read in some info from a sonar-project.properties file to .sonarcloud.properties file to suggest connected mode configuration
  • We don’t read in anything that effects the analysis, assuming that should be configured in the Web UI if it’s to be shared
  • At the same time, you’re right, some folks really prefer to store this as code or have branch-specific configuration

I’ll flag this as an insight that we should record, but I don’t expect anything short-term here.

Hi Colin
Thanks for the reply and the follow-up with the developers.
I think it would be a valuable addition to at least have the options for some of the setting to come from the config file as it would be helpful with workflows similar to one I am part of.

Kristian

1 Like

Dear Kristian,
Thanks for sharing the importance of this for you. We indeed see how it can be needed for several languages. Although it’s not something that is on our roadmap at the moment, we kept a record of this and continue to look out for similar requests. We’ll update this thread if anything changes.