At the moment, the only possible way to suppress analyzer warnings
is by cutting the code out with #ifdef. It is practically impossible
to do locally, so whole functions should stay not analyzed.
This patch introduces new attribute analyzer_suppress for these
purposes. Even without specifying checker IDs, it is far more
precise than the existing practice. It can be applied to statements
in question. Its proximity to the warning and the fact that this is
part of the code, drastically increases its chances to survive code
At the moment, new suppression attribute is limited to statements
and variable declarations. This is a deliberate design choice.
It is not clear and open for discussions how it should behave when
placed on function or class declarations.
First choice here is to suppress warnings within the declaration
and the body. This includes forward declarations, nested classes
and so on. This way is more obvious and probably more intuitive,
but creates a whole bunch of problems. First of all, it is a
rather crude solution. Suppressions in large scopes such as
functions and classes should be discouraged and that's why we
actually went to the statement level. The second problem is
with issues reported on declarations. The only way the user can
suppress such warnings is to put the annotation directly on
the declaration. However, this will suppress issues within the
body of this declaration, including nested functions and classes.
The paradox of this situation is that in this case the current
approach is actually counter-intuitive.
The second approach addresses these two problems. It states that
the attribute placed on the declaration suppresses only warnings
reported on this declaration, but not in its body. And while
this way seems reasonable when we talk about the stated problems,
for the regular user, who is not familiar with all this, it might
seem that suppressions on functions and classes are non-obvious
or simply ignored by the analyzer.
Additionally, further on, when we decide on stable checker
identifiers, we can implement finer approach, where the user can
specify those to suppress specific checks. Current code still
can be relevant as it gives "suppress all" option, which is usually