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

[Reid Kleckner]

I was thinking more like this could succeed:
; CHECK: foo
; CHECK-ANYWHERE: bar
; CHECK-NEXT: baz

bar <- second
baz <- third
foo  <- first match

The goal being to handle something like the vtable layout tests, which
would look like:

// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm-only
-fdump-vtable-layouts |& FileCheck %s
...
namespace Test1 {
// CHECK-ANYWHERE:      Vtable for 'Test1::A' (3 entries).
// CHECK-NEXT:   0 | offset_to_top (0)
// CHECK-NEXT:   1 | Test1::A RTTI
// CHECK-NEXT:       -- (Test1::A, 0) vtable address --
// CHECK-NEXT:   2 | void Test1::A::f()
struct A {
  virtual void f();
};
void A::f() { }
}

Instead of the current repeated FileChecks with prefixes:

// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm-only
-fdump-vtable-layouts > %t 2>&1
// RUN: FileCheck --check-prefix=CHECK-1 %s < %t
// RUN: FileCheck --check-prefix=CHECK-2 %s < %t
...
// CHECK-1:      Vtable for 'Test1::A' (3 entries).
// CHECK-1-NEXT:   0 | offset_to_top (0)
// CHECK-1-NEXT:   1 | Test1::A RTTI
// CHECK-1-NEXT:       -- (Test1::A, 0) vtable address --
// CHECK-1-NEXT:   2 | void Test1::A::f()

On Wed, Apr 10, 2013 at 5:01 PM, Eli Bendersky <eliben at google.com> wrote:
>
>
>
> 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
>
>