This is exactly what we plan to do! And it's awesome to hear that you believe it's the right approach!
There is one problem with that approach though, we want to have an option for the use to suppress one particular diagnostic. However, there is no one good looking identifier type for checkers that the end user can see and use. Straight up checker names are too verbose and can change, diagnostic messages can be pretty long and also susceptible to changes. I guess we need to open some sort of discussion here.

I see a few options here:
The first option is to implement suppress that suppresses whatever warning is there, without warning identifiers for now. This is a bigger effort though and has larger scope than what Jan is doing here.
The second option is to support suppress for uncounted checkers. So, we start small and don't ask Jan to do everything in this patch. The problem here is with identifier (again). We probably need to choose a good identifier/set of identifiers for this group of checkers that will persist even when we proceed with other checkers.
And, finally, the third option is to introduce a separate attribute that suppresses all the checks from that group. In this case, it should be probably decoupled from the checker, meaning that it should tell something to the person reading this code. Sorta like volatile refcountable.

What do you think?

This is exactly what we plan to do! And it's awesome to hear that you believe it's the right approach!

Excellent!

There is one problem with that approach though, we want to have an option for the use to suppress one particular diagnostic. However, there is no one good looking identifier type for checkers that the end user can see and use. Straight up checker names are too verbose and can change, diagnostic messages can be pretty long and also susceptible to changes. I guess we need to open some sort of discussion here.

I agree, this should be done in a broader community discussion. The typical way this is handled by other tools is to come up with a stable identifier for each rule so that users can use the stable identifier for suppression even if the rule title or other aspects change.

The first option is to implement suppress that suppresses whatever warning is there, without warning identifiers for now. This is a bigger effort though and has larger scope than what Jan is doing here.

Agreed -- also, IIRC, the static analyzer already supports // NOLINT comments, so I don't think this gets us a whole lot that we don't already have today.

The second option is to support suppress for uncounted checkers. So, we start small and don't ask Jan to do everything in this patch. The problem here is with identifier (again). We probably need to choose a good identifier/set of identifiers for this group of checkers that will persist even when we proceed with other checkers.
And, finally, the third option is to introduce a separate attribute that suppresses all the checks from that group. In this case, it should be probably decoupled from the checker, meaning that it should tell something to the person reading this code. Sorta like volatile refcountable.

There may be a fourth option here -- come up with an RFC and start a discussion about how to suppress analyzer diagnostics by name. There are a few different approaches to consider there -- do you want to suppress just one aspect of a given check or do you want to suppress the check as a whole? Do you want to be able to suppress multiple different checks using a single attribute or should that require multiple attributes? Should there be a warning flag specific to this attribute so that users can opt in to warning when the suppression attribute is being used? Should there be a warning flag the user can opt in to/out of warning when the suppress attribute is used but there is no diagnostic to suppress?

Agreed -- also, IIRC, the static analyzer already supports // NOLINT comments, so I don't think this gets us a whole lot that we don't already have today.

AFAIK only clang-tidy supports those, but maybe I missed it somehow.

There may be a fourth option here -- come up with an RFC and start a discussion about how to suppress analyzer diagnostics by name. There are a few different approaches to consider there -- do you want to suppress just one aspect of a given check or do you want to suppress the check as a whole? Do you want to be able to suppress multiple different checks using a single attribute or should that require multiple attributes? Should there be a warning flag specific to this attribute so that users can opt in to warning when the suppression attribute is being used? Should there be a warning flag the user can opt in to/out of warning when the suppress attribute is used but there is no diagnostic to suppress?

This is actually the reason why I suggest options 2 and 3. It's a lot of questions to answer! We also need to come up with a stable identifier. And I suggest to do something that is maybe not an awesome and all around generalized solution, but that is not a hacky solution "for the time being" either. We can start moving in the right direction here and also initiate the conversation at the same time.