[PATCH] D96653: [FileCheck] Add neighboring annotations for -dump-input-filter=error

Thomas Preud'homme via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 26 02:20:24 PST 2021


thopre added a comment.

Sorry for the late review.

In D96653#2574627 <https://reviews.llvm.org/D96653#2574627>, @jdenny wrote:

> In D96653#2569854 <https://reviews.llvm.org/D96653#2569854>, @thopre wrote:
>
>> Would the neighbouring work if the error is on a CHECK-NOT and there's another CHECK-NOT immediately preceding and/or following it?
>
> Ah, you're right.  There are probably ways to fix this but....
>
> I'm becoming convinced this neighboring heuristic is the wrong approach.  First, the implementation is confusing, as evidenced by your inline comments. Second, and more importantly, it's growing special cases: CHECK-LABEL and now CHECK-NOT.  I fear it will become increasingly brittle as FileCheck evolves.

Though I agree with the problem of special casing, I'd like to add that the disctinction between positive and negative match directives will be needed for supporting numeric substitution block using a variable defined on the same directive. Regarding CHECK-LABEL, can't we have a data structure that allow browsing annotation by start line/point and end line/point? Is the position of CHECK-LABEL annotations in the list of annotation an artifact of how CHECK-LABEL are processed or is there a need for those annotation to be before another directive starting on the next line?

> What do you think?  Looking at the implementation, I think search ranges would be easy to capture for errors.

So you'd show neighboring lines around search range start and end? That looks like a better characterisation of what this patch was trying to do so I agree it seems like a good idea.


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

https://reviews.llvm.org/D96653



More information about the llvm-commits mailing list