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

Feature request: expose type sizes #14199

Closed
mqudsi opened this issue Feb 23, 2023 · 5 comments
Closed

Feature request: expose type sizes #14199

mqudsi opened this issue Feb 23, 2023 · 5 comments
Labels
C-feature Category: feature request

Comments

@mqudsi
Copy link

mqudsi commented Feb 23, 2023

When working on trying to improve the performance of a rust codebase, it's important to be able to introspect the nature of types. While there are a number of aspects that one might want to explore (alignment, size, etc.) I think the most important of these is probably the size of a type to help decide between Option<T> and Box<T> or to figure out if pigeonholing is being used to make Option<T> the same size as T, etc.

Since these are all awesomely available as const functions that take a type but no value, it would be wonderful if the size of types could be visible (preferably directly in the hover info, or alternatively via a code action).

Since #10933 was merged I think it should be possible although it might also depend on #10825 (going by the title but not by the description) in order to evaluate constant expressions.

e.g. a step in the right direction would be to make it possible to do this myself in the IDE, by typing out the following:

const X: usize = core::mem::size_of::<i32>();

then hovering over X and seeing the result of the constant evaluation. Currently hovering over X just shows const X: usize = core::mem::size_of::<CxxWString>, but it would be beyond amazing if it could show (instead or in addition) the result of the evaluation (e.g. const X: usize = core::mem::size_of::<i32>(); // 4).

Once that works, rust-analyzer could basically "write and evaluate" in the background an expression to get the size of any type T when T is hovered over to retrieve the size (either in advance or on-the-fly).

Taking a step back and looking at what I'm asking: would you like me to open a second PR to formally request "evaluate and display the result of compile-time constant expressions evaluating to primitive types" or is this PR sufficient?

@mqudsi mqudsi added the C-feature Category: feature request label Feb 23, 2023
@HKalbasi
Copy link
Member

Currently it shows size of structs and enums in hover, so if you want to see the type of i32, you can hover on struct Foo(i32). About const evaluation, your example will work after #14040

@mqudsi
Copy link
Author

mqudsi commented Feb 23, 2023

Hmm I see it now but only for some types. Is it only for types native to the crate being developed? Actually no because I see it with some of my dependencies...

Any reason why it wouldn't show the size of some types, for example libc::termios with the following definition?

    pub struct termios {
        pub c_iflag: ::tcflag_t,
        pub c_oflag: ::tcflag_t,
        pub c_cflag: ::tcflag_t,
        pub c_lflag: ::tcflag_t,
        pub c_line: ::cc_t,
        pub c_cc: [::cc_t; ::NCCS],
        #[cfg(not(any(
            target_arch = "sparc",
            target_arch = "sparc64",
            target_arch = "mips",
            target_arch = "mips64")))]
        pub c_ispeed: ::speed_t,
        #[cfg(not(any(
            target_arch = "sparc",
            target_arch = "sparc64",
            target_arch = "mips",
            target_arch = "mips64")))]
        pub c_ospeed: ::speed_t,
    }

I just get

libc::unix::linux_like::linux::gnu
──────────────────────────────────
pub struct termios

@HKalbasi
Copy link
Member

If it fails to find the correct data layout, it will show nothing. In your example, my guess is that it can't evaluate the NCCS constant.

@mqudsi
Copy link
Author

mqudsi commented Feb 23, 2023

Ok, thanks.

Is there anything new in this request or should I close it out?

@HKalbasi
Copy link
Member

I think we can close it in favor of #4091

@HKalbasi HKalbasi closed this as not planned Won't fix, can't repro, duplicate, stale Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature Category: feature request
Projects
None yet
Development

No branches or pull requests

2 participants