Description Stephan Herrmann 2020-03-17 08:31:32 EDT

Bug 560733 is an example where some project's policy is in conflict with the development of more advanced warning analysis:

We want to detect a new situation as a warning in an existing category (here: unused local variable).

Some projects have configured this category to error, and hence each "false positive" (truly false or not) is perceived as a blocker to the feature itself.

In this deadlock we cannot provide much progress.


For all who join me in recognizing that 100% accuracy of optional warnings is hardly ever possible, the solution would seem to be to use @SuppressWarnings for the exceptional cases, but where the problem is classified as error, people may not be able to use @SuppressWarnings.


To avoid this deadlock I suggest to (more or less gently) push projects towards enabling:
 [x] Suppress optional errors with '@SuppressWarnings'



I frequently see the proposal to create a new option (off-by-default) for a situation newly detected by a new version of the compiler.

I declare that I will not invest my time in any analysis that is off-by-default (hence never noticed by the vast majority of users) and at the same time contribute to the flood of options that will further scare users away from looking at available options.


Before discussing concrete strategies, I seek discussion about the following statement:

- Whenever projects configure optional problems as errors, it is strongly recommended to enable suppressing those optional errors with @SuppressWarnings.

Do people agree, or else: why not?