diagnostics: point to coroutine body on higher-ranked auto trait errors

[shivendra02467]

Fixes #155880

When encountering a higher-ranked auto trait bound error involving a coroutine or async function,the trait solver previously used the span of the outermost cause (eg. spawn(...) or is_send(...)).

This PR modifies the TraitPlaceholderMismatch formatting logic to walk down the ObligationCauseCode chain.If the obligation originates from a ty::Coroutine or ty::CoroutineWitness, it extracts that specific span, providing a much more accurate underline for the user.

Before:

error: implementation of `Send` is not general enough
  --> src/main.rs:25:5
   |
25 |     is_send(outer())
   |     ^^^^^^^^^^^^^^^^ implementation of `Send` is not general enough

After:

error: implementation of `Send` is not general enough
  --> src/main.rs:13:74
   |
13 |   async fn inner<'a, T: Trait + 'a>(_: T, x: T::Assoc<'a>) -> T::Assoc<'a> {
   |  __________________________________________________________________________^
14 | |     std::future::ready(x).await
15 | | }
   | |_^ implementation of `Send` is not general enough

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
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
• compiler expanded to 73 candidates
• Random selection from 20 candidates

[nnethercote]

Seems plausible but I don't know enough about the underlying issue to review effectively. Let's try someone else:

r? @lcnr

[shivendra02467]

Hi @lcnr, just a gentle ping on this whenever you have a moment! Since you opened the original issue, I'd love to get your thoughts on this approach.

[lcnr]

it's good to see that this information is already accessible. We should also keep the original span, we want to know "where do we require things to be Send and error" and "why do we error".

So instead of replacing the span, it would be good to add an additional note, so sth like

error: implementation of `Send` is not general enough
  --> src/main.rs:25:5
   |
25 |     is_send(outer())
   |     ^^^^^^^^^^^^^^^^ implementation of `Send` is not general enough
  --> src/main.rs:13:74
   |
13 |   async fn inner<'a, T: Trait + 'a>(_: T, x: T::Assoc<'a>) -> T::Assoc<'a> {
   |  __________________________________________________________________________^
14 | |     std::future::ready(x).await
15 | | }
   | |_^ this async block has a field of type `&'0 u32` which is not known to be `Send` 
   = note: `Send` would have to be implemented for the type `&'0 u32`, for any lifetime `'0`...
   = note: ...but `Send` is actually implemented for the type `&'1 u32`, for some specific lifetime `'1`

View changes since the review

[shivendra02467]

Makes total sense, I'll get that updated. also
In your example, you mention extracting the specific interior field type (&'0 u32). Dynamically extracting the exact interior type that caused the failure from the placeholder error seems like a much larger/more complex change.
Would a generic note like "this coroutine or async block is not general enough" be acceptable for the scope of this PR, or were you hoping to get the specific interior type extraction implemented here as well?

[lcnr]

"this async block captures a value whose type is not Send" or sth?

an async block being not general enough doesn't really make sense to me. But ye, having some more general "this async block needs to impl Send seems fine. I think you can get the type of the affected field by looking at the self type of its child obligation.

[lcnr]

I don't know how we talk about the fields of coroutine witnesses in diagnostics, cc @rust-lang/wg-diagnostics or maybe @rust-lang/lang-docs

[shivendra02467]

updated

[lcnr]

you can compute this def_id at the end of the error here? No longer have to do it at the start of the function

[shivendra02467]

that makes total sense, i've updated the PR, thanks!

[traviscross]

"this async block captures a value whose type is not Send" or sth?

Sounds right to me.

[lcnr]

gj finding the relevant information here and sorry for not getting to this earlier, I've been quite busy due to RustWeek

View changes since this review

[shivendra02467]

gj finding the relevant information here and sorry for not getting to this earlier, I've been quite busy due to RustWeek

Thanks! and no problem.

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

[lcnr]

cc @rust-lang/types I don't know how to best word this annotation. Thoughts?

I feel like "captures a value" is not completely ideal

View changes since the review

[shivendra02467]

I'll hold off on changing the "captures a value..." text until the types team weighs in on what terminology they prefer here!

[shivendra02467]

Awesome, thanks for confirming that phrasing, @traviscross!

@lcnr I've pushed an update that makes the label dynamically match the phrasing traviscross approved. It now grabs the specific trait name, so it will output "this async fn captures a value whose type is not Send" (or whichever trait is failing).