feat: generate function declaration in macro for better type check compile error message

[ik1ne]

Motivation

issue #6306

parse_knobs method creates an async block and then calls it. While doing so, the return type of original function is erased for the async block.
This slightly changes the compiler error message from type mismatch.

Solution

Create a temporary function with original return type preserved instead of creating an async block.

Caveats

1. If users call __tokio_internal_async_body inside their main function it will infinitely recurse.
2. I don't think it will, but this might have some erroneous behavior on successfully compiled binary so I would appreciate if someone can find out if this implementation is sound.
3. This is a breaking change for compile error tests, since compiler error message for typecheck will change.

[taiki-e]

This approach was considered in the past but rejected because it would be a breaking change.
#3766 (comment) #4513 (comment)

While "use this approach if there are no arguments" might be fine, it's not clear that it's worth the complexity.

[ik1ne]

Thanks for the clarification, I understand why this implementation is not valid and going to close this PR.

However, the test cargo test --all-features has been succeeded(including trait_method), since <() as A>::f doesn't access self inside the function. (calling self.f() self.g() inside f() makes the test fail, while master version passes)

So, before I close this PR, would you mind if I change the trait_method and check if this PR's ci fails? (And then create PR for trait_method afterwards)

[taiki-e]

However, the test cargo test --all-features has been succeeded(including trait_method), since <() as A>::f doesn't access self inside the function. (calling self.f() self.g() inside f() makes the test fail, while master version passes)

So, before I close this PR, would you mind if I change the trait_method and check if this PR's ci fails? (And then create PR for trait_method afterwards)

Yeah, it is definitely a problem that the trait_method test did not catch that this is a breaking change.
It would be great if you could fix that test so that it catches the problem.

[ik1ne]

While not every check has been finished, I checked following compiler error locally and for some of the github checks:

error[E0434]: can't capture dynamic environment in a fn item
  --> tokio/tests/macros_test.rs:34:13
   |
34 |             self.g()
   |             ^^^^
   |
   = help: use the `|| { ... }` closure form instead

For more information about this error, try `rustc --explain E0434`.
error: could not compile `tokio` (test "macros_test") due to previous error

So I'm closing this issue and going to create a PR for trait_method.