Tracking Issue for #[track_caller] on closures

View all comments

This is a tracking issue for the RFC "XXX" (rust-lang/rfcs#NNN).
The feature gate for the issue is #![feature(closure_track_caller)].

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 the RFC
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

XXX --- list all the "unresolved questions" found in the RFC to ensure they are
not forgotten

Should async {}, etc support track caller on their lowered closures?

Implementation history

Initial implementation in Support #[track_caller] on closures and generators #87064

What's the status of this issue? I'd be happy to try and pursue stabilization if it's ready.

Even if this is stabilized, you'll still need the unstable stmt_expr_attributes to actually write it on a closure expression: #15701

Even if this is stabilized, you'll still need the unstable stmt_expr_attributes to actually write it on a closure expression: #15701

That seems to be the case only if the closure is not passed immediately as a function argument:

// This works
let x = std::convert::identity(#[track_caller] || {});
// But this does not
let x = #[track_caller] || {};

Maybe I'm misunderstanding the terminology, but in the case that does work, the closure is still an expression, no?

You're right - this seems like a bug in the stmt_expr_attributes feature gate (or maybe an intentional partial stabilization).

persist-client: ignore warning about `#[track_caller]`

track_caller on async is a no-op see issue #87417 <rust-lang/rust#87417…

Set log level via RUST_LOG (#44)

@rustbot

Nominating for lang team discussion. We may not be ready to approve attributes on closures generally. However, this being unstable led to the backing out of#[track_caller] support on async fn in #104741 (originally implemented in #104219) unless the closure_track_caller feature gate is enabled, because it uses that feature under the hood.

@rustbot label I-lang-nominated I-async-nominated

@rust-lang/lang, can we get consensus on stabilizing support for #[track_caller] on async fn only, and does that need an FCP?

The only possible question I see is whether caller tracking should occur during initial call or subsequent polling; this follows the approach adopted and FCP'd in #87064 and adds it to poll. One implication of this is that combinators would need to add #[track_caller] to their poll implementations to be able to "see through" them to user code. @rust-lang/wg-async in case there are any concerns about this.

Additionally, how close are we to consensus on stabilizing closure_track_caller if a stabilization PR were to come up?

Rollup merge of rust-lang#161972 - theemathas:async-track_caller-test…

Unrolled build for #161972 in rollup 162229

Rollup merge of #161972 - theemathas:async-track_caller-tests, r=Shoy…

Note: After my work at #163396 is done and then merged, #[track_caller] async fn will track the caller, but #[track_caller] async closures will track the poller/awaiter. This is due to implementation difficulties with the latter.

This means that async_fn_track_caller and closure_track_caller together won't be able to be simultaneously stabilized as-is after my PR, as doing so would stabilize #[track_caller] async closures, which currently don't work properly. (Such closures are currently gated behind both features, requiring both features to be enabled.)

Maybe #[track_caller] async closures should be moved to a new feature gate?

Navigation Menu

Repository navigation

Tracking Issue for `#[track_caller]` on closures #87417

About tracking issues

Steps

Unresolved Questions

Implementation history

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for #[track_caller] on closures #87417

Description

About tracking issues

Steps

Unresolved Questions

Implementation history

Activity

kartva commented on Oct 5, 2022

Aaron1011 commented on Oct 22, 2022

mpfaff commented on Jan 22, 2023

Aaron1011 commented on Jan 22, 2023

tmandry commented on Mar 28, 2023

22 remaining items

theemathas commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for `#[track_caller]` on closures #87417