Improve diagnostics for tokio::main and tokio::test attributes

[Veykril]

Motivation

Motivation is to fix #5518, by no longer attaching questionable spans to tokens for improved diagnostics.

Solution

Turns out we can further improve diagnostics while not having to attach tail expression spans to tokens, bringing the diagnostics closer to what rustc reports for non tokio attributed async functions by just re-emitting a local version of the annotated function instead of using an async block. Compare the test output with the output of the non attributed versions (playground link for those)

They are now equal.

Closes #5518

[Veykril]

Ah I wasn't aware this worked on associated functions

[Veykril]

I also now see this was tried before in #3039 (review) reading up on that now

Edit: I see, this runs risk of changing drop order in theory. An async blocks drop order is dependent on the order it references its captures by, where as for async function it is the parameter order. So for parameterless (and unary) functions this change is fine, but for more parameters it can potentially change the drop order, ... how annoying. Interestingly enough that also means that #[tokio::main] functions have a differing drop order from vanilla async functions.

[Veykril]

I'll close this PR then, unfortunate but I don't think there is a way to get around that. Might be good to note this as a potential change for a future 2.0 release if that ever is going to happen though, as the difference in drop order can be surprising I reckon.

[taiki-e]

As for drop order, doing the similar thing as async-trait did (dtolnay/async-trait#143) should fix it without reducing the number of use cases supported as this PR does.

[Veykril]

But that is going from an async fn in the expansion to an async block, fixing drop order there is simple as you can just emit usages in order at the start of the block. Going from a block to an async fn as is done here doesn't have such a solution (as you can't tell the order of captures of an async block syntactically).

Unless I am misunderstanding that PR (its quite a massive diff)

[joshka]

Assuming that this change is good aside from the drop order change, would it be possible to capture the drop order problem in a test somehow?

[Darksonn]

That's a good idea. I imagine that we could use a global counter that is incremented in each destructor to assert that the drop order is correct. Would you like to do that?