cppcheck: missing rule `unmatchedSuppression`

[gerboengels]

Since commit 044c1831 (PR #1837) a number of cppcheck-rules are lost, like unmatchedSuppression. This was probably because of the cleanup mentioned in that PR, as this rule is not present in the cppcheck --errorlist output. However, I do get this error in my cppcheck output (cppcheck 2.8).

I don't know if it should be filed as a cppcheck bug (missing output from --errorlist), or sonar-cxx should hardcode this rule in the rulelist.

Same goes (at least in my case, there might be more) for errors unknownMacro, internalAstError, syntaxError and cppcheckError, although you could argue those are more configuration errors than code analysis results.

By the way, I had some trouble investigating this issue. The logs said Processing successful, saved new issues=61 (which is the number of issues in my xml), but none of them appeared in Sonar. Even when scanning with sonar-scanner -Dsonar.verbose=true -X the logs didn't mention that these 61 issues couldn't be matched against a rule. That would have saved me some time investigating.

CXX version 2.0.7.

[guwirth]

Hello @gerboengels,

unmatchedSuppression, unknownMacro, internalAstError, syntaxError and cppcheckError

These "errors" sound more like internal CppCheck errors/warnings/hints than static code analysis issues? I'm not sure if they should be visible in the SQ UI (or better just in the LOG file)?

The logs said Processing successful, saved new issues=61 (which is the number of issues in my xml) ... didn't mention that these 61 issues couldn't be matched against a rule.

This message is from the scanner on the scanner side. Not sure if the scanner is able to find out which rules are activated (available) on server side? This needs to be investigated further...

Regards,

[gerboengels]

These "errors" sound more like internal CppCheck errors/warnings/hints than static code analysis issues?

I agree, except for unmatchedSuppression: the whole reason a suppression ends up in the code is because of static code analysis. An issue was reported in SQ, and for some reason we (try to) suppress it. Maybe the suppression is (or becomes) misplaced (wrong line), contains a typo, or it became unnecessary (like when a false positive is fixed in a newer version of cppcheck). Then I'd like to be informed about that, so I can fix it or clean up my code.

Our team found this unmatchedSuppression to be quite useful in the SQ UI when we were using the older version. So therefore we miss it right now (we rarely look at the cppcheck logs itself, because we trust issues to pop up in SQ UI, so it took quite some time before I noticed these unmatched suppressions weren't reported anymore). I do understand it's a bit of a gray area, so if you think it is more of an internal CppCheck hint and close this issue, that's ok. I just wanted to give my thoughts and experience when using the old version :)

[guwirth]

Hi @gerboengels,

In principle, it would be no problem to add the "internal messages" back into the list. The question is how to get a complete list of the internal messages? With cppcheck --errorlist it doesn't work? Then everyone could decide for himself if he wants to see the issue or not.

For issues SQ knows in principle three output possibilities:

• message in the scanner LOG file
• issues are generated in the UI
• warning issues are generated in the UI #1835

Regards,

[guwirth]

@gerboengels you can try with latest snapshot