[cfe-commits] r164677 -
David Blaikie
dblaikie at gmail.com
Sat Sep 29 03:57:50 PDT 2012
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; cfe-commits at cs.uiuc.edu
Subject: Re: [cfe-commits] r164677 -
On Sep 28, 2012, at 12:09 , Sean Silva <silvas at purdue.edu> 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
cfe-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
More information about the cfe-commits
mailing list