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

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D58784#1423165 <https://reviews.llvm.org/D58784#1423165>, @jdenny wrote:

> Are we planning to say that an initial empty line must be matched with `CHECK-FIRSTLINE: {{^$}}`?
>
> It seems we're creating yet another directive with new quirks that must be learned to use it correctly.  And yet, when formally specified, it's exactly the same as CHECK-SAME except that it can be and can only be the initial directive.  For those reasons, Paul's interpretation of initial CHECK-SAME (including rejection of initial CHECK-NEXT/CHECK-EMPTY with diagnostics pointing to CHECK-SAME) seems simpler and thus more user-friendly than introducing CHECK-FIRSTLINE.
>
> Whether we choose CHECK-FIRSTLINE or Paul's interpretation of initial CHECK-SAME, I still wouldn't like the asymmetry that a `{{^$}}` pattern must be used to match an empty first line while CHECK-EMPTY must be used to match other consecutive lines that are empty.  I'd also be disappointed that a CHECK-DAG-NEXT block, which we proposed in another review, couldn't be used to match //all// (unordered) lines of input.


I think `CHECK-FIRSTLINE: {{^$}}` would be a natural consequence of not wanting to change the permitted uses of other check directives, although I definitely agree it's not ideal. I'm not sure how else it would work if CHECK-SAME remained illegal as the first CHECK, and if we don't want to change CHECK-EMPTY's semantics. I suppose we could special-case CHECK-EMPTY's behaviour when it is the first check in the file to match the first line. This would certainly be intuitive, but it means that CHECK-EMPTY would no longer mean the same as CHECK-NEXT (except matching an empty line) in all cases. Thus CHECK-EMPTY becomes "Checks if the NEXT line in the input is completely empty. If it is the first specified CHECK, it checks that the first line matches is empty." I think this would be nicer than a new directive for this specific case, or to force regular expressions etc.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58784