Repository: rust
Issue: Tracking Issue for `#[track_caller]` on async fn
Labels: T-lang,C-tracking-issue

<!--This is a tracking issue for the RFC "XXX" (rust-lang/rfcs#NNN).-->
This is a tracking issue for `#[track_caller]` on async fn.
The feature gate `#[feature(async_fn_track_caller)]` for the issue is not implemented yet (https://github.com/rust-lang/rust/issues/110009)

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implement https://github.com/rust-lang/rust/issues/110009
<!--- [ ] Implement the RFC (cc @rust-lang/XXX -- can anyone write up mentoring
      instructions?)-->
- [ ] Update tracking behavior (see Unresolved Questions)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

(Copied over from: https://github.com/rust-lang/rust/issues/87417#issuecomment-1496735888)

It's not 100% clear that tracking the poller, rather than the original caller, is the ideal behavior. That said, we may still be able to resolve the question without an RFC.

Arguments in favor of tracking the poller (current behavior):

- The user might expect to see the call that's happening now rather than one that happened in the past.
- Prevents us from having to store the caller in the Future type.
- Usually poller and caller are the same function, anyway, so we should do the simpler and more performant thing.

Arguments in favor of tracking the original caller instead of the poller:

- User might expect to see the actual caller; especially given the name track_caller, showing the poller can confusing.
- A &'static Location is only one pointer; storing it is not so bad.
- Combinators won't need to add #[track_caller] to "thread through" the caller information.
- If we tracked the poller, #[track_caller] on a spawned task would show the executor.
  - There's no way today for the executor to save off caller location information (e.g. in spawn) and re-provide it to the polled function, even if it wanted to. We could fix this with a set_caller API.
  - Tracking won't work for &dyn Future. Executors can easily work around this if they have an API with access to the underlying type before coercing to dyn, as most do ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=815c4e7373f6d21e3f5a1bb5bdfb8872)). But if you happen to already have a dyn Future, you'll be stuck.

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- https://github.com/rust-lang/rust/pull/104219
- https://github.com/rust-lang/rust/pull/104741
- https://github.com/rust-lang/rust/pull/105180