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

[David Blaikie]

On Wed, Jan 16, 2013 at 12:19 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Wed, Jan 16, 2013 at 10:13 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> 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.
>
> OK, I will wait for your reply.

Yeah, I'll have to concede here. It doesn't look like it'll be easy
enough to do in the short term.

We could still have the LogObserver pull out the contents & put them
in a separate file assuming we have clear start/end markers from
FileCheck so we can detect the portion we need to remove. If people
would find that valuable. (maybe, maybe not - if the begin/end markers
are clear enough, I guess users won't have much trouble just reading
it that way)