[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