-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Compute data layout of types #13490
Compute data layout of types #13490
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm somewhat worried about maintainability here. This copies 2000 lines from rustc instead of factoring the functionality out into a reusable crate, which is going to be hard to keep in sync.
crates/hir-ty/src/layout/target.rs
Outdated
f32_align: AbiAndPrefAlign::new(Align::from_bytes(4).unwrap()), | ||
f64_align: AbiAndPrefAlign::new(Align::from_bytes(8).unwrap()), | ||
pointer_size, | ||
pointer_align: AbiAndPrefAlign::new(Align::from_bytes(8).unwrap()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This value is not correct on all targets (and others potentially too)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now fixed. About others, instruction_address_space
is wrong for Harvard architectures but it doesn't affect layout computation, and vector_align
is wrong but is for SIMD types which are not supported. I believe the rest is correct for at least x86
, arm
, riscv
and powerpc
.
rust-lang/rust#103693 can reduce ~800 lines of copied codes. But since |
8041c03
to
f47fb10
Compare
I'm not familiar with the process of publishing those, but what do you mean? I remember |
The last published version is a year or so old: https://crates.io/crates/rustc-ap-rustc_lexer/versions. Before that it was published every week. |
ae65739
to
6601b73
Compare
I updated the PR to use the new It can even be merged before the rustc PR, since I published my fork to the crates.io and it works at the current state. I will come with a follow up PR when my changes in rustc merged and rustc auto publish story becomes clear. @rustbot review |
Make rustc_target usable outside of rustc I'm working on showing type size in rust-analyzer (rust-lang/rust-analyzer#13490) and I currently copied rustc code inside rust-analyzer, which works, but is bad. With this change, I would become able to use `rustc_target` and `rustc_index` directly in r-a, reducing the amount of copy needed. This PR contains some feature flag to put nightly features behind them to make crates buildable on the stable compiler + makes layout related types generic over index type + removes interning of nested layouts.
rust-lang/rust#103693 just merged, and I updated my auto published crates to use upstream rustc. |
☔ The latest upstream changes (presumably #13686) made this pull request unmergeable. Please resolve the merge conflicts. |
0bc0aed
to
c627fc4
Compare
Make rustc_target usable outside of rustc I'm working on showing type size in rust-analyzer (rust-lang/rust-analyzer#13490) and I currently copied rustc code inside rust-analyzer, which works, but is bad. With this change, I would become able to use `rustc_target` and `rustc_index` directly in r-a, reducing the amount of copy needed. This PR contains some feature flag to put nightly features behind them to make crates buildable on the stable compiler + makes layout related types generic over index type + removes interning of nested layouts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good!
check_size_and_align( | ||
stringify!($($t)*), | ||
::std::mem::size_of::<Goal>() as u64, | ||
::std::mem::align_of::<Goal>() as u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat trick! This should even work when cross-compiling r-a.
i16_align: AbiAndPrefAlign::new(Align::from_bytes(2).unwrap()), | ||
i32_align: AbiAndPrefAlign::new(Align::from_bytes(4).unwrap()), | ||
i64_align: AbiAndPrefAlign::new(Align::from_bytes(8).unwrap()), | ||
i128_align: AbiAndPrefAlign::new(Align::from_bytes(8).unwrap()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the alignment of i64 and i128 are always 8 Bytes on all platforms. If there's no way to query the correct alignment from the cfg_options, can you add a FIXME comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a way: rustc +nightly -Z unstable-options --print target-spec-json
. But it needs nightly. Is it possible to use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rustc_cfg
code already tries to use nightly-only features, and falls back to stable-compatible behavior if those are unavailable or don't work, so this should be doable. However, I think just setting the align to 8 should be fine for now, we can follow up with a fix that asks rustc later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least aarch64 and riscv64 use a 16 byte alignment for u/i128.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a fixme comment
@bors r+ |
1 similar comment
@bors r+ |
☀️ Test successful - checks-actions |
Show type info on hover of enum variant fields Small addition to #13490
Show type alias layout This PR expands on #13490 to allow displaying layout data on hover for type aliases.
cc #4091
Things that aren't working:
Future
I think)Things that show wrong result:
Enums with explicit discriminantNonZero*
and similar standard library items which control layout with special attributesAt the user level, I didn't put much work, since I wasn't confident about what is the best way to present this information. Currently it shows size and align for ADTs, and size, align, offset for struct fields, in the hover, similar to clangd. I used it some days and I feel I liked it, but we may consider it too noisy and move it to an assist or command.