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

Stephen Lin swlin at post.harvard.edu
Fri Jul 12 10:11:04 PDT 2013


On Thu, Jul 11, 2013 at 4:23 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
> 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

Committed as r186162.

-Stephen



More information about the llvm-commits mailing list