Suppress issue in C++ source file

Hello,

I am using SonarLint (version 4.34.0.31639) 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
Matthias

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
Volker

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
Matthias

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.

2 Likes

Hello.
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!

Marco

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.

2 Likes

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

3 Likes

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.

2 Likes

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

2 Likes

Revisiting this thread, I’d chime in that this is an extremely important feature for a code analytics tool to have, and I echo the sentiment that it is necessary for source code to be self-documented with any intention of suppressing issues found with it by such tools.

I would very much like to see this addressed if at all possible.

1 Like

Thank you for your comment.
I was already afraid that no other users of this tool recognize this urgent need.
It is still unclear to me why there is so little agreement here.

With kind regards
Matthias Gülck

1 Like

Is there already an update on providing this feature (the ability to suppress specific warnings in the source code)?

1 Like

Any update on this issue? I have the same concerns.

I am a evaluating SonarLint and the other tools with applications that cross-compile to different platforms. I am using SonarLint with the latest VSCode.

Any cross-compilation project will have to conditionally include different include-files for the different platforms. These are usually handled via conditional pre-processor macros using #ifdef and #ifndef which limits the specific include file to the proper platform. However, SonarLint seems to ignore the pre-processor conditional and reports an error that the platform-specific include file is not found on the IncludePath … which is correct but not helpful. The include file does not exist on this cross-compilation.

There needs to be a mechanism to allow SonarLint to ignore the following include file error on the next source line. The “//NOSONAR” comment method would work in my case … but as many others have reported, it is not available on SonarLint.

As mentioned earlier, there is no standard way to disable linters … but that is a weak excuse. “#pragma” is also not fully standard, but they are widely used to control compiler syntax warnings … for example. In the compiler warnings case, gnu and clang use one style, and Microsoft uses another. This two approaches cover a large portion of the market.

Why take the pragma-like syntax for compiler level control and prefix it with “//” to make it a comment … and use that syntax for SonarLint.

Or you can follow the (effective) style used by Synopsys Coverity annotations such as:

// NOSONAR {event-tag-name}

And provide a mechanism to look up the proper event tag name for the “problem”.

If there is no progress on Mathias’s issue from 2 years ago … how do we refresh the issue? Has it been added as a formal feature request?

BTW: Microsoft Intellisense in Visual Studio or VSCode has the same issue with conditionally included include files. There is a specific Intellisense “fallback” setting just for this one case, where the missing include file error can be suppressed (on a workspace or user level).

I am using the SmartLint Extension for VS Code from the VS Code marketplace. It is version 10:01:03. “//NOSONAR” is not available.

Hi @db808,

It looks like you have two problems:

  • One is the fact that you’d like to be able to suppress issues. This thread is the right place for that.
  • The other one is that you don’t get the right configuration for your analysis, which means you have missing headers, but also probably other bad consequences because those missing headers contain information for the rest of the analysis. I would suggest that you open a dedicated thread where you give more details (your IDE, did you configure anything in SonarLint…).

Hope this helps.

Hi Loic,

Thank you for your prompt reply and thoughts.

Perhaps I did not clearly provide the background. Different platforms, such as Windows, Linux, BSD, and proprietary (often real time) operating systems offer a different set of include files. Also, add-on packages often provide their own set of include files.

There is often a relatively standard set of “core” include files for a platform or add-on package, but many products offer extensions and/or alternatives which can be useful to a developer. It is not unusual as software matures that new features (like a high precision time system, for example) are added. Initially, these new features may be exclusive to a platform, but as the feature gets popular (intellectual property not withstanding), these newer features become more available on different platforms. Many of these features are hardware or third party related.

Example … high precision time functions are different on Windows and Linux. Many developers, myself included, have chosen to wrap these platform-specific functions in a more generic function to provide portability across Windows and Linux with high-precision time.

An easy way to write this wrapper function is to use conditional compilation.

Example pseudo-code.

If platform A,
Include necessary unique-to-A include files

If platform B,
Include necessary unique-to-B include files

<Code which is common to both platforms >

If platform A
<code specific to A>

Else If platform B
<code specific to B>

<more common code>

So … how do you conditionally include a header file?

#ifdef WIN32
#include “stdafx.h”
#endif

The stdafx.h file is Windows Visual Studio specific, and does not exist on Linux. Such source will compile properly on Linux, even with full compiler-level warnings.

#ifdef WIN32
#include <windows.h>
#endif

// For Mac OS X
#if defined(__MACH__) && defined(__APPLE__)
#include <mach/mach_time.h>

// Mac OS X is native 64 bit lseeks.
#define lseek64 lseek
#define off64_t off_t
#endif

// headers for block special devices under Linux, don’t exist on Windows

#ifndef WIN32
#include <sys/ioctl.h>
#include <linux/fs.h>
#endif

//Windows and Linux have different names for low-level data types,
// often used by low-level C-compatible OS “system” functions.
// The Linux environment does not define LPVOID by default

#ifndef WIN32
#include <sys/ioctl.h>
#include <linux/fs.h>
#endif

Yes, you could refactor and create smaller platform-specific source files with the proper header includes, without needing conditional compilation. But then you need conditional linking to ensure that the proper sub-routine gets liked in.

Also … it is often advantageous to have the different flavors of similar platform-specific features near each other in the same source file …. rather than in separate source files. In this way, it is easier to understand that the code segments are indeed working the same way.

There are many other examples. In the early days of POSIX …. Many developers wanted to use the more-standardized POSIX forms of functions (such as threads), rather than the “native” thread functions. So you would conditionally test for POSIX, and include the POSIX headers if available, and include the “native” headers otherwise.

In my case … this is the typical reason I use conditionally included header files … to support Linux, MacOS, BSD, and in some cases, Windows in the same source.

So …. Without a mechanism to tell the SonarLint to ignore a missing include file in the next line, I will always get lint errors from SonarLint.

Regards,

Dave B

Hi @db808,

I am well aware of the mechanisms of conditional compilation for cross-platform development. My point is that even if the code is capable of being compiled on several platforms, in different configurations, when you actually compile one file, it is for one platform, one configuration at a time.

SonarLint is no different from a compiler: When it runs, it does not analyze a generic C++ code. It analyses it for a specific configuration and platform, and it will automatically ignore all code that is #ifdefed out.

Exactly how this is done depends on the IDE you are using. In some cases, it’s fully automatic and follows the currently active configuration of the IDE. For instance, if you use SonarLint for Visual Studio, and analyze a file that is part of a classical MsBuild project that targets Windows, only the Windows version of the code will be analyzed.

For some IDEs, you have the give a little help to SonarLint to figure out the configuration.

Apparently, in your case, something is not working as expected, but to understand what and provide you with the intended user experience, we need more information on your IDE, and if you tried to configure something.

Unfortunately, I have to revise my statement.
@SuppressWarnings("squid:S…) does not work at all for C++, because SonarLint aborts with an error message if the corresponding entry is made.
It only looked like it would work partially, since no more errors were displayed.
Nevertheless, it is still incomprehensible to me why this switch was provided for JAVA, but not for C++.
Moreover, there is already a very rough solution for C++ with “//NOSONAR”, which would only have to be refined (not suppress all errors, but only the explicitly specified ones).

1 Like