Hundreds of obvious false positives

[Slavomir_Kucera]

I’ve recently received suggestions from the sonarcloud scan related to ‘Member functions that don’t mutate their objects should be declared “const”’ rule for functions that are STATIC and also for functions that are very obviously modifying members.
Similarly, ‘Pointer and reference parameters should be “const”’ if the corresponding object is not modified"’ is triggered for out parameters.
Additionally, rule “Inherited functions should not be hidden” is being triggered by virtual function override.

[Colin]

Hey @Slavomir_Kucera

Thanks for joining us in our Community. Please review this post regarding reporting false-positives

How to Report a False-positive / False-negative

Hey SonarSource Community! False-positives happen, as do false-negatives, and we’re eager to fix them. We are thrilled when our users report problems, so we can make our products better. What is a false-positive (FP)? A false-positive is when an issue is raised unexpectedly on code that should not trigger an issue, or where the suggested action doesn’t make any sense for the code. What is a false-negative (FN)? A false-negative is when an issue should be raised on a piece of code, but isn’t…

Specifically:

We also need you to include a code sample

This code sample should either be:

• code-as-text. Not a screenshot of code or a screenshot of an issue raised in SonarQube.
• Or a link to code that raises the issue on a public SonarCloud project

We’ll be happy to investigate further once we have all the required information.

[Slavomir_Kucera]

This is the report, the issues are partially flag as false positives.

https://sonarcloud.io/summary/new_code?id=eclipse_che-che4z-lsp-for-hlasm&pullRequest=226

[Slavomir_Kucera]

Hi @Colin

did you manage to identify the cause of the problem from the report I posted?

Thanks,
Slavek

[JolyLoic (Loïc Joly)]

Hello @Slavomir_Kucera,

I had a look of the issues you reported, they fall into 3 rules:

• S5817 Member functions that don’t mutate their objects should be declared “const”
  In your examples, this rule reports for static function, while it should not.
• S1242 Inherited functions should not be hidden
  In your examples, this rule reports for simple overriding functions, while it should not
• S3923 All branches in a conditional structure should not have exactly the same implementation
  In your examples, this rule reports while both branches are significantly different.

In all cases, we report something that is obviously a false positive that the rule is written to ignore. Why?

My best guess is that when we try to parse your code, we have parsing errors. Because of these errors the code that we analyze is not really your code, but some sort of output of some error recovery process, which could explain those false positives.

To go to the next step:

• You can try to understand those parsing errors on your own. You can use -X on the command line or sonar.verbose=true in the configuration, the ParsingError will be visible in the output.
  Note the the goal is not to solve all of them, but only the ones that have an impact on your code
• Or you can send us more information so that we can look at it more efficiently. For us, the best is to create a reproducer file that you then send us:
  • Search in the analysis log for the name of the file for which you want to create a reproducer. You will have to use exactly this name (case, / or \…)
  • Set the property sonar.cfamily.reproducer to this value
  • Launch a new analysis. It will fail and generate a reproducer file that you can then send us.
  • If you want to sent it privately, let us know, we’ll send you a private message.

Note: We saw that you are using 2 different steps to analyze the code. This is a common source of errors. As the documentation says:

The Build Wrapper collects information about the build including absolute file paths (source files, standard headers, libraries, etc…). Later on, SonarScanner uses this information and needs to access those paths. Whereas this is straightforward while running these 2 steps on the same host, it is worth some consideration when using any sort of containerization.

[Slavomir_Kucera]

Hello @JolyLoic,

I actually solved the problem (and forgot to mention it here). The problem was caused by mismatch between the environments for build and analysis that led to parsing errors.

Would it be possible for SonarCloud to include this detail about parsing failures in the (full) analysis report? Just a simple “Encoutered xyz parsing errors.”/“No parsing errors.” would be great.

[JolyLoic (Loïc Joly)]

It’s not so easy, because some parsing errors are benign, and unavoidable: We are analyzing code that may use some compiler extensions which we don’t understand.

As a consequence, we are reluctant to show parsing error too prominently, making people believe they should correct or report all of them.