First of all unmatchedSuppression has probably never worked properly. So depending on your configuration it might have been that have never seen such a warning at all or you had to deal with false positives. So you had to suppress these (probably globally) and that is a whole other thing (see below).

Secondly this is not very portable at all. Also depending on your configuration or just the underlying version of Cppcheck you will get these warnings. These might not apply to you so you want to get rid of them but they might show up for somebody else. So this is not something a regular user should not have enabled (this might also go for other messages in the category but one thing at a time). It is rather something you want to have within your CI. It seems like something that should go behind --check-config instead but since this requires the whole analysis to be run that is obviously not a fit.

Also suppressing these is an annoying chicken and egg problem (at least used to be). In case you have a version which no longer or not yet triggers any of the findings which needs to be suppressed you will get these warnings and then you have to suppress them. But if you do that and the suppression is actually used then you get a message that there was no unmatched suppression. This is probably something that should be avoided but something to look into after the unmatched suppression are actually reported as intended.

The reason the deprecation period is that short is because of the brokenness of this.

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

As unmatchedSuppression is working much better now I am no longer sure about this.

My second point of these being incorrectly reported because of the configuration used still is valid but we should wait a bit if we get reports about this. After all the improvements have only been available in recent releases and some distros/users might still need to catch up.

It is also possible that people are never seeing these since information is still a bit noisy/tainted out of the box (i.e. checkersReport and missingIncludeSystem - still need to take a closer look at that) so they might not have those enabled at all. But would support that it should be split.

It seems an actual use case has just come up where it would make sense to have it split out after all - see llvm/llvm-project#175417 (comment).

Hi, I would also be interested in a better support for this check to be able to clean unnecessary suppression.
What I'd like is:

• To have a way to enable this check in a more fine grained way. At least without the unwanted/extra output from information (which I do not enable)
• To be able to diagnose only inline suppression (maybe via an additional check unmatchedInlineSuppression?). I use both inline suppression for specific local ones and a suppression file for more global ones (full suppression or pattern) and I wouldn't want to have the check report global suppression on most files.