enabled information messages in selfchecks / mitigated unmatchedSuppression warnings

[firewave]

The unmatchedSuppression messages might be a bug where the regular expression appears to be incorrectly validated. I saw this with local runs but didn't look into it yet. There was also different behavior between using no threads and -j. I will file tickets as soon as I have the time to look at it.

[chrchr-github]

So we have inline suppressions, but don't check if they are (still) matched? Ugh.

[firewave]

The "issue" we are having is that we are using a single suppression file for multiple different Cppcheck analysis invocations. This causes unmatchedSuppression warnings for unmatched global suppressions and suppressions for files which are not part of the analysis.

The first could be solved by using more granular suppressions. That might not be what you want. We possible need some way to filter out error IDs without suppressing them indicating that you just not care about them. Suppression should also be considered temporary hence the unmatchedSuppression warning.

The latter cannot be solved easily. We adjust the warning to only report them as unmatched if neither the regular expression nor the ID matched. That would require some re-working of the suppression code (which might happen as part of the still in progress executor rework) but might result in lots of outdated entries in the suppression file.

Another issue is that you also cannot control unmatchedSuppressionproperly. It is part of information - which it shouldn't IMO - see https://trac.cppcheck.net/ticket/10697. And if you enable that and you also suppress that you might still end up with an unmatchedSuppression. So maybe that should have a separate type in --enable/--disable.

[firewave]

As most (all) of the issues are with having a suppression file and those do not apply to inline suppression at all maybe we should introduce unmatchedInlineSuppression?

[chrchr-github]

As most (all) of the issues are with having a suppression file and those do not apply to inline suppression at all maybe we should introduce unmatchedInlineSuppression?

Sounds reasonable. Unmatched inline suppressions are more problematic anyway.

[firewave]

*/moc_*.cpp:-1:0: information: Unmatched suppression: symbolDatabaseWarning [unmatchedSuppression]
^

I filed https://trac.cppcheck.net/ticket/13659 about the invalid location.

I also filed https://trac.cppcheck.net/ticket/13660 about such warnings being shown even if no files matching the wildcard were encountered.

[firewave]

lib/filesettings.h:98:0: information: Unmatched suppression: unusedFunction [unmatchedSuppression]
    const std::string& sfilename() const
^
lib/utils.h:297:0: information: Unmatched suppression: unusedFunction [unmatchedSuppression]
std::size_t getArrayLength(const T (& /*unused*/)[size])
^
lib/errorlogger.h:198:0: information: Unmatched suppression: unusedFunction [unmatchedSuppression]
    const std::string &verboseMessage() const {
^

These are a bit a of problem.

The warnings are correct but we have a dedicated job in a different workflow which takes care of this and the check is not enabled in this case. So I have no idea how we can avoid these.

This also highlights that the unusedFunction check is not run in the selfchecks with the sanitizers. So we should enable it only in those and not fail the build in case any error is encountered in those. But in that case we would not see potential changes in behavior with the sanitizers enabled. As that is not an actual production use case it should be fine though.

Update: We could just hack these out by not reporting them if unusedFunction is not enabled. I think that logic already exists but might not be applied for inline suppressions.

[firewave]

lib/token.h:1457:0: information: Unmatched suppression: premium-misra-cpp-2023-12.2.1 [unmatchedSuppression]
    bool mIsC : 1;
^

This will only trigger with the premium selfcheck so we should ignore these suppressions if it is not premium - which would be a horrible hack IMO.

Update: Well - I think we already have that "hack" in place for unusedFunction.

[firewave]

We cannot enable these yet because we get warnings about the non-unusedFunction inline suppressions. That requires the UNUSEDFUNCTION_ONLY to be adjusted. I will do that in a follow-up to not delay this PR any longer.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

@danmar @chrchr-github This is finally ready for review. 🥳