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

[Thomas Preud'homme via Phabricator via llvm-commits]

thopre added a comment.

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

> In D96653#2590308 <https://reviews.llvm.org/D96653#2590308>, @thopre wrote:
>
>> In D96653#2590252 <https://reviews.llvm.org/D96653#2590252>, @jdenny wrote:
>>
>>> In D96653#2589769 <https://reviews.llvm.org/D96653#2589769>, @thopre wrote:
>>>
>>>> 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.
>>>
>>> I don't follow.  I might have missed a discussion.  Could you provide a quick example?
>>
>> I was referring to https://lists.llvm.org/pipermail/llvm-dev/2020-June/142188.html . We already have a distinction between positive and negative match since we do PrintMatch or PrintNoMatch depending on that.
>
> Thanks for the link.  I remember that discussion.
>
> Is your point that there are multiple parts of FileCheck's implementation where we must distinguish between positive and negative matches, and so whatever solution we choose for the current issue may have to make that distinction as well?  If so, point taken.

Not quite. My point is that you should not worry about having to distinguish between positive Vs negative for whatever solution to this problem because that distinction is going to be required for other features as well.

> However, it seems we're in agreement that search ranges are the better approach anyway.  I hope that approach will permit the -dump-input presentation layer (which I suppose is not well delineated) and FileCheck's matching logic to be less tightly coupled than the current patch requires.

I hope so too :-)


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

https://reviews.llvm.org/D96653