debuginfo: identify awaitee (via special name or other solution)

[pnkfelix]

Spawned off of #73524 (comment)

For debugging async crash dumps (and async stack traces in general, I think), the debugger needs to identify the awaitee field in some manner.

There have been various suggestions here, such as changing the await desugaring to move the awaitee to a temporary with a special name like $awaitee that one cannot write in normal rust code. But there may be "gotchas" here; @tmandry noted that "for combinators and such you'll have to do something special".

[pnkfelix]

another suggestion: "the other thing you can do is put debuginfo metadata on the generator variant associated with that await point"

[eholk]

@michaelwoerister did some work on this with #95011, although it doesn't look like that one covers combinators like select! and join!.

@rustbot label +AsyncAwait-Triaged

[eholk]

We talked about the combinator issue some more in the triage meeting. It seems like we don't have a good sense yet of how well combinators currently work (the answer is probably "not well" although some simpler ones might "just work™"), and we also don't really know what the expectations are. We should clarify these things and then work out a design for handling combinators.

[michaelwoerister]

Here are my thoughts on the topic:

For logical async stack traces (i.e. stack traces of async fns that are currently suspended), we want to be able to identify what a particular fn is awaiting. We do that by looking at the suspended state of the fn. This state is basically an enum with a variant for each state the fn can be in, and each variant has fields for local variables that are kept alive across suspension points. #95011 made sure that the local variable generated for simple .await expressions always gets the name __awaitee. So, in the debugger, if we find a field called __awaitee in the suspended state of an async fn, we know that that is the thing being awaited.

However, one can also awaite (multiple) things via join!() and select!(), and those are unlikely to generate something that can reliably be identified and reconstructed in a debugger. There are even multiple implementations of those macros (e.g. in future-rs and tokio).

So, one possible approach would be to always wrap the state being captured when an fn is suspended during a join!() or select!() inside of a well-known type (possibly defined in the standard library), and maybe also make the macros generate a well-known name for the binding. The goal is, again, that if we look at the suspended async state in the debugger, we want to reliably be able to tell if something was generated by a join!() or select!() and what the arguments of it are.