Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate more precise generator names #92873

Merged
merged 2 commits into from
Jan 15, 2022
Merged

Conversation

eholk
Copy link
Contributor

@eholk eholk commented Jan 13, 2022

Currently all generators are named with a generator$N suffix, regardless of where they come from. This means an async fn shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators.

This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator.

r? @tmandry
cc @michaelwoerister @wesleywiser @dpaoliello

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 13, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 13, 2022
Currently all generators are named with a `generator$N` suffix,
regardless of where they come from. This means an `async fn` shows up as
a generator in stack traces, which can be surprising to async
programmers since they should not need to know that async functions are
implementated using generators.

This change generators a different name depending on the generator kind,
allowing us to tell whether the generator is the result of an async
block, an async closure, an async fn, or a plain generator.
@rust-log-analyzer

This comment has been minimized.

@tmandry
Copy link
Member

tmandry commented Jan 14, 2022

Much better, thank you!

@bors r+

@bors
Copy link
Contributor

bors commented Jan 14, 2022

📌 Commit a1173cf has been approved by tmandry

@bors 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 Jan 14, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 15, 2022
…askrgr

Rollup of 8 pull requests

Successful merges:

 - rust-lang#92747 (Simplification of BigNum::bit_length)
 - rust-lang#92767 (Use the new language identifier for Rust in the PDB debug format)
 - rust-lang#92775 (Inline std::os::unix::ffi::OsStringExt methods)
 - rust-lang#92863 (Remove `&mut` from `io::read_to_string` signature)
 - rust-lang#92865 (Ignore static lifetimes for GATs outlives lint)
 - rust-lang#92873 (Generate more precise generator names)
 - rust-lang#92879 (Add Sync bound to allocator parameter in vec::IntoIter)
 - rust-lang#92892 (Do not fail evaluation in const blocks)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 85c119c into rust-lang:master Jan 15, 2022
@rustbot rustbot added this to the 1.60.0 milestone Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants