[PATCH] Add support to FileCheck for out-of-order matching

[Eli Bendersky]

On Wed, Apr 10, 2013 at 2:00 PM, Eli Bendersky <eliben at google.com> wrote:

> On Wed, Apr 10, 2013 at 1:40 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> It seems like we have a bunch of tests where we really don't care
>> about ordering.  Should we add support to FileCheck for that?
>>
>> For example, this test uses repeated filecheck runs on the temp file
>> output with different prefixes just to work around this problem:
>>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vtable-layout.cpp?view=markup
>> I had the same problem while working on vbtable layout.
>>
>> This is a big grep test that can't easily be filecheck-ified because
>> there's no out of order matching:
>>
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/metadata-symbols-64.m?revision=174461&view=markup
>> I'd like to filecheck-ify that test because there's something wrong
>> with the grep escaping on my system.
>>
>> I propose CHECK-ANYWHERE, or something else with the same behavior.
>> Basically, this is a check directive that just resets the matching
>> cursor back the beginning of the file.  Any subsequent checks follow
>> from the end of a successful match.  Any captured variables are
>> preserved, mostly because removing them would be hard.
>
>
> The proposal is interesting, but I have doubts about the proposed
> implementation. Wouldn't this make the semantics of some tests very...
> unusual? Consider this:
>
> CHECK: foo
> CHECK-EVERYWHERE: bar
> CHECK: baz
>
> Is this going to match:
>
> baz
> foo
> bar
>
> That's kind-of weird :-)
>

I figured I should be more constructive :-)
An alternative proposal without this problem (AFAICS) is to collect all
"-EVERYWHERE" checks and run them separately in the end on the whole file.
They're order-independent, so this seems safe. And oh while we're at it,
let's call it CHECK-GLOBAL and also have CHECK-GLOBAL-NOT because that one
would be really useful for rewriting some 'not grep' tests.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130410/48ac1f9a/attachment.html>