Print nicer async/await trait errors for generators in any place in the error 'stack'

[Aaron1011]

Fixes#67025

Currently, we only print 'nice' async/await trait errors when the 'bad' type inside the generator occurs at the top of the 'stack' of errors (the nested errors in the ObligationCauseCode.

This PR allows these 'nice' error messages to be printed each time we encounter a generator in the error stack. This has the result of showing the user how each async fn contributed to the overall type not implementing some auto trait.

This PR still has a few issues:

• The errors have some unnecessary 'occurs within GenFuture/impl Future/[static generator]. It would be nice to try to completely eliminate these when it doesn't reduce clarity, as they often add no actual information.
• We should be printing an additional 'nice' error in the test issue-64130-non-send-future-diags.rs, for async fn foo. I suspect that some of the involved lifetimes are causing a false negative when we check if a type occurs within the generator.

However, I'd be interested in feedback on the overall idea of displaying multiple spans in the error message.

cc @estebank

[rust-highfive]

r? @cramertj

(rust_highfive has picked a reviewer for you, use r? to override)

[nikomatsakis]

How does this compare against #65345 ?

[Aaron1011]

@nikomatsakis: #65345 doesn't appear to handle multiple generator in the same error stack, but it has more diagnostic improvements for when it does detect a generator.

[nikomatsakis]

@Aaron1011

OK. How would you feel about landing #65345 first, and trying to rebase this atop that?

[Aaron1011]

@nikomatsakis: Sounds good to me

[nikomatsakis]

r? @nikomatsakis

[Mark-Simulacrum]

Hm, maybe we can work around that? (Environment variable or something) It also seems plausibly not bad. Maybe even just giving an issue link without the switching and asking for feedback is good (it's sort of like the survey suggested by Niko, but maybe a bit easier).

[Aaron1011]

Maybe even just giving an issue link without the switching and asking for feedback is good (it's sort of like the survey suggested by Niko, but maybe a bit easier).

Without actually showing the intermediate spans, I'm not sure how useful that would be. If showing that information would end up being distracting and not very useful, this we wouldn't find out by just giving an issue link. Conversely, users might not realize that showing extra spans would be helpful, since they don't know what they would be seeing for their particular error.

[JohnCSimon]

triage: merge conflicts

[Aaron1011]

@JohnCSimon: This PR is currently blocked on reaching some kind of consensus as to what these kinds of errors should look like:

• "Intermediate" frames are always hidden
• "Intermediate" frames are hidden by default, can be displayed via a compiler flag
• Something else

[nikomatsakis]

@Aaron1011 do you think you could prepare a hackmd or gist that summarizes the question at hand? It would be great to give some example programs along with two sample outputs, for example. I would like to focus the discussion on very specific examples and proposals. I'd also like to get this resolved. =)

[nikomatsakis]

OK, I prepared a summary of the question at hand -- does this sound like it captures the question

[nikomatsakis]

I was thinking of starting an internals thread to drive this to a conclusion

[nikomatsakis]

Created internals thread here

[nikomatsakis]

We discussed this in our compiler team triage meeting. The internals thread seems to have died down somewhat but the polling at least suggests a preference for "minimal stack trace" (72%).

There is definitely some interest in a "verbose mode" as well. But we felt that would best be preferred as a separate consideration.

@Aaron1011 do you think you could explore altering the PR to give a more "minimal stack trace"? We'll have to experiment a bit with the best way to format that, I imagine.

[pnkfelix]

Here a link to aforementioned discussion amongst T-compiler.

Based on niko's comment above, I am shifting this to S-waiting-on-author instead of team.

[Dylan-DPC-zz]

@Aaron1011 any updates on this?

[nikomatsakis]

I'm going to close this PR, just to keep my list tidy -- @Aaron1011 please feel free to re-open if it's adjusted. Thanks!