[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