> 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 <[email protected]> wrote: > On Thu, Sep 27, 2012 at 10:09 PM, Nico Weber <[email protected]> wrote: >> >> On Fri, Sep 28, 2012 at 1:59 PM, Sean Silva <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
