Rather than adding a new expected-no-diagnostics, I'd be in favor of just s/-verify/-Werror/ unless there's a reason that isn't suitable.
(& yeah, a warning in empty files as well as/instead of seems fine too) From: Jordan Rose Sent: 9/28/2012 11:04 PM To: Sean Silva; Andy Gibbs Cc: Nico Weber; Richard Smith; [email protected] Subject: Re: [cfe-commits] r164677 - On Sep 28, 2012, at 12:09 , Sean Silva <[email protected]> wrote: >> 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? We have quite a few tests that currently use -verify to test that there are no errors. If we make this illegal, we'll have to spuriously introduce warnings, or add this new expected-no-diagnostics. I'm mildly against expected-no-diagnostics but I can't come up with a solid reason why. I thought the original proposal here was to have -verify warn if the input file had zero length, which I think would handle this issue fine. Roping in Andy in case he has any insights to share from his earlier -verify work. Jordan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
