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

[Stephen Lin]

Actually, I went ahead and renamed it CHECK-LABEL and rebased, since I think it’s better :)
-Stephen



On Jun 7, 2013, at 9:44 AM, Stephen Lin <swlin at apple.com> wrote:

> Understood :) although I personally think this is worth the complexity increase, from experience writing and debugging tests.
> 
> Anyone want to review this? If no one else thinks this is worthwhile I'm ok leaving it in my own tree for my own testing purposes--I'll just take out the -UNIQ suffix before submitting and run a script to put it back when debugging locally.
> 
> I'm also open to renaming the directive. Maybe CHECK-LABEL?
> 
> -Stephen
> 
> On May 29, 2013, at 1:18 PM, Eli Bendersky <eliben at google.com> wrote:
> 
>> 
>> 
>> 
>> On Wed, May 29, 2013 at 11:07 AM, Reid Kleckner <rnk at google.com> wrote:
>> If this only affects error messages, could we simply teach FileCheck some heuristics for bounding the region of the intended match, based on common patterns like 'CHECK: define ...', 'CHECK: asdf:', or 'CHECK: }' ?
>> 
>> 
>> Oh, let's get over with it and just add a CHECK-THIS-PYTHON-FUNCTION: directive :-) I'm kidding of course, though the recent trend in FileCheck is worrisome - FileCheck may reach self awareness before TableGen!
>> 
>> Eli
>> 
>> 
>> 
>>  
>> 
>> On Wed, May 29, 2013 at 1:51 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> Anyone have any thoughts on this? :)
>> -Stephen
>> 
>> ---------- Forwarded message ----------
>> From: Stephen Lin <swlin at post.harvard.edu>
>> Date: Sat, May 18, 2013 at 5:36 PM
>> Subject: [PATCH] Add CHECK-UNIQ directive to FileCheck to allow more
>> accurate error messages and error recovery
>> To: llvm-commits at cs.uiuc.edu
>> Cc: Eli Bendersky <eliben at google.com>
>> 
>> 
>> Hi,
>> 
>> This patch adds a new directive, CHECK-UNIQ, which is meant to be used
>> to match unique identifier lines (like labels).
>> 
>> If present in a match file, FileCheck will use these directives to
>> split the input into blocks that are independently processed, ensuring
>> that a CHECK does not inadvertently match a line in a different block
>> (which can lead to a misleading/useless error message when the error
>> is eventually caught). Also, FileCheck can now recover from errors
>> within blocks by continuing to the next block.
>> 
>> Please let me know if you have any comments or suggestions.
>> 
>> Also, if people like this idea, I will also script a mass update of
>> tests to use CHECK-UNIQ in common cases, like assembly labels and IR
>> function definition lines. (I will include a sanity check to make sure
>> each pattern does indeed uniquely match a single line of the input
>> before updating.)
>> 
>> Stephen
>> 
>> ---------- Forwarded message ----------
>> From: Eli Bendersky <eliben at google.com>
>> Date: Thu, Apr 25, 2013 at 10:37 AM
>> Subject: Re: [LLVMdev] Minor FileCheck proposal: CHECK-UNIQUE for
>> labels to improve error messages
>> To: Stephen Lin <swlin at post.harvard.edu>
>> Cc: llvmdev <LLVMdev at cs.uiuc.edu>
>> 
>> 
>> On Wed, Apr 24, 2013 at 8:05 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> >
>> > Hi,
>> >
>> > Apologies if this has been proposed before; I couldn't find anything
>> > in basic searching.
>> >
>> > I've been writing tests lately and noticed that the error messages are
>> > not very helpful in cases where a check is incorrect but matches
>> > something that occurs in a later block: the checker continues assuming
>> > that the matched line is correct (no matter how much farther ahead it
>> > occurs) and then provides a misleading error message some time later.
>> >
>> > The problem is exacerbated if many similar tests are put in one file,
>> > since many checks can end up succeeding with unintended matches before
>> > something ends up failing.
>> >
>> > I propose a simple addition to FileCheck syntax to improve error
>> > messages in this case: a CHECK-UNIQUE directive which indicates that a
>> > given check is a unique match that should only occur once (and only
>> > once) in a given file and can only be matched with the given
>> > CHECK-UNIQUE; this would be used for labels or any other unique
>> > identifier lines.
>> >
>> > The CHECK-UNIQUE lines can then allow a better error message to be
>> > produced, by basically treating each section between CHECK-UNIQUE
>> > lines separately, so the actual line causing the error can be
>> > pinpointed more accurately.
>> >
>> > Anyone else thing this is a good idea? I'm happy to work on this if so.
>> 
>> 
>> I like this idea. There are many places in the test cases where this
>> idiom is needed and currently CHECK followed by a CHECK-NOT is used,
>> which is cumbersome.
>> 
>> Eli
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130610/c102546d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-label.patch
Type: application/octet-stream
Size: 11775 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130610/c102546d/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130610/c102546d/attachment-0001.html>