You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
#[track_caller] on async fn's was previously a no-op but now produces a compiler error #104588
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.
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).
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.
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
Activity
compiler-errors commentedon Nov 18, 2022
cc: @bryangarza
@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 (eitherclosure_track_caller, or a new feature such asasync_track_caller).anp commentedon Nov 18, 2022
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 commentedon Nov 19, 2022
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 commentedon Nov 23, 2022
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-medium
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
Remove `#[track_caller]` from `render_comparison_test_with_renderer()`
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
Rollup merge of rust-lang#104741 - bryangarza:bug-104588-async-track-…
Rollup merge of rust-lang#104741 - bryangarza:bug-104588-async-track-…
Switch `#[track_caller]` back to a no-op unless feature gate is enabled
Switch `#[track_caller]` back to a no-op unless feature gate is enabled