[cfe-commits] r164677 -

Richard Smith richard at metafoo.co.uk
Thu Sep 27 18:24:17 PDT 2012


On Thu, Sep 27, 2012 at 6:05 PM, Nico Weber <thakis at chromium.org> wrote:

> On Fri, Sep 28, 2012 at 1:31 AM, Sean Silva <silvas at purdue.edu> 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 <dblaikie at gmail.com>
> 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; cfe-commits at cs.uiuc.edu
> >> 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 <silvas at purdue.edu> 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 <nicolasweber at gmx.de>
> 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
> >>>> cfe-commits at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >>> _______________________________________________
> >>> cfe-commits mailing list
> >>> cfe-commits at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> >> _______________________________________________
> >> cfe-commits mailing list
> >> cfe-commits at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120927/cda1d3c4/attachment.html>


More information about the cfe-commits mailing list