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

Eli Bendersky eliben at google.com
Wed Apr 24 14:32:46 PDT 2013


On Wed, Apr 24, 2013 at 11:35 AM, Michael Liao <michael.liao at intel.com>wrote:

> Here's the revised patch achieving that goal. When a match is deferred,
> we will check whethe that check string has DAG strings and match them
> first. If all of them could match, we will match that check string again
> starting from the end of DAG string matchings. I kept the logic checking
> DAG string once a check string itself could match as it will reduce the
> range to verify for DAG strings. How do you think that? I could remove
> it if we think it's unnecessary.
>
> There's one feature might be useful. (I disabled it in both patches
> now.) Is it valueable to mix CHECK-NOT and CHECK-DAG together?
>

What I don't see in this patch is updated documentation. Personally I'm a
bit worried about the growing complexity of FileCheck logic. Some tests are
non-trivial to follow even without the new features (specifically I mean
when they fail and one needs to try to follow FileCheck's matching path in
the result file). Those can make some tests, if sloppily written, even more
incomprehensible. Whatever is decided, the new behavior has to be very well
defined and documented (with examples). This will hopefully lower the
chance people write overly-complex tests.

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


More information about the llvm-commits mailing list