NLL: Deduplicate errors for incorrect move in loop

[davidtwco]

Fixes#53807.

r? @nikomatsakis

[davidtwco]

I'm not sure if this approach to deduplicating errors is the best approach, but it seems to have been relatively effective with only one case I'd consider a regression.

I'm happy to take another approach if this isn't deemed optimal.

[pnkfelix]

Hmm. Do you have an intuition as to which of the errors are being preferred for presentation by this PR? I am a little surprised to see it favoring the error on line 29 here over the ones on line 28.

I guess I'd want to make sure we don't run into a scenario where a beginner erroneously infers that some statement is not performing a move (or does not have a use of the local, whatever), when in fact there is a move/use at that statement, but the diagnostic system is filtering the error mentioning it out from the error report.

[davidtwco]

This PR groups errors by the MoveOutIndex(s) that are relevant (however this error reporting function was coming to that conclusion previously) and then emitting, for that grouping, the error that corresponds to the place that is most "specific".

In this case, a more "specific" means a Place that is not a prefix of a less "specific" Place. So I just decline to create and buffer an error if the Place for that error is a prefix of the Place that I already have a buffered error for.

There's a log statement that indicates an error is being suppressed and you still get the log statement showing which arguments the reporting function was called with before it suppresses it. There's also a comment attempting to explain the above logic on the field that stores the buffered errors.

[nikomatsakis]

Hmm, @pnkfelix has an interesting point — or, at least, I that citing some point in a match arm as a "use" is more confusing than citing the match foo { itself.

Did you experiment with preferring the most general move? e.g., if the common prefix of the grouping is foo, perhaps preferring moves of foo?

That said, I don't think we should dump a ton of errors relating to a single move — I think that is more likely to confuse users. I could imagine trying to include more than one "use after move" point within the error itself.

e.g., we might display

 --> $DIR/issue-17385.rs:28:11
|
LL | drop(foo);
| --- value moved here
LL | match foo { //~ ERROR use of moved value
| ^^^ value used here after move
LL | X(1) => (),
| - value also used here after move
= note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait

sorry the indentation doesn't line up, hopefully you get the idea

[nikomatsakis]

or perhaps with a kind of "note" like

 --> $DIR/issue-17385.rs:28:11
|
LL | drop(foo);
| --- value moved here
LL | match foo { //~ ERROR use of moved value
| ^^^ value used here after move
= note: move occurs because `foo` has type `X`, which does not implement the `Copy` trait
= note: value is also used in other places after the move
LL | X(1) => (),
| -

[davidtwco]

I didn't try the the most general move. When I was digging into the example case from the issue, I thought the best error there was the one with the "used in previous iteration of loop" message, and I noticed it was on the most specific place, which is why I used that as my heuristic.

[nikomatsakis]

r=me with comment

[bors]

📌 Commit 88ca341 has been approved by nikomatsakis

[davidtwco]

@bors retry #40474

[bors]

⌛ Testing commit 88ca341 with merge 8f37677...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 8f37677 to master...