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

[jdenny]

Summary

For example:

$ cat check
CHECK: start
CHECK-NEXT: end

$ FileCheck -v check < input |& tail -27
<<<<<<
         1: start
check:1     ^~~~~
         2: foo0
         3: foo1
         4: foo2
         5: foo3
         6: foo4
         .
         .
         .
        18: foo16
        19: foo17
        20: foo18
        21: foo19
        22: foo20
        23: end
next:2      !~~ error: match on wrong line
        24: bar0
        25: bar1
        26: bar2
        27: bar3
        28: bar4
         .
         .
         .
>>>>>>

Without this patch, input lines 1-6 are not shown. This patch reveals
those lines because that's where the actual problem is because that's
where the CHECK-NEXT directive was expected to match but didn't.
Seeing the line where CHECK-NEXT actually matched, line 23, is
typically less useful information in my experience.

In general, this patch depends on the following heuristics:

1. Any annotation that neighbors an error annotation is likely useful in debugging that error.
2. Revealing these annotations usually does not increase verbosity significantly.

To point 1, this patch facilitates debugging of several kinds of
errors, examples of which this patch adds to the test suite:

• A CHECK-NEXT or CHECK-SAME match on the wrong line.
• A CHECK-NOT unexpected match because a neighboring directive matched at an unexpected point, affecting the search range.
• An unmatched CHECK because a subsequent CHECK-LABEL matched at an unexpected point, affecting the search range.

To point 2:

• This patch is intended to reveal at most two neighboring annotations per error.
• This patch has no effect when neither -v or -vv is specified because annotations for successful directives are then not generated. Generally, I keep -vv in my environment's FILECHECK_OPTS, but I'm not sure other LLVM developers will want it enabled by default.
• This patch usually doesn't affect the most common kind of failure: a positive directive that doesn't match anything and that isn't followed by a CHECK-LABEL. First, its error annotation already starts at the preceding match, so context typically already reveals the preceding match's annotation. Second, no more directives are processed after the failure, so there are no subsequent annotations to reveal.
• This patch has no effect when -dump-input-filter is set to something other than error (the default). Other values usually produce more verbose input dumps already.

[thopre]

llvm/test/FileCheck/dump-input/filter-error-neighbor/multiline.txt

1–11

Could you do like the other tests and explain what input lines are revealed by this code?

llvm/utils/FileCheck/FileCheck.cpp

158–160

Isn't there one too many "annotations" in that sentence?

517–518

Is this saying that for a LABEL match ending at line L, the annotation for an error on line L-1 would be after the annotation for the LABEL match end at line L? Or is the "that precedes it" redundant and this is just saying that in the case of an error end and a LABEL end on line L, the label is first?

[jdenny]

llvm/utils/FileCheck/FileCheck.cpp

158–160

Semantically and grammatically, I think it's correct. Is your concern that so many occurrences of "annotations" makes it confusing?

517–518

An error can start on an earlier line than a label and end on the same line as the label, but, on that last line, the error is shown after the label. I agree it's confusing, I'll add an example to the comments.

[jdenny]

Addressed @thopre's comments.

llvm/test/FileCheck/dump-input/filter-error-neighbor/multiline.txt

1–11

Done. In most tests, I also clarified which lines are specifically revealed by -dump-input-filter=error vs. the lines added by -dump-input-context=2.

llvm/utils/FileCheck/FileCheck.cpp

158–160

I've made an attempt at clarifying the sentence. Please let me know if it helped.

[jhenderson]

This seems reasonable in general. I haven't got time to review the actual implementation though right now. If it's still open come next week, and I have the time, I'll try to take a look, but don't wait for me, if others are happy.

[jdenny]

In D96653#2567767, @jhenderson wrote:

This seems reasonable in general. I haven't got time to review the actual implementation though right now. If it's still open come next week, and I have the time, I'll try to take a look, but don't wait for me, if others are happy.

Thanks. This patch could affect many people, especially if many people are using -v or -vv as I always do, so I'd prefer more than one accept. In other words, I'm happy to wait a bit.

[jdenny]

llvm/utils/FileCheck/FileCheck.cpp

162

Oops, I added tabs. Will fix when there are more changes to make.

[thopre]

Would the neighbouring work if the error is on a CHECK-NOT and there's another CHECK-NOT immediately preceding and/or following it? Wouldn't the diagnostics for those other CHECK-NOT be the neighbouring diagnostics when what we would want is the neighbouring positive match (i.e. ignore CHECK-NOT)? In other word, with the following directives:

CHECK: start
CHECK-NOT: foo
CHECK-NOT: 42
CHECK-NOT: bar
CHECK: end

and an input consisting of:

start
lots of stuff
42
lots more stuff
end

would that reveal lines start and end or some of the stuff because the neighbouring code is looking at the neighbouring CHECK-NOT diagnostics?

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-label-follows.txt

3

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-next-same.txt

2

Why is the error on input line 2 for a CHECK-SAME?

llvm/test/FileCheck/dump-input/filter-error-neighbor/multiline.txt

1–11

That's very nice, thank you

4

I think the error line is confusing because it is not clear that the error refer to an input error as opposed to an annotation error. And that is precisely what confused me on my first reading of this patch. If I understood correctly the code, a NOT annotation error as in the range of lines from the first line after the preceding positive match directive (CHECK or CHECK-LABEL here) to the last line before the following positive match directive. i.e. the input error is in input line 16 but the annotation error goes from line 6 to line 27.

15

16

I'm confused. Doesn't the CHECK-NOT diagnostic run from line 6 to 27 and that's why line 3-7(5+2 context lines) and 25-29 (27+2 context lines) are revealed? Should that be talking about the span of the CHECK-NOT annotation/diagnostic instead of the CHECK-NOT match (line 16-17)?

My understanding is that the special handling does not cover the first label because it is only for a label immediately after the last line of a NOT, there's no symmetric special handling for before the error. Forgive me if I've misunderstood again.

[jdenny]

In 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.

The real point, which doesn't seem brittle or confusing, is that we want to see search ranges for errors (but probably not for successful patterns as that could get quite noisy). Actually, explicitly showing those search ranges rather than implying them via neighboring annotations is probably better for people who are still learning FileCheck's logic.

Currently, we show search ranges for unmatched patterns using X~~, and sometimes a fuzzy match appears within marked by ?~~. So now I guess I'm suggesting adding X~~ for unexpected matches as well, so !~~ would appear within. However, X~~ is currently documented to mean no match, which is wrong in the latter case. Moreover, I already find X~~ to be noisy for long search ranges, which most errors have. CHECK-NOT blocks are especially cluttered.

A less noisy (in most cases) possibility is for each end of the search range to be a separate annotation. The markers might be [ and ], but there are other bracketing symbols we could choose. For example:

<<<<<<
         . 
         . 
         . 
        28: ....
        29: ....
        30: start
check:1     ^~~~~
not:2'0          [ search range start
        31: ....   
        32: ....
         .
         . 
         . 
        59: ....
        60: ....
        61: foo
not:2'1     !~~  error: no match expected
        62: ....
        63: ....
         .
         .
         .
        88: ....
        89: ....
not:2'2         ] search range end
        90: end
check:3     ^~~
>>>>>>

At first, we might do this only for unexpected matches (CHECK-SAME/CHECK-NEXT match on the wrong line, or CHECK-NOT match). If we like it, we might then consider it for unmatched directives as well. In other words, X~~ would go away, and we'd have, for example:

<<<<<<
           .
           .
           .
          28: ....
          29: ....
          30: start
check:1       ^~~~~
check:2'0          [    error: no match found in search range starting here
          31: ....
          32: ....
          33: ....
           .
           .
           .
          87: ....
          88: ....
check:2'1         ] search range end
          89: end
check:3       ^~~
>>>>>>

(Again, there might be a fuzzy match marked by ?~~ within, but I didn't put together an example.)

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

In any case, thanks for your helpful review. I started writing responses to each of your inline comments, but now I'm thinking it might be best to just reboot.

[jhenderson]

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

Sorry for not spotting this question before. Your proposals seem okay to me, but I'm not sure I personally have any particular useful opinions on the topic, as I tend not to use the --dump-input option for various reasons, which are outside the scope of this work.

[thopre]

Sorry for the late review.

In D96653#2574627, @jdenny wrote:

In 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.

[jdenny]

In D96653#2574627, @jdenny wrote:

<<<<<<
           .
           .
           .
          28: ....
          29: ....
          30: start
check:1       ^~~~~
check:2'0          [    error: no match found in search range starting here
          31: ....
          32: ....
          33: ....
           .
           .
           .
          87: ....
          88: ....
check:2'1         ] search range end
          89: end
check:3       ^~~
>>>>>>

Oops. This example is a bit broken. check:3 would have to be a label or else it wouldn't be processed due to the check:2 error.

[jdenny]

In D96653#2589630, @jhenderson wrote:

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

Sorry for not spotting this question before. Your proposals seem okay to me,

Thanks for considering it.

but I'm not sure I personally have any particular useful opinions on the topic, as I tend not to use the --dump-input option for various reasons, which are outside the scope of this work.

I agree that should be a separate discussion, but I'd be interested to have it. Maybe it would lead to a better solution.

[jdenny]

In 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?

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?

The former. D77607 caused this. I still feel like D77607 is generally right. The strange part to me is that a preceding directive's search range ends at the end of the CHECK-LABEL match. It seems like it ought to end at the start of the CHECK-LABEL match. -dump-input reveals that CHECK-LABEL behavior is odd:

$ cat input 
foo

$ cat check 
CHECK: foo
CHECK-LABEL: foo

$ FileCheck -vv check < input |& tail -6
<<<<<<
         1: foo
label:2     ^~~
check:1     ^~~
label:2        X error: no match found
>>>>>>

Per input line, annotations are sorted by time. The CHECK-LABEL matches first. Then the CHECK matches the same text. Then CHECK-LABEL runs again and fails. I suppose the reason for this behavior is to catch poorly chosen labels.

Hopefully you see the value of D77607's sort by time: it make the FileCheck behavior clearer even when that behavior is odd.

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?

They should be included via --dump-input-context=N... except sometimes in the bizarre case someone sets N=0, but I'm not too worried about that.

That looks like a better characterisation of what this patch was trying to do so I agree it seems like a good idea.

Thanks for the review. I'll work on this.

[thopre]

In D96653#2590252, @jdenny wrote:

In 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.

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?

The former. D77607 caused this. I still feel like D77607 is generally right. The strange part to me is that a preceding directive's search range ends at the end of the CHECK-LABEL match. It seems like it ought to end at the start of the CHECK-LABEL match. -dump-input reveals that CHECK-LABEL behavior is odd:

$ cat input 
foo

$ cat check 
CHECK: foo
CHECK-LABEL: foo

$ FileCheck -vv check < input |& tail -6
<<<<<<
         1: foo
label:2     ^~~
check:1     ^~~
label:2        X error: no match found
>>>>>>

Per input line, annotations are sorted by time. The CHECK-LABEL matches first. Then the CHECK matches the same text. Then CHECK-LABEL runs again and fails. I suppose the reason for this behavior is to catch poorly chosen labels.

Hopefully you see the value of D77607's sort by time: it make the FileCheck behavior clearer even when that behavior is odd.

Ah yes that makes sense. Might be worth seaching why CHECK-NOT range ends at the end of the first line of the next CHECK-LABEL. Even if that were changed I do think focusing on search range rather than neighbouring annotations makes more sense.

[jdenny]

In D96653#2590308, @thopre wrote:

In D96653#2590252, @jdenny wrote:

In 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.

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.

[thopre]

In D96653#2590681, @jdenny wrote:

In D96653#2590308, @thopre wrote:

In D96653#2590252, @jdenny wrote:

In 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 :-)

[probinson]

The strange part to me is that a preceding directive's search range ends at the end of the CHECK-LABEL match. It seems like it ought to end at the start of the CHECK-LABEL match.

I'd expect the behavior of CHECK-NOT ranges to work the same for CHECK-LABEL as for a regular CHECK.

(I deeply regret not following through on the FileCheck model stuff... will put it on my to-do list, again.)

[jdenny]

In D96653#2594600, @probinson wrote:

The strange part to me is that a preceding directive's search range ends at the end of the CHECK-LABEL match. It seems like it ought to end at the start of the CHECK-LABEL match.

I'd expect the behavior of CHECK-NOT ranges to work the same for CHECK-LABEL as for a regular CHECK.

As far as I know, it does. However, before CHECK-LABEL, a CHECK-NOT range is not the same as a CHECK range:

$ cat input 
...
...
bar

$ cat check1
CHECK-NOT: foo
CHECK-LABEL: bar

$ cat check2
CHECK: bar
CHECK-LABEL: bar

$ FileCheck -dump-input=always -vv check1  < input |& tail -9
<<<<<<
           1: ...
not:1         X~~
           2: ...
not:1         ~~~
           3: bar
label:2'0     ^~~
label:2'1     ^~~
>>>>>>

$ FileCheck -vv check2  < input |& tail -8
<<<<<<
         1: ...
         2: ...
         3: bar
label:2     ^~~
check:1     ^~~
label:2        X error: no match found
>>>>>>

(I deeply regret not following through on the FileCheck model stuff... will put it on my to-do list, again.)

That discussion really helped me. It would be great to see it in the docs.

[probinson]

As far as I know, it does. However, before CHECK-LABEL, a CHECK-NOT range is not the same as a CHECK range:

So if you have

CHECK-NOT: bar
CHECK-LABEL: bar

it will invariably fail? (Trying to distinguish behavior of the directives from behavior of the dump output.)

[jdenny]

In D96653#2597491, @probinson wrote:

As far as I know, it does. However, before CHECK-LABEL, a CHECK-NOT range is not the same as a CHECK range:

So if you have

CHECK-NOT: bar
CHECK-LABEL: bar

it will invariably fail? (Trying to distinguish behavior of the directives from behavior of the dump output.)

For the example input I gave, it does not fail. I have no reason to believe the input dump is misrepresenting anything. It's the FileCheck matching behavior that's strange: CHECK-NOT's search range before CHECK-LABEL does not overlap with the CHECK-LABEL match. CHECK's search range before CHECK-LABEL does overlap with the CHECK-LABEL match. At least in the experiments I've tried. I've not investigated the implementation to determine why.

[thopre]

In D96653#2597515, @jdenny wrote:

In D96653#2597491, @probinson wrote:

As far as I know, it does. However, before CHECK-LABEL, a CHECK-NOT range is not the same as a CHECK range:

So if you have

CHECK-NOT: bar
CHECK-LABEL: bar

it will invariably fail? (Trying to distinguish behavior of the directives from behavior of the dump output.)

For the example input I gave, it does not fail. I have no reason to believe the input dump is misrepresenting anything. It's the FileCheck matching behavior that's strange: CHECK-NOT's search range before CHECK-LABEL does not overlap with the CHECK-LABEL match. CHECK's search range before CHECK-LABEL does overlap with the CHECK-LABEL match. At least in the experiments I've tried. I've not investigated the implementation to determine why.

What does the label:2 X error: no match found mean then? I thought this was (despite the prefix) applying to the CHECK since the CHECK is searched after the LABEL.

[jdenny]

In D96653#2597583, @thopre wrote:

What does the label:2 X error: no match found mean then? I thought this was (despite the prefix) applying to the CHECK since the CHECK is searched after the LABEL.

CHECK-LABEL runs twice: once before all other directives, and once with them. It's the second run that fails in the case you quoted.

[jdenny]

As discussed, I'll try a different solution for this issue this patch addresses, probably in a different review.

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-dag.txt

+; The neighboring behavior of -dump-input-filter=error does not reveal lines
+; that are within an error annotation.  CHECK-DAG is the reason.  In the example
+; below, it would cause all the CHECK-DAG matches to be revealed.
+;
+; Moreover, the neighboring implementation has special handling for CHECK-LABEL
+; in that its match is revealed if it precedes the last line of an error.  That
+; special handling shouldn't be applied to other directives.  Otherwise, the
+; successful CHECK-DAG match at the end of the CHECK-DAG error here would be
+; revealed accidentally.
+
+     CHECK:<<<<<<
+CHECK-NEXT:        1: loop iter 3
+CHECK-NEXT:dag:4      ^~~~~~~~~~~
+CHECK-NEXT:dag:10     X~~~~~~~~~~ error: no match found
+CHECK-NEXT:        2: loop iter 0
+CHECK-NEXT:dag:1      ^~~~~~~~~~~
+CHECK-NEXT:dag:10     ~~~~~~~~~~~
+CHECK-NEXT:        3: loop iter 4
+CHECK-NEXT:dag:5      ^~~~~~~~~~~
+CHECK-NEXT:dag:10     ~~~~~~~~~~~
+CHECK-NEXT:        .
+CHECK-NEXT:        .
+CHECK-NEXT:        .
+CHECK-NEXT:>>>>>>
+
+RUN: echo 'CHECK-DAG: loop iter 0'  >  %t.chk
+RUN: echo 'CHECK-DAG: loop iter 1'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 2'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 3'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 4'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 5'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 6'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 7'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 8'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 9'  >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 10' >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 11' >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 12' >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 13' >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 14' >> %t.chk
+RUN: echo 'CHECK-DAG: loop iter 15' >> %t.chk
+
+RUN: echo 'loop iter 3'  >  %t.in
+RUN: echo 'loop iter 0'  >> %t.in
+RUN: echo 'loop iter 4'  >> %t.in
+RUN: echo 'loop iter 6'  >> %t.in
+RUN: echo 'loop iter 12' >> %t.in
+RUN: echo 'loop iter 7'  >> %t.in
+RUN: echo 'loop iter 8'  >> %t.in
+RUN: echo 'loop iter 14' >> %t.in
+RUN: echo 'loop iter 2'  >> %t.in
+RUN: echo 'loop iter 11' >> %t.in
+RUN: echo 'loop iter 1'  >> %t.in
+RUN: echo 'loop iter 15' >> %t.in
+RUN: echo 'loop iter 13' >> %t.in
+RUN: echo 'loop iter 10' >> %t.in
+RUN: echo 'loop iter 5'  >> %t.in
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-label-follows.txt

+; The neighboring behavior of -dump-input-filter=error reveals input lines 12-16
+; below (neighbor of an error).  Those lines are where the actual problem is:
+; the "host triples:" header is off by one.  Sometimes the key to understanding
+; a directive's failure is where the following CHECK-LABEL matched because it
+; limits the search range.
+
+     CHECK:<<<<<<
+CHECK-NEXT:           1: offload triples:
+CHECK-NEXT:label:1'0     ^~~~~~~~~~~~~~~~
+CHECK-NEXT:label:1'1     ^~~~~~~~~~~~~~~~
+CHECK-NEXT:           2: - x86_64-linux-gnu
+CHECK-NEXT:check:2'0     X~~~~~~~~~~~~~~~~~ error: no match found
+CHECK-NEXT:check:2'1       ?                possible intended match
+CHECK-NEXT:           3: - x86_64-unknown-linux-gnu
+CHECK-NEXT:check:2'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~
+CHECK-NEXT:           4: - x86_64-pc-linux-gnu
+CHECK-NEXT:check:2'0     ~~~~~~~~~~~~~~~~~~~~~
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:          12: - x86_64-amazon-linux
+CHECK-NEXT:check:2'0     ~~~~~~~~~~~~~~~~~~~~~
+CHECK-NEXT:          13: - x86_64-linux-android
+CHECK-NEXT:check:2'0     ~~~~~~~~~~~~~~~~~~~~~~
+CHECK-NEXT:          14: host triples:
+CHECK-NEXT:label:3       ^~~~~~~~~~~~~
+CHECK-NEXT:check:2'0     ~~~~~~~~~~~~~
+CHECK-NEXT:          15: - nvptx64-nvidia-cuda
+CHECK-NEXT:          16: - x86_64-linux-gnu
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:>>>>>>
+
+RUN: echo 'CHECK-LABEL: offload triples:' >  %t.chk
+RUN: echo 'CHECK: nvptx64-nvidia-cuda'    >> %t.chk
+RUN: echo 'CHECK-LABEL: host triples:'    >> %t.chk
+
+RUN: echo 'offload triples:'           >  %t.in
+RUN: echo '- x86_64-linux-gnu'         >> %t.in
+RUN: echo '- x86_64-unknown-linux-gnu' >> %t.in
+RUN: echo '- x86_64-pc-linux-gnu'      >> %t.in
+RUN: echo '- x86_64-redhat-linux6E'    >> %t.in
+RUN: echo '- x86_64-redhat-linux'      >> %t.in
+RUN: echo '- x86_64-suse-linux'        >> %t.in
+RUN: echo '- x86_64-manbo-linux-gnu'   >> %t.in
+RUN: echo '- x86_64-linux-gnu'         >> %t.in
+RUN: echo '- x86_64-slackware-linux'   >> %t.in
+RUN: echo '- x86_64-unknown-linux'     >> %t.in
+RUN: echo '- x86_64-amazon-linux'      >> %t.in
+RUN: echo '- x86_64-linux-android'     >> %t.in
+RUN: echo 'host triples:'              >> %t.in
+RUN: echo '- nvptx64-nvidia-cuda'      >> %t.in
+RUN: echo '- x86_64-linux-gnu'         >> %t.in
+RUN: echo '- x86_64-unknown-linux-gnu' >> %t.in
+RUN: echo '- x86_64-pc-linux-gnu'      >> %t.in
+RUN: echo '- x86_64-redhat-linux6E'    >> %t.in
+RUN: echo '- x86_64-redhat-linux'      >> %t.in
+RUN: echo '- x86_64-suse-linux'        >> %t.in
+RUN: echo '- x86_64-manbo-linux-gnu'   >> %t.in
+RUN: echo '- x86_64-linux-gnu'         >> %t.in
+RUN: echo '- x86_64-slackware-linux'   >> %t.in
+RUN: echo '- x86_64-unknown-linux'     >> %t.in
+RUN: echo '- x86_64-amazon-linux'      >> %t.in
+RUN: echo '- x86_64-linux-android'     >> %t.in
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-next-same.txt

+; The neighboring behavior of -dump-input-filter=error reveals input lines 1-3
+; below (neighbor preceding an error).  Those lines are where the actual problem
+; is because that's where the CHECK-NEXT/CHECK-SAME directive was expected to
+; match but didn't.  Seeing the line where CHECK-NEXT/CHECK-SAME actually
+; matched, line 13, is typically less useful information.
+
+     CHECK:<<<<<<
+CHECK-NEXT:         1: start
+CHECK-NEXT:check:1     ^~~~~
+CHECK-NEXT:         2: foo0
+CHECK-NEXT:         3: foo1
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:        11: foo9
+CHECK-NEXT:        12: foo10
+CHECK-NEXT:        13: end
+ NEXT-NEXT:next:2      !~~ error: match on wrong line
+ SAME-NEXT:same:2      !~~ error: match on wrong line
+CHECK-NEXT:>>>>>>
+
+RUN: echo 'CHECK: start'    >  %t.next.chk
+RUN: echo 'CHECK-NEXT: end' >> %t.next.chk
+
+RUN: echo 'CHECK: start'    >  %t.same.chk
+RUN: echo 'CHECK-SAME: end' >> %t.same.chk
+
+RUN: echo start >  %t.in
+RUN: echo foo0  >> %t.in
+RUN: echo foo1  >> %t.in
+RUN: echo foo2  >> %t.in
+RUN: echo foo3  >> %t.in
+RUN: echo foo4  >> %t.in
+RUN: echo foo5  >> %t.in
+RUN: echo foo6  >> %t.in
+RUN: echo foo7  >> %t.in
+RUN: echo foo8  >> %t.in
+RUN: echo foo9  >> %t.in
+RUN: echo foo10 >> %t.in
+RUN: echo end   >> %t.in
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.next.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines -check-prefixes=CHECK,NEXT
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.same.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines -check-prefixes=CHECK,SAME

llvm/test/FileCheck/dump-input/filter-error-neighbor/check-not.txt

+; The neighboring behavior of -dump-input-filter=error reveals input lines 1-3
+; and 60-63 below.  With only the former (neighbor preceding an error), it looks
+; like the host list includes a GPU triple.  The latter (neighbor following an
+; error) reveals we have an accidentally nested list.  Often the key to
+; understanding a CHECK-NOT failure is where the directives before and after it
+; matched because those establish the search range.
+
+     CHECK:<<<<<<
+CHECK-NEXT:         1: <triples kind="host">
+CHECK-NEXT:check:1     ^~~~~~~~~~~~~~~~~~~~~
+CHECK-NEXT:         2:  x86_64-linux-gnu
+CHECK-NEXT:         3:  x86_64-unknown-linux-gnu
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:        42:  x86_64-amazon-linux
+CHECK-NEXT:        43:  x86_64-linux-android
+CHECK-NEXT:        44:  nvptx64-nvidia-cuda
+CHECK-NEXT:not:2        !~~~~~~~~~~~~~~~~~~ error: no match expected
+CHECK-NEXT:        45:  i686-linux-gnu
+CHECK-NEXT:        46:  i686-pc-linux-gnu
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:         .
+CHECK-NEXT:        60:  i586-gnu
+CHECK-NEXT:        61:  i686-gnu
+CHECK-NEXT:        62: </triples>
+CHECK-NEXT:check:3     ^~~~~~~~~~
+CHECK-NEXT:        63: </triples>
+CHECK-NEXT:>>>>>>
+
+RUN: echo 'CHECK: <triples kind="host">'   >  %t.chk
+RUN: echo 'CHECK-NOT: nvptx64-nvidia-cuda' >> %t.chk
+RUN: echo 'CHECK: </triples>'              >> %t.chk
+
+RUN: echo '<triples kind="host">'      >  %t.in
+RUN: echo '  x86_64-linux-gnu'         >> %t.in
+RUN: echo '  x86_64-unknown-linux-gnu' >> %t.in
+RUN: echo '  x86_64-pc-linux-gnu'      >> %t.in
+RUN: echo '  x86_64-redhat-linux6E'    >> %t.in
+RUN: echo '  x86_64-redhat-linux'      >> %t.in
+RUN: echo '  x86_64-suse-linux'        >> %t.in
+RUN: echo '  x86_64-manbo-linux-gnu'   >> %t.in
+RUN: echo '  x86_64-linux-gnu'         >> %t.in
+RUN: echo '  x86_64-slackware-linux'   >> %t.in
+RUN: echo '  x86_64-unknown-linux'     >> %t.in
+RUN: echo '  x86_64-amazon-linux'      >> %t.in
+RUN: echo '  x86_64-linux-android'     >> %t.in
+RUN: echo '  i686-linux-gnu'           >> %t.in
+RUN: echo '  i686-pc-linux-gnu'        >> %t.in
+RUN: echo '  i486-linux-gnu'           >> %t.in
+RUN: echo '  i386-linux-gnu'           >> %t.in
+RUN: echo '  i386-redhat-linux6E'      >> %t.in
+RUN: echo '  i686-redhat-linux'        >> %t.in
+RUN: echo '  i586-redhat-linux'        >> %t.in
+RUN: echo '  i386-redhat-linux'        >> %t.in
+RUN: echo '  i586-suse-linux'          >> %t.in
+RUN: echo '  i486-slackware-linux'     >> %t.in
+RUN: echo '  i686-montavista-linux'    >> %t.in
+RUN: echo '  i586-linux-gnu'           >> %t.in
+RUN: echo '  i686-linux-android'       >> %t.in
+RUN: echo '  i386-gnu'                 >> %t.in
+RUN: echo '  i486-gnu'                 >> %t.in
+RUN: echo '  i586-gnu'                 >> %t.in
+RUN: echo '  i686-gnu'                 >> %t.in
+RUN: echo '<triples kind="offload">'   >> %t.in
+RUN: echo '  x86_64-linux-gnu'         >> %t.in
+RUN: echo '  x86_64-unknown-linux-gnu' >> %t.in
+RUN: echo '  x86_64-pc-linux-gnu'      >> %t.in
+RUN: echo '  x86_64-redhat-linux6E'    >> %t.in
+RUN: echo '  x86_64-redhat-linux'      >> %t.in
+RUN: echo '  x86_64-suse-linux'        >> %t.in
+RUN: echo '  x86_64-manbo-linux-gnu'   >> %t.in
+RUN: echo '  x86_64-linux-gnu'         >> %t.in
+RUN: echo '  x86_64-slackware-linux'   >> %t.in
+RUN: echo '  x86_64-unknown-linux'     >> %t.in
+RUN: echo '  x86_64-amazon-linux'      >> %t.in
+RUN: echo '  x86_64-linux-android'     >> %t.in
+RUN: echo '  nvptx64-nvidia-cuda'      >> %t.in
+RUN: echo '  i686-linux-gnu'           >> %t.in
+RUN: echo '  i686-pc-linux-gnu'        >> %t.in
+RUN: echo '  i486-linux-gnu'           >> %t.in
+RUN: echo '  i386-linux-gnu'           >> %t.in
+RUN: echo '  i386-redhat-linux6E'      >> %t.in
+RUN: echo '  i686-redhat-linux'        >> %t.in
+RUN: echo '  i586-redhat-linux'        >> %t.in
+RUN: echo '  i386-redhat-linux'        >> %t.in
+RUN: echo '  i586-suse-linux'          >> %t.in
+RUN: echo '  i486-slackware-linux'     >> %t.in
+RUN: echo '  i686-montavista-linux'    >> %t.in
+RUN: echo '  i586-linux-gnu'           >> %t.in
+RUN: echo '  i686-linux-android'       >> %t.in
+RUN: echo '  i386-gnu'                 >> %t.in
+RUN: echo '  i486-gnu'                 >> %t.in
+RUN: echo '  i586-gnu'                 >> %t.in
+RUN: echo '  i686-gnu'                 >> %t.in
+RUN: echo '</triples>'                 >> %t.in
+RUN: echo '</triples>'                 >> %t.in
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines

llvm/test/FileCheck/dump-input/filter-error-neighbor/multiline.txt

+; -dump-input-filter=error reveals only the first or last line of an annotation
+; neighboring an error, depending on whether it precedes or follows the error.
+; This test checks that we don't mix up first and last.  Otherwise, a preceding
+; or following annotation can accidentally be omitted altogether.  Of course,
+; we must have multiline annotations so that first != last.
+;
+; This test also checks that CHECK-LABEL is handled in the same way.  That is,
+; CHECK-LABEL has additional special handling in that its match is revealed if
+; it precedes the last line of an error, but that special handling alone
+; wouldn't be sufficient for CHECK-LABEL here: it wouldn't reveal the first
+; CHECK-LABEL's match because the CHECK-NOT match has multiple lines.
+
+     CHECK:<<<<<<
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           3: start
+  CHK-NEXT:check:1       ~~~~~
+  LAB-NEXT:label:1'0     ~~~~~
+  LAB-NEXT:label:1'1     ~~~~~
+CHECK-NEXT:           4: start
+  CHK-NEXT:check:1       ~~~~~
+  LAB-NEXT:label:1'0     ~~~~~
+  LAB-NEXT:label:1'1     ~~~~~
+CHECK-NEXT:           5: start
+  CHK-NEXT:check:1       ~~~~~
+  LAB-NEXT:label:1'0     ~~~~~
+  LAB-NEXT:label:1'1     ~~~~~
+CHECK-NEXT:           6: bar
+CHECK-NEXT:           7: bar
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:          14: bar
+CHECK-NEXT:          15: bar
+CHECK-NEXT:          16: foo
+CHECK-NEXT:not:2         !~~ error: no match expected
+CHECK-NEXT:          17: foo
+CHECK-NEXT:not:2         ~~~
+CHECK-NEXT:          18: bar
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:          26: bar
+CHECK-NEXT:          27: bar
+CHECK-NEXT:          28: end
+  CHK-NEXT:check:3       ^~~
+  LAB-NEXT:label:3'0     ^~~
+  LAB-NEXT:label:3'1     ^~~
+CHECK-NEXT:          29: end
+  CHK-NEXT:check:3       ~~~
+  LAB-NEXT:label:3'0     ~~~
+  LAB-NEXT:label:3'1     ~~~
+CHECK-NEXT:          30: end
+  CHK-NEXT:check:3       ~~~
+  LAB-NEXT:label:3'0     ~~~
+  LAB-NEXT:label:3'1     ~~~
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:           .
+CHECK-NEXT:>>>>>>
+
+RUN: echo 'CHECK: start{{([[:space:]]*start)+}}' >  %t.chk.chk
+RUN: echo 'CHECK-NOT: foo{{([[:space:]]*foo)*}}' >> %t.chk.chk
+RUN: echo 'CHECK: end{{([[:space:]]*end)+}}'     >> %t.chk.chk
+
+RUN: echo 'CHECK-LABEL: start{{([[:space:]]*start)+}}' >  %t.lab.chk
+RUN: echo 'CHECK-NOT: foo{{([[:space:]]*foo)*}}'       >> %t.lab.chk
+RUN: echo 'CHECK-LABEL: end{{([[:space:]]*end)+}}'     >> %t.lab.chk
+
+RUN: echo 'start' >  %t.in
+RUN: echo 'start' >> %t.in
+RUN: echo 'start' >> %t.in
+RUN: echo 'start' >> %t.in
+RUN: echo 'start' >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'foo'   >> %t.in
+RUN: echo 'foo'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'bar'   >> %t.in
+RUN: echo 'end'   >> %t.in
+RUN: echo 'end'   >> %t.in
+RUN: echo 'end'   >> %t.in
+RUN: echo 'end'   >> %t.in
+RUN: echo 'end'   >> %t.in
+
+XUN: %ProtectFileCheckOutput \
+XUN: not FileCheck -dump-input-context=2 -v %t.chk.chk < %t.in 2>&1 \
+XUN:               -dump-input-filter=error \
+XUN: | FileCheck %s -match-full-lines -check-prefixes=CHECK,CHK
+
+RUN: %ProtectFileCheckOutput \
+RUN: not FileCheck -dump-input-context=2 -v %t.lab.chk < %t.in 2>&1 \
+RUN:               -dump-input-filter=error \
+RUN: | FileCheck %s -match-full-lines -check-prefixes=CHECK,LAB

llvm/test/FileCheck/dump-input/filter.txt

 ; ANNOTATION-NEXT:            .
 ; ANNOTATION-NEXT:            .
 ; ANNOTATION-NEXT: >>>>>>
 
 ;      ERROR: <<<<<<
 ; ERROR-NEXT:            .
 ; ERROR-NEXT:            .
 ; ERROR-NEXT:            .
+; ERROR-NEXT:           10: foo8
 ; ERROR-NEXT:           11: foo9
 ; ERROR-NEXT:           12: hello
 ; ERROR-NEXT: check:2       ^~~~~
 ; ERROR-NEXT:           13: foo0
 ; ERROR-NEXT: check:3'0     X~~~ error: no match found
 ; ERROR-NEXT:           14: foo1
 ; ERROR-NEXT: check:3'0     ~~~~
 ; ERROR-NEXT:           15: foo2

 
 ; RUN: %ProtectFileCheckOutput \
 ; RUN: not FileCheck -dump-input-context=0 -dump-input-filter=error \
 ; RUN:               %t.next-err.chk < %t.next-err.in 2>&1 \
 ; RUN: | FileCheck %s -match-full-lines -check-prefixes=NEXT-ERR
 
 ;      NEXT-ERR:         3: bar
 ; NEXT-ERR-NEXT: next:2     !~~ error: match on wrong line
 No newline at end of file

llvm/utils/FileCheck/FileCheck.cpp

cl::desc("In the dump requested by -dump-input, print only input lines of\n"
              "default is 'error' when -dump-input=fail, and it's 'all' when\n"
              "-dump-input=always.\n"),
     cl::values(clEnumValN(DumpInputFilterAll, "all", "All input lines"),
                clEnumValN(DumpInputFilterAnnotationFull, "annotation-full",
                           "Input lines with annotations"),
                clEnumValN(DumpInputFilterAnnotation, "annotation",
                           "Input lines with starting points of annotations"),
                clEnumValN(DumpInputFilterError, "error",
                           "Input lines with starting points of error "
+                          "annotations or with annotations that neighbor error "
                           "annotations")));
 
 static cl::list<unsigned> DumpInputContexts(
     "dump-input-context", cl::value_desc("N"),
     cl::desc("In the dump requested by -dump-input, print <N> input lines\n"
              "before and <N> input lines after any lines specified by\n"
              "-dump-input-filter.  When there are multiple occurrences of\n"
              "this option, the largest specified <N> has precedence.  The\n"
              "default is 5.\n"));
 
 typedef cl::list<std::string>::const_iterator prefix_iterator;
static void DumpInputAnnotationHelp(raw_ostream &OS) {
   WithColor(OS, raw_ostream::CYAN, true, false) << "discarded match";
   OS << ", ";
   WithColor(OS, raw_ostream::CYAN, true, true) << "unmatched input";
   OS << "\n";
 }
 
 /// An annotation for a single input line.
 struct InputAnnotation {
-  /// The index of the match result across all checks
+  /// The index of the match result across all checks.
   unsigned DiagIndex;
+  /// The kind of check that produced the match result.
+  Check::FileCheckType CheckTy;
   /// The label for this annotation.
   std::string Label;
-  /// Is this the initial fragment of a diagnostic that has been broken across
-  /// multiple lines?
+  /// Is this the initial annotation for a diagnostic, which might be broken
+  /// across multiple lines?
   bool IsFirstLine;
+  /// Is this the last annotation for a diagnostic, which might be broken across
+  /// multiple lines?
+  bool IsLastLine;
   /// What input line (one-origin indexing) this annotation marks.  This might
   /// be different from the starting line of the original diagnostic if
   /// !IsFirstLine.
   unsigned InputLine;
   /// The column range (one-origin indexing, open end) in which to mark the
   /// input line.  If InputEndCol is UINT_MAX, treat it as the last column
   /// before the newline.
   unsigned InputStartCol, InputEndCol;
BuildInputAnnotations(const SourceMgr &SM, unsigned CheckFileBufferID,
   // How many diagnostics has the current check seen so far?
   unsigned CheckDiagCount = 0;
   // What's the widest label?
   LabelWidth = 0;
   for (auto DiagItr = Diags.begin(), DiagEnd = Diags.end(); DiagItr != DiagEnd;
        ++DiagItr) {
     InputAnnotation A;
     A.DiagIndex = DiagCount++;
+    A.CheckTy = DiagItr->CheckTy;
 
     // Build label, which uniquely identifies this check result.
     unsigned CheckBufferID = SM.FindBufferContainingLoc(DiagItr->CheckLoc);
     auto CheckLineAndCol =
         SM.getLineAndColumn(DiagItr->CheckLoc, CheckBufferID);
     llvm::raw_string_ostream Label(A.Label);
     Label << GetCheckTypeAbbreviation(DiagItr->CheckTy) << ":";
     if (CheckBufferID == CheckFileBufferID)
if (!DiagItr->Note.empty()) {
         A.Marker.Lead = ' ';
     }
     A.FoundAndExpectedMatch =
         DiagItr->MatchTy == FileCheckDiag::MatchFoundAndExpected;
 
     // Compute the mark location, and break annotation into multiple
     // annotations if it spans multiple lines.
     A.IsFirstLine = true;
+    A.IsLastLine = false;
     A.InputLine = DiagItr->InputStartLine;
     A.InputStartCol = DiagItr->InputStartCol;
     if (DiagItr->InputStartLine == DiagItr->InputEndLine) {
       // Sometimes ranges are empty in order to indicate a specific point, but
       // that would mean nothing would be marked, so adjust the range to
       // include the following character.
       A.InputEndCol =
           std::max(DiagItr->InputStartCol + 1, DiagItr->InputEndCol);
       Annotations.push_back(A);
     } else {
       assert(DiagItr->InputStartLine < DiagItr->InputEndLine &&
              "expected input range not to be inverted");
       A.InputEndCol = UINT_MAX;
       Annotations.push_back(A);
       for (unsigned L = DiagItr->InputStartLine + 1, E = DiagItr->InputEndLine;
            L <= E; ++L) {
         // If a range ends before the first column on a line, then it has no
         // characters on that line, so there's nothing to render.
         if (DiagItr->InputEndCol == 1 && L == E)
           break;
         InputAnnotation B;
         B.DiagIndex = A.DiagIndex;
+        B.CheckTy = A.CheckTy;
         B.Label = A.Label;
         B.IsFirstLine = false;
+        B.IsLastLine = false;
         B.InputLine = L;
         B.Marker = A.Marker;
         B.Marker.Lead = '~';
         B.Marker.Note = "";
         B.InputStartCol = 1;
         if (L != E)
           B.InputEndCol = UINT_MAX;
         else
           B.InputEndCol = DiagItr->InputEndCol;
         B.FoundAndExpectedMatch = A.FoundAndExpectedMatch;
         Annotations.push_back(B);
       }
     }
+    Annotations.back().IsLastLine = true;
   }
 }
 
 static unsigned FindInputLineInFilter(
     DumpInputFilterValue DumpInputFilter, unsigned CurInputLine,
-    const std::vector<InputAnnotation>::iterator &AnnotationBeg,
-    const std::vector<InputAnnotation>::iterator &AnnotationEnd) {
+    const std::vector<InputAnnotation>::iterator &AnnotationCur,
+    const std::vector<InputAnnotation> &Annotations) {
   if (DumpInputFilter == DumpInputFilterAll)
     return CurInputLine;
-  for (auto AnnotationItr = AnnotationBeg; AnnotationItr != AnnotationEnd;
+  auto AnnotationBeg = Annotations.begin();
+  auto AnnotationEnd = Annotations.end();
+  for (auto AnnotationItr = AnnotationCur; AnnotationItr != AnnotationEnd;
        ++AnnotationItr) {
     switch (DumpInputFilter) {
     case DumpInputFilterAll:
       llvm_unreachable("unexpected DumpInputFilterAll");
       break;
     case DumpInputFilterAnnotationFull:
       return AnnotationItr->InputLine;
     case DumpInputFilterAnnotation:
       if (AnnotationItr->IsFirstLine)
         return AnnotationItr->InputLine;
       break;
     case DumpInputFilterError:
+      // If it's the first line of an error, include it.
       if (AnnotationItr->IsFirstLine && AnnotationItr->Marker.FiltersAsError)
         return AnnotationItr->InputLine;
+      // If it's a diagnostic's first line and it's after the last line of an
+      // error, include it.  This might reveal an incorrect end to a search
+      // range.
+      if (AnnotationItr->IsFirstLine && AnnotationItr != AnnotationBeg) {
+        auto AnnotationPrev = std::prev(AnnotationItr);
+        if (AnnotationPrev->Marker.FiltersAsError && AnnotationPrev->IsLastLine)
+          return AnnotationItr->InputLine;
+      }
+      // If it's a diagnostic's last line and it's before the first line of an
+      // error, include it.  This might reveal an incorrect start to a search
+      // range.  It might reveal the incorrect text where a CHECK-NEXT or
+      // CHECK-SAME was expected to match but instead matched on a later line.
+      //
+      // As a special exception, if it's the last line of a CHECK-LABEL match
+      // before the last line of an error, include it.  A CHECK-LABEL directive
+      // is processed before all other directives, so its annotation precedes
+      // the last line of an error that precedes it.  Don't apply that exception
+      // generally, or a CHECK-DAG error can produce a spurious inclusion due to
+      // a successful CHECK-DAG at the end of the search range.
+      //
+      // Because we include last lines sometimes, input lines from
+      // DumpInputFilterError are not always a subset of input lines from
+      // DumpInputFilterAnnotation.
+      if (AnnotationItr->IsLastLine) {
+        auto AnnotationNext = std::next(AnnotationItr);
+        if (AnnotationNext != AnnotationEnd &&
+            AnnotationNext->Marker.FiltersAsError &&
+            (AnnotationNext->IsFirstLine ||
+             (AnnotationItr->CheckTy == Check::CheckLabel &&
+              AnnotationNext->IsLastLine)))
+          return AnnotationItr->InputLine;
+      }
+      // We have included only first and last lines of diagnostics so that we
+      // don't include a line within an error just because it's next to a
+      // "possible intended match" diagnostic.  The "possible intended match"
+      // diagnostic is included on its own merits anyway, but the amount of
+      // context could be unexpectedly augmented.
+      //
+      // We have not included lines just because they're next to non-first and
+      // non-last error lines.  Otherwise, a CHECK-DAG error could include many
+      // lines for successful matches from the same CHECK-DAG block.
       break;
     }
   }
   return UINT_MAX;
 }
 
 /// To OS, print a vertical ellipsis (right-justified at LabelWidth) if it would
 /// occupy less lines than ElidedLines, but print ElidedLines otherwise.  Either
static void DumpAnnotatedInput(raw_ostream &OS, const FileCheckRequest &Req,
   for (unsigned Line = 1;
        InputFilePtr != InputFileEnd || AnnotationItr != AnnotationEnd;
        ++Line) {
     const unsigned char *InputFileLine = InputFilePtr;
 
     // Compute the previous and next line included by the filter.
     if (NextLineInFilter < Line)
       NextLineInFilter = FindInputLineInFilter(DumpInputFilter, Line,
-                                               AnnotationItr, AnnotationEnd);
+                                               AnnotationItr, Annotations);
     assert(NextLineInFilter && "expected NextLineInFilter to be computed");
     if (NextLineInFilter == Line)
       PrevLineInFilter = Line;
 
     // Elide this input line and its annotations if it's not within the
     // context specified by -dump-input-context of an input line included by
     // -dump-input-filter.  However, in case the resulting ellipsis would occupy
     // more lines than the input lines and annotations it elides, buffer the