Support `#[track_caller]` on async fns #104219

bryangarza · 2022-11-09T23:35:29Z

Adds #[track_caller] to the generator that is created when we desugar the async fn.

Open questions:

What is the performance impact of adding #[track_caller] to every GenFuture's poll(...) function, even if it's unused (i.e., the parent span does not set #[track_caller])? We might need to set it only conditionally, if the indirection causes overhead we don't want.

This patch allows the usage of the `track_caller` annotation on generators, as well as sets them conditionally if the parent also has `track_caller` set. Also add this annotation on the `GenFuture`'s `poll()` function.

rustbot · 2022-11-09T23:35:36Z

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2022-11-09T23:35:39Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

bryangarza · 2022-11-09T23:37:28Z

r? @eholk

compiler/rustc_ast_lowering/src/expr.rs

eholk · 2022-11-10T00:03:36Z

compiler/rustc_ast_lowering/src/item.rs

@@ -86,7 +86,7 @@ impl<'a, 'hir> ItemLowerer<'a, 'hir> {
            impl_trait_defs: Vec::new(),
            impl_trait_bounds: Vec::new(),
            allow_try_trait: Some([sym::try_trait_v2, sym::yeet_desugar_details][..].into()),
-            allow_gen_future: Some([sym::gen_future][..].into()),
+            allow_gen_future: Some([sym::gen_future, sym::closure_track_caller][..].into()),


I wonder if it makes sense to split gen_future and closure_track_caller into separate entires?

I think it's fine like this, since allow_gen_future is only used in one place and since we want track caller to work we also need the closure_track_caller feature. Separating them seems like extra work with little benefit.

eholk · 2022-11-10T00:15:09Z

@bors r+

bors · 2022-11-10T00:15:10Z

📌 Commit 509b947 has been approved by eholk

It is now in the queue for this repository.

… r=eholk Support `#[track_caller]` on async fns Adds `#[track_caller]` to the generator that is created when we desugar the async fn. Fixes rust-lang#78840 Open questions: - What is the performance impact of adding `#[track_caller]` to every `GenFuture`'s `poll(...)` function, even if it's unused (i.e., the parent span does not set `#[track_caller]`)? We might need to set it only conditionally, if the indirection causes overhead we don't want.

matthiaskrgr · 2022-11-10T20:17:53Z

@bors r- failed in a rollup
https://github.com/rust-lang-ci/rust/actions/runs/3439952321/jobs/5737838684#step:25:22242
#104256

bryangarza · 2022-11-10T23:24:54Z

The failure

 failures:

---- [ui] src/test/ui/async-await/track-caller/panic-track-caller.rs stdout ----

error: test run failed!
status: exit status: 101
command: "/node-v15.14.0-linux-x64/bin/node" "/checkout/src/etc/wasm32-shim.js" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/async-await/track-caller/panic-track-caller/a.wasm"
stdout: none
--- stderr -------------------------------
RuntimeError: unreachable
    at __rust_start_panic (<anonymous>:wasm-function[94]:0x5a97)
    at rust_panic (<anonymous>:wasm-function[91]:0x5a5d)
    at _ZN3std9panicking20rust_panic_with_hook17h0c233e78e6112adfE (<anonymous>:wasm-function[90]:0x5a2d)
    at _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17hf994fd019a2fd642E (<anonymous>:wasm-function[77]:0x4a54)
    at _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17ha238eeecdfc892b1E (<anonymous>:wasm-function[76]:0x49b9)
    at rust_begin_unwind (<anonymous>:wasm-function[85]:0x5681)
    at _ZN4core9panicking9panic_fmt17ha1487ae10087c69cE (<anonymous>:wasm-function[140]:0x63bf)
    at _ZN4core9panicking5panic17heb919bbe7cf670eaE (<anonymous>:wasm-function[143]:0x680c)
    at _ZN3std5panic12catch_unwind17h79eba0ed8ab51e6aE (<anonymous>:wasm-function[2]:0x230)
    at _ZN18panic_track_caller4main17h0fa14fb0b64e685eE (<anonymous>:wasm-function[14]:0x66a)
    at _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h363919328fe77852E (<anonymous>:wasm-function[0]:0x1cf)
    at _ZN3std2rt10lang_start28_$u7b$$u7b$closure$u7d$$u7d$17h226d7bc4ae73ce06E (<anonymous>:wasm-function[1]:0x1f1)
    at _ZN3std2rt19lang_start_internal17h8bbe173c9dd6e6e6E (<anonymous>:wasm-function[64]:0x3f60)
    at main (<anonymous>:wasm-function[15]:0x6b2)
    at Object.<anonymous> (/checkout/src/etc/wasm32-shim.js:20:20)
    at Module._compile (node:internal/modules/cjs/loader:1092:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1121:10)
    at Module.load (node:internal/modules/cjs/loader:972:32)
    at Function.Module._load (node:internal/modules/cjs/loader:813:14)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:76:12)
------------------------------------------



failures:
    [ui] src/test/ui/async-await/track-caller/panic-track-caller.rs

test result: FAILED. 13105 passed; 1 failed; 704 ignored; 0 measured; 0 filtered out; finished in 92.50s

Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=wasm32-unknown-unknown

bryangarza · 2022-11-10T23:30:36Z

@matthiaskrgr @eholk do we need to ignore the wasm target? I just noticed this on a few other UI tests

// ignore-wasm no panic or subprocess support
// ignore-emscripten no panic or subprocess support

tmandry · 2022-11-12T20:42:20Z

@bryangarza Please use // needs-unwind instead of ignoring individual targets. That way if std is built with panic=abort the test will still be ignored.

(Alternatively you might be able to let the process abort instead of catching the panic, and assert that the panic output itself contains the desired file/line; not sure how well it will work though.)

bryangarza · 2022-11-14T05:43:30Z

@bryangarza Please use // needs-unwind instead of ignoring individual targets. That way if std is built with panic=abort the test will still be ignored.

(Alternatively you might be able to let the process abort instead of catching the panic, and assert that the panic output itself contains the desired file/line; not sure how well it will work though.)

oh okay thanks, I’ll update it to // needs-unwind tomorrow

bryangarza · 2022-11-15T18:47:20Z

@eholk - I think we can try adding it to the rollup again

eholk · 2022-11-15T21:57:37Z

@bors r+ rollup=never

bors · 2022-11-15T21:57:39Z

📌 Commit 79c06fc has been approved by eholk

It is now in the queue for this repository.

Manishearth · 2022-11-16T17:45:30Z

@bors p=1

going to close the tree for non-nevers for a while so they can drain out

bors · 2022-11-17T13:47:07Z

⌛ Testing commit 79c06fc with merge b6097f2...

bors · 2022-11-17T16:47:41Z

☀️ Test successful - checks-actions
Approved by: eholk
Pushing b6097f2 to master...

rust-timer · 2022-11-17T18:07:42Z

Finished benchmarking commit (b6097f2): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.2%	[-3.2%, -3.2%]	1
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

WaffleLapkin · 2022-12-01T15:15:22Z

compiler/rustc_ast_lowering/src/expr.rs

+        let parent_has_track_caller = self
+            .attrs
+            .values()
+            .find(|attrs| attrs.into_iter().find(|attr| attr.has_name(sym::track_caller)).is_some())
+            .is_some();


I feel like this is very broken, the parent here might be just a normal function, not necessarily the desugaring of an async fn, see #105134

…=eholk Support `#[track_caller]` on async fns Adds `#[track_caller]` to the generator that is created when we desugar the async fn. Fixes rust-lang#78840 Open questions: - What is the performance impact of adding `#[track_caller]` to every `GenFuture`'s `poll(...)` function, even if it's unused (i.e., the parent span does not set `#[track_caller]`)? We might need to set it only conditionally, if the indirection causes overhead we don't want.

eholk and others added 3 commits October 10, 2022 16:00

Add a test case for #[track_caller] on async fn

0c158f0

wip: trying to enable #[track_caller] on async fn

3db41d1

Allow and add track_caller to generators

fa99cb8

This patch allows the usage of the `track_caller` annotation on generators, as well as sets them conditionally if the parent also has `track_caller` set. Also add this annotation on the `GenFuture`'s `poll()` function.

rustbot assigned jackh726 Nov 9, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 9, 2022

rustbot assigned eholk and unassigned jackh726 Nov 9, 2022

eholk approved these changes Nov 10, 2022

View reviewed changes

Refactor nested for-loops into find() calls

509b947

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 10, 2022

Manishearth mentioned this pull request Nov 10, 2022

Rollup of 9 pull requests #104256

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 10, 2022

Ignore wasm and emscripten targets for test

b678e92

Use needs-unwind instead of ignoring WASM/emscripten

79c06fc

bryangarza force-pushed the async-track-caller-dup branch from 715fb31 to 79c06fc Compare November 15, 2022 01:09

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 15, 2022

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 17, 2022

bors merged commit b6097f2 into rust-lang:master Nov 17, 2022

rustbot added this to the 1.67.0 milestone Nov 17, 2022

bors mentioned this pull request Nov 17, 2022

Avoid GenFuture shim when compiling async constructs #104321

Merged

bryangarza deleted the async-track-caller-dup branch November 17, 2022 20:56

anp mentioned this pull request Nov 18, 2022

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

Closed

WaffleLapkin mentioned this pull request Dec 1, 2022

async{} blocks can no longer be used in functions marked as #[track_caller] #105134

Closed

WaffleLapkin reviewed Dec 1, 2022

View reviewed changes

compiler-errors mentioned this pull request Dec 22, 2022

Switch #[track_caller] back to a no-op unless feature gate is enabled #104741

Merged

tmandry mentioned this pull request Mar 28, 2023

Tracking Issue for #[track_caller] on closures #87417

Open

3 tasks

bryangarza mentioned this pull request Apr 6, 2023

Tracking Issue for #[track_caller] on async fn #110011

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support `#[track_caller]` on async fns #104219

Support `#[track_caller]` on async fns #104219

bryangarza commented Nov 9, 2022 •

edited

Loading

rustbot commented Nov 9, 2022

rustbot commented Nov 9, 2022

bryangarza commented Nov 9, 2022

eholk Nov 10, 2022

eholk commented Nov 10, 2022

bors commented Nov 10, 2022

matthiaskrgr commented Nov 10, 2022

bryangarza commented Nov 10, 2022

bryangarza commented Nov 10, 2022 •

edited

Loading

tmandry commented Nov 12, 2022

bryangarza commented Nov 14, 2022

bryangarza commented Nov 15, 2022

eholk commented Nov 15, 2022

bors commented Nov 15, 2022

Manishearth commented Nov 16, 2022

bors commented Nov 17, 2022

bors commented Nov 17, 2022

rust-timer commented Nov 17, 2022

WaffleLapkin Dec 1, 2022

Support #[track_caller] on async fns #104219

Support #[track_caller] on async fns #104219

Conversation

bryangarza commented Nov 9, 2022 • edited Loading

rustbot commented Nov 9, 2022

rustbot commented Nov 9, 2022

bryangarza commented Nov 9, 2022

eholk Nov 10, 2022

Choose a reason for hiding this comment

eholk commented Nov 10, 2022

bors commented Nov 10, 2022

matthiaskrgr commented Nov 10, 2022

bryangarza commented Nov 10, 2022

bryangarza commented Nov 10, 2022 • edited Loading

tmandry commented Nov 12, 2022

bryangarza commented Nov 14, 2022

bryangarza commented Nov 15, 2022

eholk commented Nov 15, 2022

bors commented Nov 15, 2022

Manishearth commented Nov 16, 2022

bors commented Nov 17, 2022

bors commented Nov 17, 2022

rust-timer commented Nov 17, 2022

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

WaffleLapkin Dec 1, 2022

Choose a reason for hiding this comment

Support `#[track_caller]` on async fns #104219

Support `#[track_caller]` on async fns #104219

bryangarza commented Nov 9, 2022 •

edited

Loading

bryangarza commented Nov 10, 2022 •

edited

Loading