[PATCH] D58784: [FileCheck]Remove assertions that prevent matching an empty string at file start before CHECK-NEXT/SAME

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

I think there is value in having a way to check the very first line of input. Once we've done that, everything else ought to fall out naturally, if the model is defined well enough.

James discovered that the existing assertions interfered with ways to check that the first line is actually empty. The assertions were there mainly because we punted defining how SAME and NEXT would work at the top of the input.  And, it turns out, the assertions were implemented based on an incorrect assumption anyway, triggering on a NEXT that wasn't actually the first directive.

I think the difference between Joel's and my interpretations are whether the very first line counts as the "same line" as the implicit label at the top of the input, or the "next line."  I have this naive idea that a "next line" is "the one after the next newline" and there isn't an implicit newline at the top-of-input.  An explicit CHECK-LABEL doesn't consume a line, which is why CHECK-SAME after a CHECK-LABEL works on the same line as the label text. So, I think the implicit label at the top-of-input works the same way, and the first line isn't a "next" line.

This all lets me keep thinking that a CHECK-SAME as the first directive would naturally look for a match on the first line of input (i.e., the "same" line as the implicit initial label), and an initial CHECK-NEXT would (by virtue of how it is defined relative to the model, not because it's inherently useful) match on the second line of input.

I can see some usefulness to saying we don't allow an initial CHECK-NEXT, because you probably meant CHECK-SAME (because your intuition matches Joel's!).  This in turn means the assertion relative to CHECK-NEXT (that James wants to remove) isn't a bad idea, we just need to make it not depend on an incorrect assumption.  And if for some reason you *do* want to check something on the second line, and not on the first line, you can do this:

  CHECK-SAME: {{$}}
  CHECK-NEXT: stuff that's on the second line

That is, I think it's correct to remove the CHECK-SAME assertion, and we need to fix the CHECK-NEXT assertion.

Sudden thought:  Why are these assertions anyway? Shouldn't they be normal diagnostics? Or does FileCheck always have assertions on?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58784