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

[Joel E. Denny via Phabricator via llvm-commits]

jdenny added a comment.

In https://reviews.llvm.org/D47106#1110240, @probinson wrote:

> (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).


I think we should try to understand why reordering detection was implemented in the first place.  I've imagined hypothetical examples where it could help, but I don't know if they occur in real tests.  I generally have a hard time knowing what the right use cases for DAG-NOT-DAG are, and I imagine that's part of the motivation of the reordering detection: to help people not use it incorrectly.  All of that can be part of the llvm-dev discussion you suggest.

> 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.

Yes, I believe that's what happens now.

> 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).

Yes, we've agreed on that, and I've tinkered some with fixing the end of the range when followed by a DAG group.  I think knowing whether that breaks existing tests would be helpful in any further discussion on that point.

> 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?

The main question remaining for me is about the start of the second DAG group's match range and thus whether reordering detection happens.

> 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.

I'm certainly fine with an llvm-dev discussion.

> 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.

Agreed.


https://reviews.llvm.org/D47106