[PATCH] D47106: [FileCheck] Make CHECK-DAG non-overlapping

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

(Replying here instead of inline as the thread is getting kind of long.)

Sorry, I didn't realize FileCheck would try to detect and explicitly diagnose reordering DAG across NOT.  That seems like more trouble than it's worth.  NOT is documented to enforce ordering, and we can make it just do that, and if you mess up then your test fails by not matching rather than telling you something is in the wrong order.  (Then you can use `-v` or `-vv` to work out what happened, if you need to.)

Once we define the DAGs as separated into distinct groups by a NOT, I think it's conceptually straightforward to say each DAG group has a "matching range" from the start of the earliest match to the end of the latest match.  Two DAG groups can't have overlapping match ranges (just like you are making individual DAG matches not overlap).

Defining the search range of a DAG group does get a little fuzzy when it's not bounded by a normal CHECK.  I think when that happens, we say it goes to the next LABEL, or start/end of file.

Similarly, if you have a NOT group, its range is bounded by the previous match (or last match of a preceding DAG group), and the following match (or first match of a following DAG group).

At that point, I think the behavior becomes tractable.  The first DAG group finds what it finds, the NOT forces no reordering therefore the second DAG group's range starts at the endpoint of the first group's matches.  After the second DAG group runs, the NOT's range is from the endpoint of the first group's matches to the earliest of the second group's matches.

How does that all sound?  If we can agree on this behavior, then probably I should write it up for the dev list to get a broader audience, before launching ahead with the implementation.  But (if I do say so myself) I think this kind of conceptual model has been lacking in FileCheck as it has grown new features, and it's worth laying it out explicitly.


https://reviews.llvm.org/D47106