cppcheck icon indicating copy to clipboard operation
cppcheck copied to clipboard

enabled `information` messages in self-check

Open firewave opened this issue 4 years ago • 11 comments

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.

firewave avatar Jan 28 '21 17:01 firewave

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

chrchr-github avatar Sep 07 '23 13:09 chrchr-github

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 avatar Oct 12 '23 09:10 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?

firewave avatar Oct 12 '23 09:10 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?

Sounds reasonable. Unmatched inline suppressions are more problematic anyway.

chrchr-github avatar Oct 12 '23 09:10 chrchr-github