Introduce a better mechanism to suppress false loplugin warnings

...by annotating occurrences of false warnings with [-loplugin:<name>] comments
in source files and letting individual plugins opt-in to watch out for such
suppression annotations, rather than maintaining lists of excluded source files
in the individual plugins.  (See the new loplugin::Plugin::suppressWarningsAt.)

Instead of making all calls to loplugin::Plugin::report check for suppression
annotations, the intent is that this check will only be added opt-in to those
places in the plugins that are prone to emitting false warnings.  In general it
is better to have plugins that don't produce false warnings in the first place,
or at least let those warnings be addressed with trivial and harmless source
code modifications, avoiding the need for any suppression mechanism.

As a proof of concept, I have removed the exclude list from
loplugin:redundantfcast and instead annotated the relevant source code.  (And
thereby found that three of the six originally excluded files didn't need to be
excluded any more at all?)

For now, this mechanism looks for comments (both //... and /*...*/, even
documentation-style /**...*/) that overlap the current and/or the preceding
line, because at least for code controlled by clang-format it is often easier to
move comments to a line of their own, preceding the commented code.  Looking
also at the current line (and not only at the preceding one) opens the door for
erroneous over-eager annotation, where an annotation that was meant to address a
false warning on the current line would also silence a potentially true warning
on the following line.  This probably doesn't cause much trouble in practice,
but is up for potential change.

Change-Id: I91ce7a0e5248886a60b471b1a153867f16bb5cea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133365
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions