[llvm-commits] [PATCH] A "very verbose" mode for FileCheck

David Blaikie dblaikie at gmail.com
Wed Jan 16 12:13:11 PST 2013


On Wed, Jan 16, 2013 at 11:49 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Wed, Jan 16, 2013 at 9:47 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> On Wed, Jan 16, 2013 at 11:44 AM, Eli Bendersky <eliben at google.com> wrote:
>>> On Wed, Jan 16, 2013 at 11:43 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>> On Wed, Jan 16, 2013 at 9:39 PM, Eli Bendersky <eliben at google.com> wrote:
>>>>> Yes, the effect of dumping a (sometimes largish) file on each
>>>>> invocation of FileCheck should be measured, since we run thousands
>>>>> upon thousands of instances of FileCheck for each "make check-all".
>>>>
>>>> It is done only on errors, so I don't think we care about performance
>>>> impact (if any).
>>
>> How does this happen only on error? Is FileCheck already buffering the
>> entire contents of the input anyway?
>>
>> Well, in any case, that's fine by me.
>
> Not only buffers, but normalizes spaces.
>
>> But leaves me with the question: why bother with the option to print
>> to stderr at all? We can just improve the buildbot configuration to
>> log these files alongside the failure log. (ensuring that they'll be
>> complete/standalone/exact replicas of the input & you won't have to
>> figure out where the file input begins/ends and the FileCheck/other
>> log data is)
>
> Because it is simpler?

Hmm, you might be right. I was hoping it would be simpler but I'm not
sure if, even dynamically with a LogObserver, whether I can easily
pull a new, previously unspecified, file back to the buildmaster.

I'd rather hope it's not too difficult & I could just do it this way -
it seems like it ought to be somewhat tidier (& not substantially more
complicated) than adding a new feature to FileCheck. But I can't
promise anything.



More information about the llvm-commits mailing list