[cfe-commits] r164677 -

[Sean Silva]

> Yes, that's a great point. We could add some kind of expected-no-diagnostics
> marker (or -verify-no-diagnostic switch), or to change the test to use, say,
> -Werror instead of -verify (which would mean we'd no longer have caught the
> missing %s), but it certainly takes the shine off the idea.

I think the expected-no-diagnostics is a good idea. It's good to have
the negative assertion described explicitly in the code, instead of
being just an "empty silence".

Would introducing the expected-no-diagnostics + the "fail if no
expected-*" behavior solve the issue then?

--Sean Silva

On Fri, Sep 28, 2012 at 2:20 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Sep 27, 2012 at 10:09 PM, Nico Weber <thakis at chromium.org> wrote:
>>
>> On Fri, Sep 28, 2012 at 1:59 PM, Sean Silva <silvas at purdue.edu> wrote:
>> >>> Alternatively (and slightly more generally) how about teaching -verify
>> >>> to
>> >>> fail if it doesn't find any expected-* comments to check (like
>> >>> FileCheck
>> >>> does)?
>> >>
>> >> That wouldn't have helped in this case though, would it? there's no
>> >> expected- comment in this file.
>> >
>> > Wut? I think that what Richard was proposing elegantly addresses this
>> > case. Basically, it fails when it doesn't see an expected-* comment.
>>
>> Right. This test here doesn't have an expected-* comment.
>>
>> > Since stdin is empty, then there would be no expected-* comment, so
>> > the test would fail.
>>
>> The fixed test would fail too.
>
>
> Yes, that's a great point. We could add some kind of expected-no-diagnostics
> marker (or -verify-no-diagnostic switch), or to change the test to use, say,
> -Werror instead of -verify (which would mean we'd no longer have caught the
> missing %s), but it certainly takes the shine off the idea.