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

Joel E. Denny via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 8 12:45:08 PST 2019


jdenny added a comment.

In D58784#1422567 <https://reviews.llvm.org/D58784#1422567>, @jhenderson wrote:

> One question about CHECK-FIRSTLINE - is it required to be the first CHECK in the file? In other words, to check two different things on the first line, would the following be allowed:
>
>   CHECK-FIRSTLINE: some stuff
>   CHECK-FIRSTLINE: more stuff
>
>
> I don't think it needs to be, because the following would make sense to me:
>
>   CHECK-FIRSTLINE: some stuff
>   CHECK-SAME: more stuff
>


The second example feels right to me.  I think the reason is that my intuition still says we're doing something like CHECK-NEXT here.  Thus, it's always the first match on the line, so subsequent matches on the line must be specified using CHECK-SAME.

> But the latter has the downside that, using multiple check prefixes, I can't say something like "check that the first line starts with some blob in one version, followed by the second blob, but in the second blob, only check for the latter", i.e. neither of the following would work:
> 
>   V1ONLY-FIRSTLINE: some stuff
>   BOTH-SAME: more stuff
> 
> 
>   V1ONLY-FIRSTLINE: some stuff
>   BOTH-FIRSTLINE: more stuff

You can handle that without new directives (after removing the broken assertions):

  BOTH: {{^}}
  V1ONLY-SAME: some stuff
  BOTH-SAME: more stuff

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.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D58784





More information about the llvm-commits mailing list