How to work around S5912 detection (object slicing)

Sometimes it is needed to explicitly slice. (This is even suggested in the sonarlint rule itself!)
However, when this is done explicitly as suggested by the rule,
Sonarlint still warns on it.
The warning from visual studio itself can be suppressed with [[gsl::suppress(es.63)]], but since sonarlint has no in-source suppression, there is no way to handle this currently?
Here is a minimal reproduction:

struct slice
{
    int a1 = 0;
};

struct example
    : private slice
{
    int a2 = 0;

    slice get_slice() const
    {
        [[gsl::suppress(es.63)]]
        return *this;   // Sonarlint warns about cpp:S5912 here
    }
};

Edit:

  • Operating system: Win10 22H2
  • Visual Studio version: 2022 Community v 17.7.4
  • SonarLint plugin version: 7.3.0.77872
  • Programming language you’re coding in: c++ (17)
  • Is connected mode used: no

Hi,

Welcome to the community!

Could you tell us your SonarLint version and what language this is for?

 
Thx,
Ann

Sorry, I missed out on attaching that info.
I have edited the first post, and here is the info as well:

  • Operating system: Win10 22H2
  • Visual Studio version: 2022 Community v 17.7.4
  • SonarLint plugin version: 7.3.0.77872
  • Programming language you’re coding in: c++ (17)
  • Is connected mode used: no
1 Like

Hi,

Thanks for the details. The current version is 7.7.0.86423. Could you upgrade and see if this is still replicable?

 
Thx,
Ann

1 Like

Using 7.7.0.86423 this issue is unchanged:

image

Hi,

Thanks for checking. I’ve flagged this for the language experts.

 
Ann

1 Like

Hi @Mark_Jansen and welcome to the community,

Unfortunately, as you mentioned, in-source issue suppression is not supported at the moment, but a solution is coming soon, see here. For the time being, I can suggest the following:

  • As described in the rule description, when slicing is actually required, we recommend having a dedicated member function to make the intention clear (as you seem to be already doing :smile:).

  • If you are already using SonarQube or SonarCloud to scan your project, you can use connected mode to synchronize accepted issues on the server (so that they are not reported on SonarLint).

  • You can also disable the rule from SonarLint as a workaround, but I wouldn’t recommend it for this rule in particular. Instead, having a dedicated function where the rule is violated generally makes the code clearer.

Thanks for sharing your question, and feel free to vote and provide feedback on the linked productboard card.

Best regards,
Michael

Thanks!

Yes, I made this a dedicated function because sonarlint recommended it, and I assumed that because sonarlint recommended it, there would not be a warning inside a dedicated function.

The solution you link to does seem to suggest that it is for connected mode?
I am not using connected mode because the simplicity of the extension (just install it and it works) is more convenient than having to setup a service for Sonar, and connect to that / keep it up to date and what not.

Regards,

Mark.

Hi @Mark_Jansen,

The recommendation is to isolate slicing in a dedicated function so that this single violation of the rule can be accepted on SonarQube or SonarCloud after a review.

I think that it is still worth raising a violation here, because the fact that the function only has return *this; doesn’t necessarily imply that the author intended slicing to happen here (they might have just used the wrong return type for example). The only way to ensure that intention is clear, is by doing a review, and accepting this single violation.

Thank you for sharing your feedback though, I will also check with the team to see if we want to revisit this decision…

You are right, the card I shared earlier describes a solution that we are currently working on, where you can silence an issue without adding product-specific attributes that may reduce code readability. Instead, the issue is accepted locally, and this is synchronized among all collaborators by leveraging connected mode.

If you are more interested in in-code issue suppression, you may find this discussion relevant. We are still having discussions about this subject, and we may provide a solution soon. Stay tuned!