Erroneous "Remove this empty namespace" in C++ files in Visual Studio

[cacti77 (Lucas Partridge)]

Using SonarLint for Visual Studio 2019 v4.24.0.20196 in MS Visual Studio Professional 2019 v16.6.5.

In Visual Studio many of my C++ files have the “Remove this empty namespace” warning next to namespaces that are patently not empty! All the lines in these files have green squiggles under them which makes the files difficult to read. Strangely, some of the C++ files without empty namespaces don’t have this warning, as I would expect, but it’s not obvious what’s different about those files.

When I look at the same files in SonarQube they do not have this issue, as expected. SonarLint has been configured to point at the same project settings on our SonarQube server.

Has anyone else seen this? A workaround to temporarily disable this warning other than completely disabling the SonarLint extension in Studio would be nice. I guess one option would be to temporarily relax the rule for empty namespaces in the SonarQube server too.

Note - restarting Studio doesn’t cure this, and it occurs in a team-mate’s Visual Studio too.

[Abbas_Sabra]

Hello @cacti77,

Can you share a screenshoot of a simple example where this rule is incorrectly triggered?
I tried to reproduce on my side but it is working well:

Thanks,

[cacti77 (Lucas Partridge)]

Many thanks for looking at this. The simplest I’ve been able to come up with that reproduces it is this:

Obviously it’s not valid code but maybe that’s what triggers the issue - another issue inside the non-empty namespace? Sorry, this is the best I could do in the time I had.

[Abbas_Sabra]

@cacti77,

I can reproduce it. It seems to be only related to namespaces that contain only invalid declarations.
I created a ticket to fix it.
Thanks for spending the time to provide a reproducer. This is helpful!

Thanks,

[cacti77 (Lucas Partridge)]

Thanks @Abbas_Sabra! I’m glad you found a better example because in the real code where it’s occurring there are no compiler errors and huge amounts of code (all with green squiggles!), but I couldn’t spot what was causing it.

[Abbas_Sabra]

@cacti77,
if you think that the issue in your real code is different, you can generate a reproducer file and share it(privately if you prefer) and we will be able to reproduce the same scenario. Here is a link to the documentation on how to generate a reproducer file.

Also, there is a rule with ParsingError as a key. You can enable this rule(through SonarLint json setting/ or SQ instance) to make sure that there is no parsing error in the code where the false-positive is happening.

[cacti77 (Lucas Partridge)]

Thanks. I’ve produced a reproducer file from a massively cut-down sample of the real code that still shows the problem in Visual Studio. How can I share it with you privately please?

[Abbas_Sabra]

@cacti77 I sent you a private message where you can upload it

[cacti77 (Lucas Partridge)]

Ok, done.

[cacti77 (Lucas Partridge)]

After further investigation with @Abbas_Sabra it seems another issue is that the SonarLint plugin is incorrectly interpreting relative paths in the Additional Include Directories entry (under C/C++ > General) of each C++ project’s settings in Visual Studio. SonarLint seems to be looking for header files relative to the source .cpp file that #includes the header, rather than relative to the directory containing the project’s .vcxproj file. The header file is consequently not imported and hence the code inside the namespace appears invalid to SonarLint.

The workaround is either to use absolute paths in each project’s Additional Include Directories entry, or to prefix the relative path values with $(ProjectDir)\.

[Abbas_Sabra]

@cacti77,

Thanks for providing the reproducer and all the needed information to debug the issue.
Indeed SonarLint isn’t resolving relative include directory correctly. I created this ticket to fix the issue.
Will keep you updated.

[cacti77 (Lucas Partridge)]

@Abbas_Sabra - you’re welcome. Thanks for your support and suggested workaround:). Looking forward to seeing the fixes to both tickets in an updated plugin.