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)? > > > > -- 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
