`#[track_caller]` on async fn's was previously a no-op but now produces a compiler error

[anp]

Code

I tried this code:

#[track_caller]
async fn foo() {
    println!("{}", std::panic::Location::caller());
}


#[tokio::main]
async fn main() {
    foo().await;
}

I expected to see this happen: a successful build that prints src/main.rs:3:20 (i.e. the attribute is a no-op)

Instead, this happened:

Compiling playground v0.0.1 (/playground)
error[[E0658]](https://doc.rust-lang.org/nightly/error-index.html#E0658): `#[track_caller]` on closures is currently unstable
 --> src/main.rs:2:16
  |
2 | async fn foo() {}
  |                ^^
  |
  = note: [see issue #87417 <https://github.com/rust-lang/rust/issues/87417>](https://github.com/rust-lang/rust/issues/87417) for more information
  = help: [add `#![feature(closure_track_caller)]`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#) to the crate attributes to enable

Version it worked on

It most recently worked on: 1.65.0 stable

Version with regression

playground's current nightly: 1.67.0-nightly (2022-11-17 83356b78c4ff3e7d84e9)

I think this compilation failure was introduced by #104219 which adds actual support for track_caller on async fn's, since it was previously a no-op.

TBH, in hindsight I think we probably should have disallowed track_caller on async fn's in the initial implementation so that we could leave room for unstable support in the future. However given that this wasn't considered, it seems like this may now be a stability regression.

[compiler-errors]

cc: @bryangarza

TBH, in hindsight I think we probably should have disallowed track_caller on async fn's in the initial implementation so that we could leave room for unstable support in the future.

@anp, that's a good point. it's probably possible to make #[track_caller] a no-op + lint against the ungated usage as a warning, and gate this behavior behind something else (either closure_track_caller, or a new feature such as async_track_caller).

[anp]

That makes a lot of sense as a way to resolve this. Having the ungated usage produce a warning seems like a great way to avoid confusion about a feature flag silently changing compiled behavior.

[bryangarza]

cc: @bryangarza

TBH, in hindsight I think we probably should have disallowed track_caller on async fn's in the initial implementation so that we could leave room for unstable support in the future.

@anp, that's a good point. it's probably possible to make #[track_caller] a no-op + lint against the ungated usage as a warning, and gate this behavior behind something else (either closure_track_caller, or a new feature such as async_track_caller).

Sounds good, I can put up a PR that does this. I didn't realize that the annotation was already being used on async fn's in the wild

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium