Suppress issue in C++ source file


I am using SonarLint (version in ConnectedMode with SonarQube (Enterprise Edition, version 8.1 (build 31237)) under Visual Studio Professional 2017 (version 15.9.36).

Now I’ve been looking for some time for a way to disable a single warning reported by SonarLint/SonarQube in a C++ sourcefile.
Unfortunately I haven’t found anything about this in the FAQs.
All I have found so far is the possibility to exclude a line with “//NOSONAR” from the analysis. However, this comment only affects the result of SonarQube. SonarLint still reports the warning.
Moreover, the solution “//NOSONAR” is too radical for me.

Surprisingly, @SuppressWarnings("squid:S…) works for both SonarLint and SonarQube in a C++ source file, but unfortunately this is not a solution, since Visual Studio’s IntelliSense, and of course the compiler, consider this as an error.

Hence my question:
How can I disable an Error/Warning/CodeSmell in the C++ sourcefile or for SonarLint and SonarQube for a single line?

Many greetings

Same question from my side for C files. in PCLint it is possible to disable single errors in a line with special comments.

I hope that SonarQube supports something equal.

Best regards

Thanks for your reply!

I have been using PCLint for about 30 years.
Since disabling messages down to line level is there from the beginning, I expected to find a corresponding option also in SonarLint/SonarQube.
For JAVA code this is possible with @SuppressWarnings("squid:S…).
As already mentioned, @SuppressWarnings("squid:S…) also works in C++ files, but of course IntelliSense and the compiler do not understand this construct.
Did the developers of SonarLint/SonarQube simply forget to transfer this feature to the C++ world here?

Many greetings

I moved this thread to feature suggestion so that people can vote for it.

That means, that actually this feature is not included?

I really regret my decision for SonarQube in the meantime.

Do we really need to vote for a function that exist naturally in other static code checkers (e.g. PCLint for C++, pylint for Python) and even in SonarQube for JAVA?
I was hoping that it would be possible to enable this feature also for C++ under Sonar:int/SonarQube, especially since a possible solution by using a keyword like "@SuppressWarnings(“squid:S…)” already works (but of course not for the compiler in this way).
Other static code checkers simply wrap this construct in a special comment (PCLint: “//lint…”, pylint: “# pylint:…”).
Wouldn’t such a solution be conceivable for SonarLint/SonarQube as well?

With kind regards
Matthias Gülck

To be honest, I don’t know of any static testing tool that doesn’t have this feature. Therefore, I would also agree with Matthias that this functionality is mandatory and should not be voted on first.

Hello @Matthias.Guelck and @vokuit00,
let me add a few more info on what we currently support.

In SonarQube it is quite easy to suppress an issue in SonarQube:

(note that you can choose to mark it as Won’t Fix of False Positive depending on the case)

Once you do that, thanks to the connected mode, your suppression will be automatically propagated to SonarLint and you won’t see anymore this issue reported in the IDE.
Please note that this the approach we promote to suppress individual issues, it is totally language agnostic, it does not add comments to your sources and easily exchange on the suppression reasons with the other collaborators.

As an alternative approach, in SonarQube you can use the //NOSONAR comment; please note that if you have multiple issues on your code line, this mechanism will suppress all of them. This is not the approach we recommend, for this reason this has not been ported to all SonarLint flavours yet, and specifically this is not supported in SonarLint for Visual Studio yet.

For more information see the first section in the SonarQube FAQ page here.

I am really interested to know whether the first approach I proposed above works for you; in the opposite case, it would awesome to understand what are your needs or expectations that are not covered by our approach.

Thanks in advance!


1 Like

I would also add that even though from an end user point of view it looks like a no brainer, from a maintainer point of view it is a feature that has to be prioritized, among others.

For historical and organizational reasons, this feature is not supported at the same level for all languages. The main reason is that we want it to work the most natural way for each language.

And here, even though comment-based issue suppression is a common feature of other linters, as far as I can tell there is no standard way to do this in C++, compared to Java’s @SuppressWarnings annotation or Python’s #noqa comments.

So this is definitely an area where we’d love to get constructive user input, to make sure that the feature matches your expectations and is prioritized correctly.

1 Like

Hello @Marco_Comi, hello @JBL_SonarSource,

thank you very much for your detailed answers.
Of course I am familiar with the solutions “//NOSONAR” and suppressing error messages in the SonarQube WebUI.
After all, the solution “//NOSONAR” already shows that a solution to my problem has been thought about.
It seems that someone found it very handy to be able to suppress an error reported by SonarQube directly in the source code. Unfortunately, this solution is too drastic, as it disables all errors in this line. Furthermore it does not affect SonarLint as described.
But since this option is basically already established, it would only need to be refined.
The advantages of such a solution:

  1. Everyone who reads the source code, sees immediately that at this point a special problem exists, about which one however exactly thought.
  2. When revising existing source code, one can directly deactivate the errors displayed by SonarLint, if one does not want to change the working source code at this point. This is much faster than starting a run with SonarQube, then opening the SonarQube WebUI, looking for the error there, and then disabling it.
    If the same error occurs in many places, this can even be solved quickly by search/replace!
    This can be a significant relief for large projects.
  3. If one suppresses an error reported by SonarLint/SonarQube directly in the source code, then this survives any merge operation and any rollback with a version control system.
    This is not guaranteed by the solution via the SonarQube WebUI as far as I know.
  4. If this source code should meet certain guidelines that should be checked by an external person, then it is helpful to explain the specifics of a certain section in the source code right there, and not to have to provide a database with these explanations additionally.

What I also haven’t understood yet:
If this possibility exists, e.g., for JAVA, why should one not be able to use this advantage also in C++?

With kind regards
Matthias Gülck

Thanks @Matthias.Guelck for sharing your expectations. Ideally we would like to provide a solution to suppress individual issues directly in the IDE. Now, this can be done either via comments / annotations in the code or in different ways, for example with via contextual actions like “Suppress this issue”, “Suppress all occurrences of this issue in this file”, etc. that store the suppression data outside the source code file; I understand from your comments above (especially 1. and 4.) that your preference goes for a mechanism that is directly visible in the source code. And if I read you correctly, although the //NOSONAR approach is too drastic as it suppresses all issues in one line, it could also be a step into solving (at least partially) the problem you raised.

So as a first step, we will add //NOSONAR gap for C++ in Visual Studio; to be clear - this is not the optimal solution - the intention here is simply to close a gap since this is supported in SonarQube and in most IDE/languages combinations for SL. We opened a ticket that you can follow here.

We will post an update here if we reach a conclusion on a better, more fine-grained suppression solution; in the meantime further feedback / suggestions are welcome.

1 Like

Hello @Marco_Comi,
from my point of view there is a major disadvantage if information like “Suppress this issue” or “Suppress all occurrences of this issue in this file” is stored outside the source code.
I have described this disadvantage in my listing under 3:
When merging or rolling back with a version control system, this information is lost!
But if this information is stored in the source code, it can NOT be lost.

With kind regards
Matthias Gülck