diagnostics: Point closure trait errors at captured values

[Dnreikronos]

Fixes #161371

Right now this error knows that something captured by a closure doesn't meet a trait bound, but the note points at the whole closure. That's fine in a tiny example. Once the closure has a bunch of captures, it's pretty annoying because you still have to hunt down the value that caused it.

The useful type is already in the obligation chain, so the diagnostic keeps it while walking back to the closure and matches it with the capture list. The next solver puts an internal tuple in the middle, which is a little awkward, so the diagnostic skips that part. Then the note can name the capture and point at where it was used. If the match doesn't work, rustc keeps the old note.

I first thought about carrying capture info from the trait solver itself, but that felt like a lot of plumbing for one diagnostic. Keeping it in error reporting felt smaller and easier to follow. I added a test with one bad capture next to an unrelated one, then updated the existing UI output that now gets the more useful span.

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, types
• compiler, types expanded to 75 candidates
• Random selection from 19 candidates

[bardiharborow]

@rustbot label +A-closures +A-auto-traits +C-enhancement +D-terse

[JohnTitor]

This condition would override the existing error unintentionally, like:

#![recursion_limit = "2"]
fn require_send<T: Send>(_: T) {}
fn main() {
    let x = (1u8,);
    require_send(move || { drop(x); });
}

This should return a recursive error but it now returns a cyclic one, maybe tyctx or something else would be overwritten somewhere.

View changes since the review

[Dnreikronos]

Yep, makes sense, I missed this, ty.

What happens is that fallback calls tcx.closure_captures, which goes through closure_typeinfo and asks for typeck again. Overflow gets reported from inside trait selection with a plain infcx.err_ctxt(), so there are no typeck results around, and it takes the fallback while typeck of the same body is still on the stack. That's your cycle. I ran your snippet with -Znext-solver=no and got E0391: cycle detected when type-checking main before the fix, E0275 after.

The fix is small and kind of dumb...only look at the typeck results the error context is already carrying, and only if they belong to the closure's own root. If they aren't there, we print the old note like before.

Two tests go back to the old note because of that, auto-trait-leak2 and issue-70935-complex-spans. Those errors come after typeck, from the opaque type side, so nothing is carrying results by then. I spent a while trying to keep the query for cases like those, but from error reporting I can't really tell whether typeck for that body already finished or is still running, and guessing wrong is what got us here in the first place. It bugs me a bit, the async one is exactly where naming the capture pays off, but I'd rather print a vague note than eat the real error.

Also stole your snippet for a test. It needs -Znext-solver=no because on the default solver the recursion limit is the recursion_depth_exceeding_limit lint now, and that path doesn't walk the obligation chain, so it never reaches this note at all.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[JohnTitor]

Thanks! @bors r+

View changes since this review

[rust-bors]

📌 Commit 5332fa8 has been approved by JohnTitor

It is now in the queue for this repository.