[llvm-dev] Clarification on expectations of buildbot email notifications

[Michael Kruse via llvm-dev]

Am Mi., 20. Feb. 2019 um 16:16 Uhr schrieb Reid Kleckner <rnk at google.com>:
> On Wed, Feb 20, 2019 at 10:29 AM Michael Kruse <llvmdev at meinersbur.de> wrote:
>> For instance, one of my patches made clang emit an additional warning
>> when compiling a popular project. This was not intentional by my
>> patch, but due to an inconsistent implementation of the warning in
>> clang. However, the warning was legitimate. I reverted the patch (it
>> had another problem), but before I recommitted it, I put up a patch
>> for review that fixed the inconsistent implementation such that the
>> warning is always emitted.
>>
>> My question here: Should the patch be reverted even if it did not have
>> the other problem?
>
>
> I would say not necessarily. If a new warning is added that fires on a popular project and the warning is working as intended, that may be a signal that the warning shouldn't be on by default (or shouldn't be part of -Wall). We obviously need to allow ourselves the freedom to add new warnings over time. Just because a project uses "-Werror -Wall" doesn't mean that their code will compile cleanly with new compilers. However, if the warning really is low value, then we may want to remove it. If someone wants to revert a new warning because it is too noisy or has false positives, they need to actively engage the patch author to support their position.

It was the -Wformat family of warnings which we probably want to have
in -Wall. The problem was/is, ngettext (GNU gettext) has multiple
__format_arg__ attributes, but clang only checked one of the format
strings. My patch changed which one was checked, so it warned about
format strings that had been ignored before.

Michael