You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yeah, I feel like this is obviously something we should have. More deneraly, we should have an intention to see the whole layout. But it's also true that even MVP version of this would required a lot of progress on modularisation front
I do miss this a lot. Especially since clangd can show you the size of a struct and the size and offset of its fields.
Also cargo +nightly rustc -- -Zprint-type-sizes or const asserts with size_of are somewhat tedious...
This is going to be very hard to implement, as this basically requires a reimplementation of the layout code in rustc: [...] is 2776 lines long
If we only need the size, maintaining (align, size, niche) for each type should be enough. No need for the exact layout and arrangement. It would be much easier.
If we only need the size, maintaining (align, size, niche) for each type should be enough. No need for the exact layout and arrangement. It would be much easier.
I don't think it would be much easier. Maybe a bit.
For example, cargo_toml::Manifest on x86_64 is > 4000B and it's really hard to find this out just by reading the docs (because they don't document this).
For example, cargo_toml::Manifest on x86_64 is > 4000B and it's really hard to find this out just by reading the docs (because they don't document this).
Thanks, that will very helpful and I hope it gets turned on by default so that the size info will be accessible on docs.rs instead of requiring building doc on local.
Though I guess it won't show Future generated by async fn/async {}.
Someone messing with a sockaddr_in is not going to wait for the IDE to tell them how to do it.
Maybe. I'm not convinced someone throwing themselves in from a C background would say it's obvious non-repr structs don't have a defined memory layout. Missized allocations and naive assumptions about layout aren't exactly uncommon in the C (or cpp) world.
Missized allocations and naive assumptions about layout aren't exactly uncommon in the C (or cpp) world.
Exactly. And that's without the IDE showing them the type layout, so having this information available won't matter if you really insist on doing it.
But Rust developers need to use unsafe and generally know they'd need #[repr(C)] in this case. At least some of the cases you've pointed to were prompted by standard library API limitations.
Exactly. And that's without the IDE showing them the type layout, so having this information available won't matter if you really insist on doing it.
Rust is a language that tends to push you in safe directions, and the point that I had originally made was that very smart people made a very poor choice to rely on UB in memory layouts without anything suggesting that it was ok to do. Api limitations or not adding alignment and size information to something which is undefined makes things like my original post was referencing easier to stumble through or think is ok. Not every person using rust, even unsafe rust, knows or understands everything. Tools should point you in the right direction. Not just provide foot guns for people who don't know better.
Adding some annotation to indicate that the layout is unstable is a good suggestion, and would resolve my objections to putting it on non-repr structs.
Cargo has a lint that triggers when the biggest variant is a lot bigger than the second biggest. So the request there is really (I think), what is the variant's size disregarding it being an enum (so no tag, no padding from other variants, effectively handling it as a struct).
Activity
bjorn3 commentedon Apr 22, 2020
This is going to be very hard to implement, as this basically requires a reimplementation of the layout code in rustc: https://github.com/rust-lang/rust/blob/8ce3f840ae9b735a66531996c32330f24b877cb0/src/librustc_middle/ty/layout.rs is 2776 lines long. It also depends on the exact version of rustc you are using, so it would have to be changed constantly.
Diggsey commentedon Apr 22, 2020
It also depends on the compilation target...
TimoFreiberg commentedon Apr 22, 2020
Maybe when the librarification progresses, rust-analyzer and rustc could use the same code?
matklad commentedon Apr 23, 2020
Yeah, I feel like this is obviously something we should have. More deneraly, we should have an intention to see the whole layout. But it's also true that even MVP version of this would required a lot of progress on modularisation front
wrenger commentedon Jul 27, 2022
I do miss this a lot. Especially since clangd can show you the size of a struct and the size and offset of its fields.
Also
cargo +nightly rustc -- -Zprint-type-sizesor const asserts with size_of are somewhat tedious...lnicola commentedon Aug 8, 2022
#12972 is an interesting feature request: it asks for the type of each variant in an enum.
oxalica commentedon Aug 8, 2022
@bjorn3
If we only need the size, maintaining
(align, size, niche)for each type should be enough. No need for the exact layout and arrangement. It would be much easier.bjorn3 commentedon Aug 8, 2022
I don't think it would be much easier. Maybe a bit.
kyrias commentedon Oct 13, 2022
This would be particularly useful for the implicit futures created by async functions, as per rust-lang/rust-clippy#5263.
Auto merge of #13490 - HKalbasi:layout, r=jonas-schievink
lnicola commentedon Dec 12, 2022
Initial support added in #13490.
jplatte commentedon Dec 12, 2022
I find the comments inside the hovers a bit distracting, maybe they should be opt-in? It's information I need very rarely.
flodiebold commentedon Dec 12, 2022
We should make it configurable, but opt-out as usual.
6 remaining items
NobodyXu commentedon Dec 13, 2022
I would really love to see that.
bjorn3 commentedon Dec 13, 2022
Nightly rustdoc has
--show-type-layout. For an example of how this looks see https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html#layoutNobodyXu commentedon Dec 13, 2022
Thanks, that will very helpful and I hope it gets turned on by default so that the size info will be accessible on docs.rs instead of requiring building doc on local.
Though I guess it won't show
Futuregenerated byasync fn/async {}.StripedMonkey commentedon Dec 13, 2022
Maybe. I'm not convinced someone throwing themselves in from a C background would say it's obvious non-repr structs don't have a defined memory layout. Missized allocations and naive assumptions about layout aren't exactly uncommon in the C (or cpp) world.
lnicola commentedon Dec 13, 2022
Exactly. And that's without the IDE showing them the type layout, so having this information available won't matter if you really insist on doing it.
But Rust developers need to use
unsafeand generally know they'd need#[repr(C)]in this case. At least some of the cases you've pointed to were prompted by standard library API limitations.hkalbasi commentedon Dec 13, 2022
Maybe we can add a
(unstable)to message if the type is not recursively#[repr(C)]StripedMonkey commentedon Dec 13, 2022
Rust is a language that tends to push you in safe directions, and the point that I had originally made was that very smart people made a very poor choice to rely on UB in memory layouts without anything suggesting that it was ok to do. Api limitations or not adding alignment and size information to something which is undefined makes things like my original post was referencing easier to stumble through or think is ok. Not every person using rust, even unsafe rust, knows or understands everything. Tools should point you in the right direction. Not just provide foot guns for people who don't know better.
Adding some annotation to indicate that the layout is unstable is a good suggestion, and would resolve my objections to putting it on non-repr structs.
hkalbasi commentedon May 17, 2023
Is this a well defined concept? In my understanding, layout of a variant has the same size as the layout of its enum, it just has more paddings.
Veykril commentedon May 18, 2023
Cargo has a lint that triggers when the biggest variant is a lot bigger than the second biggest. So the request there is really (I think), what is the variant's size disregarding it being an enum (so no tag, no padding from other variants, effectively handling it as a struct).
hkalbasi commentedon May 18, 2023
Layout of enum variant is implemented in #14845. I'm going to close this issue, feel free to open more specific ones if needed.