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. > > Richard, how do you suggest the diagnostic should be like? I fear that > an error like "didn't see an expected-* comment" wouldn't be that > helpful in diagnosing the issue at hand (missing input file, > defaulting to stdin), even though it does accurately reflect the > situation. As a hack, a note could be added, but that doesn't seem > very in line with Clang style. > > Maybe it is worthwhile to require an explicit input file AND fail if > no expected-* comments are found? > >> Sounds resonable. Wanna give it a shot? :-) > > Yeah, once we settle on a way to do this I'll prepare a patch (unless > someone beats me to it). > > --Sean Silva > > On Thu, Sep 27, 2012 at 10:26 PM, Nico Weber <[email protected]> wrote: >> On Fri, Sep 28, 2012 at 10:24 AM, Richard Smith <[email protected]> >> wrote: >>> On Thu, Sep 27, 2012 at 6:05 PM, Nico Weber <[email protected]> wrote: >>>> >>>> On Fri, Sep 28, 2012 at 1:31 AM, Sean Silva <[email protected]> wrote: >>>> >> I couldn't think of a great way. If no filename argument is present, >>>> >> -cc1 -verify reads its input from stdin, which is a valid usecase. I >>>> >> think lit closes stdin when it forks, which is why -cc1 doesn't just >>>> >> wait for eof forever in this case. >>>> > >>>> > It is a valid use case, but how about just requiring that it be >>>> > explicit (at least for -verify)? Forcing it to be explicit would >>>> > preserve the use case but make the error case impossible. >>>> >>>> Sounds resonable. Wanna give it a shot? :-) >>> >>> >>> 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. >> >>> >>>> >>>> > >>>> > -- Sean Silva >>>> > >>>> > On Thu, Sep 27, 2012 at 6:22 AM, David Blaikie <[email protected]> >>>> > wrote: >>>> >> /cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c >>>> >> MIME-Version: 1.0 >>>> >> Content-Type: text/plain; charset="utf-8" >>>> >> Content-Transfer-Encoding: 7bit >>>> >> >>>> >> If clang was going to read from stdin, wouldn't it need a -x to tell it >>>> >> what kind of input it is? Even if it has a default, an empty file is >>>> >> not a valid TU, at least in C++, though I guess if it has a default it >>>> >> would be C and an empty file is probably valid C. Perhaps a warning >>>> >> there at least could be handy >>>> >> From: Nico Weber >>>> >> Sent: 9/27/2012 7:43 AM >>>> >> To: Sean Silva >>>> >> Cc: Nico Weber; [email protected] >>>> >> Subject: Re: [cfe-commits] r164677 >>>> >> - /cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c >>>> >> On Thu, Sep 27, 2012 at 2:46 AM, Sean Silva <[email protected]> wrote: >>>> >>> Is there some way to ensure that this doesn't ever happen again? Like >>>> >>> having -verify warn/fail if there is no input? That would allow fixing >>>> >>> all of these cases in a single fell swoop and ensure that it never >>>> >>> happens again. >>>> >> >>>> >> I couldn't think of a great way. If no filename argument is present, >>>> >> -cc1 -verify reads its input from stdin, which is a valid usecase. I >>>> >> think lit closes stdin when it forks, which is why -cc1 doesn't just >>>> >> wait for eof forever in this case. >>>> >> >>>> >> I suppose lit could check if clang_cc1 is the first command on the run >>>> >> line and then add a flag that tells cc1 to error out if it's reading >>>> >> from stdin, but seems brittle. >>>> >> >>>> >> Do you have a good suggestion? >>>> >> >>>> >>> >>>> >>> -- Sean Silva >>>> >>> >>>> >>> On Wed, Sep 26, 2012 at 5:02 AM, Nico Weber <[email protected]> >>>> >>> wrote: >>>> >>>> Author: nico >>>> >>>> Date: Wed Sep 26 04:02:07 2012 >>>> >>>> New Revision: 164677 >>>> >>>> >>>> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=164677&view=rev >>>> >>>> Log: >>>> >>>> Make this test actually test something >>>> >>>> >>>> >>>> Modified: >>>> >>>> cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c >>>> >>>> >>>> >>>> Modified: cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c >>>> >>>> URL: >>>> >>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c?rev=164677&r1=164676&r2=164677&view=diff >>>> >>>> >>>> >>>> ============================================================================== >>>> >>>> --- cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c (original) >>>> >>>> +++ cfe/trunk/test/Sema/no-format-y2k-turnsoff-format.c Wed Sep 26 >>>> >>>> 04:02:07 2012 >>>> >>>> @@ -1,4 +1,4 @@ >>>> >>>> -// RUN: %clang_cc1 -verify -fsyntax-only -Wformat -Wno-format-y2k >>>> >>>> +// RUN: %clang_cc1 -verify -fsyntax-only -Wformat -Wno-format-y2k %s >>>> >>>> // rdar://9504680 >>>> >>>> >>>> >>>> void foo(const char *, ...) __attribute__((__format__ (__printf__, >>>> >>>> 1, 2))); >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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 >>>> >> _______________________________________________ >>>> >> 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 >>> >>> _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
