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

-Z print-type-sizes does not include the size of a generator itself #103887

Closed
pnkfelix opened this issue Nov 2, 2022 · 0 comments · Fixed by #104019
Closed

-Z print-type-sizes does not include the size of a generator itself #103887

pnkfelix opened this issue Nov 2, 2022 · 0 comments · Fixed by #104019
Assignees
Labels
C-bug Category: This is a bug.

Comments

@pnkfelix
Copy link
Member

pnkfelix commented Nov 2, 2022

I tried this code:

async fn wait() {}

async fn test(arg: [u8; 8192]) {
    wait().await;
    drop(arg);
}

fn main() {
    println!("{}", std::mem::size_of_val(&test([0; 8192])));
}

and then I ran rustc +nightly --edition 2021 ex-1.rs -Z print-type-sizes

I expected to see this happen: Somewhere in the output, I expected to see

print-type-size type: `[static generator@ex-1.rs:5:32: 8:2]`: 16386 bytes, alignment 1 bytes

Instead, this happened: I do see info about a bunch of types that use the above type, and it is enough information for me to extract my most immediate question (the size of the type), such as:

print-type-size type: `std::future::from_generator::GenFuture<[static generator@ex-1.rs:7:32: 10:2]>`: 16386 bytes, alignment: 1 bytes
print-type-size     field `.0`: 16386 bytes

But it would provide a more consistent experience overall if we would print out a separate line for the [static generator@ex-1.rs:7:32: 10:2] type itself, especially if it could also provide insight into the pieces of state that have been captured by the generator itself.

Meta

rustc --version --verbose:

<version>
Backtrace

<backtrace>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants