[PATCH] Add CHECK-LABEL directive to FileCheck to allow more accurate error messages and error recovery

[Stephen Lin]

On Thu, Jul 11, 2013 at 1:42 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> I explained my preference, and LABEL suggests something that is not
>> necessarily true - since it doesn't have to be attached to a label. Your
>> documentation and patch description speaks about "breaking to blocks", which
>> has the spatial semantics I was referring to earlier and no relation to
>> labels (which are just one example of unique identifiers that may serve as
>> block boundaries).
>>
>> That said, there's only a certain amount of time I'm willing to spend on
>> such bikeshedding - so if I'm in minority w.r.t the name, so be it.
>>
>> Eli
>
> No worries, I see your point and I'm in no rush so I'll see if someone
> comes up with another suggestion.

I (hopefully) improved the documentation a bit and included a test
that I wrote earlier but forgot to add to source control before
producing the diff. I will commit this sometime tomorrow if there are
no objections, votes to change the name, or better suggestions.

Also, Eli, I see your point that LABEL is not always 100% accurate if
you take it to mean that it refers to a "label" in the source
language; however, it's not really meant to mean that (since FileCheck
is agnostic as to the source language); it's more that it uniquely
labels the beginning of a logical block from FileCheck's perspective,
but it could correspond to any construct in the source language as
long as it produces something which can uniquely identify the line.
The updated language in the docs makes this (hopefully) clearer.

Furthermore, I don't think this name is any worse than CHECK-DAG,
which doesn't really only apply specifically to output generated by
DAG data structures.

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-label.patch
Type: application/octet-stream
Size: 12055 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130711/4949bc5f/attachment.obj>