[PATCH] D56789: FileCheck: Allow CHECK-{SAME, NEXT, EMPTY} after initial CHECK-DAG

Wed Jan 30 15:06:20 PST 2019

thopre added a comment.

In D56789#1371929 <https://reviews.llvm.org/D56789#1371929>, @jdenny wrote:

> In D56789#1371821 <https://reviews.llvm.org/D56789#1371821>, @thopre wrote:
>
> >
>

[SNIP]

>> Agreed, something like CHECK-DAG-NEXT would be better suited. The requirement of CHECK-DAG with CHECK-NEXT was mentioned to me by a coworker and I noticed the weird inconsistency regarding whether CHECK-DAG is the first check directives or not and thought I'd fix it. The behaviour we need is indeed reordering without any line not checked for in between using CHECK-DAG is not the right solution. So I guess the correct approach would be to error out on CHECK-DAG with CHECK-NEXT, CHECK-SAME or CHECK-EMPTY, probably with some flag to enable the old behavior while tests are updated.
> 
> Possibly so.  Given that many of those existing cases were probably intending the stricter behavior, let's first create a better solution for the stricter behavior.
> 
>> Regarding CHECK-DAG-NEXT, I wonder how it would interact with CHECK-DAG?
> 
> I think that any kind of CHECK-DAG* following a different kind of CHECK-DAG* would start a new block such that there's no reordering among blocks.  Otherwise, the semantics become very unclear to me.
> 
> It seems intuitive that the first match in a CHECK-DAG-NEXT block would have to appear on the line after whatever match came before the block.  However, if you don't want that behavior, then I'm not sure how you would express that.

No that makes sense.

> 
> 
>> Perhaps we should introduce some sort of only-tested region (e.g. CHECK-ONLY-START and CHECK-ONLY-END with better name) where CHECK-DAG inside would still be able to be reordered but only what is tested by a CHECK-DAG is allowed. It could also allow CHECK directive inside which would behave as CHECK-NEXT. How does that sound?
> 
> Or would that CHECK inside behave as a CHECK-SAME?  In general, how would whitespace be handled?  Error or ignored?

Whatever is consistent with the concept of CHECK-DAG-NEXT I guess. Am suddenly wondering whether 2 CHECK-DAG can match on the same line if they don't overlap? Anyway, this is just an idea, we should have a discussion on llvm-dev to gather requirements from people who used CHECK-DAG when they wanted something else and come up with a good design.

> What you propose sounds very similar to something I suggested at one point: CHECK-NOT-PUSH  and CHECK-NOT-POP.  The idea is you would push a pattern into `-implicit-check-not` so the pattern would be rejected among matches between the push and the pop.  This would be useful in any context where you want `-implicit-check-not` but don't want it for the entire input.

Oh nice, it would be useful indeed.

> To achieve something like CHECK-DAG-SAME, the pattern would specify a single newline, and you'd put CHECK-DAG directives in between the push and pop.  To achieve something like CHECK-DAG-NEXT, you'd do the same but each CHECK-DAG's pattern would be specified to gobble up the next newline.   Then again, those two cases might be easier to write and diagnostics might be clearer if we created special-purpose directives, but they could probably be built on the same infrastructure.
> 
> If all that makes sense to you, there are some details we could discuss about how CHECK-NOT-PUSH and CHECK-NOT-POP would interact with neighboring CHECK-NOT directives and neighboring matches.

I'd love to participate in the discussion yes. If you create a thread please Cc me.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56789/new/

https://reviews.llvm.org/D56789