Tracking Issue for #[track_caller] on async fn

[bryangarza]

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 (#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

• Implement Create separate feature gate for #[track_caller] on async fn #110009

• Update tracking behavior (see Unresolved Questions)
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

(Copied over from: #87417 (comment))

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). But if you happen to already have a dyn Future, you'll be stuck.

Implementation history

• Support #[track_caller] on async fns #104219
• Switch #[track_caller] back to a no-op unless feature gate is enabled #104741
• Use proper HirId for async track_caller attribute check #105180

[bryangarza]

FYI @tmandry

[bryangarza]

@rustbot label +T-lang

[tmandry]

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.

@rust-lang/wg-async discussed in this zulip thread. We were leaning toward tracking the original caller rather than the poller, based on the use case we knew about (assertion helpers). If there are other use cases or points of agreement/disagreement with this, please leave them in the linked zulip thread.

[Swatinem]

Another idea worth revisiting here may be:
In #104833, I also added #[track_caller] support for async blocks. Pretty much because it was trivial to do so, and actually supporting it separately would have been more work.

It might still be worth doing that, specifically to split that into its own track_async_block_caller or similar feature.