rust/compiler/rustc_abi/src/layout.rs, branch cargo_updatehttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=cargo_update2025-08-14T01:26:13+00:00Remove TmpLayout in layout_of_enum2025-08-14T01:26:13+00:00Zachary Szasample18+github@gmail.com2025-08-12T22:42:43+00:00urn:sha1:12b57942d646d27e8d0a615ba4b8a0dea6cf3b9fReuse `sign_extend` helper2025-07-29T14:17:48+00:00Oli Scherergithub333195615777966@oli-obk.de2025-07-29T08:43:10+00:00urn:sha1:219bad49461f5c9fc318732a73a05af5d198fed2Pick the largest niche even if the largest niche is wrapped around2025-07-29T14:08:15+00:00Oli Scherergithub333195615777966@oli-obk.de2025-07-24T10:19:20+00:00urn:sha1:75bdbf25e39f073b35eadedcf575affac7762a86Remove dead code and extend test coverage and diagnostics around it2025-07-24T10:21:20+00:00Oli Scherergithub333195615777966@oli-obk.de2025-07-24T08:15:03+00:00urn:sha1:e44a7386c27f821515804fa90ed39ca1e931f8de
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
compiler: Rename LayoutS to LayoutData in comments2025-06-20T17:50:12+00:00Zachary Szasample18+github@gmail.com2025-06-20T17:50:12+00:00urn:sha1:78c2ef2d488fbd8e4688139224f76ec0a33dc31eRemove rustc's notion of "preferred" alignment AKA `__alignof`2025-06-08T23:41:46+00:00Jubilee Youngworkingjubilee@gmail.com2025-02-12T06:09:16+00:00urn:sha1:2e1965831526407bada7abec631d7b7e9f6cbc7d
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it
necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a
requirement for C++ (not C, not Rust) stack frame layout for AIX,
in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness
5. can be adequately replaced by other rules for globals, as it mostly
affects alignments for a few types under 16 bytes of alignment
6. has only one clear benefactor: automating C -> Rust translation
for GNU extensions like `__alignof`
7. such code was likely intended to be `alignof` or `_Alignof`,
because the GNU extension is a "false friend" of the C keyword,
which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere
presence as usual Rust rules of alignment (e.g. `size == align * N`)
do not hold with preferred alignment
The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
Change `tag_field` to `FieldIdx` in `Variants::Multiple`2025-06-04T06:42:21+00:00Scott McMurrayscottmcm@users.noreply.github.com2025-06-04T06:42:21+00:00urn:sha1:ee9901e65c78f70b93dab5bd1e04bd77273b7c40
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
Initial `UnsafePinned`/`UnsafeUnpin` impl [Part 1: Libs]2025-04-13T05:11:04+00:00Skysky@sky9.dev2025-02-14T20:56:24+00:00urn:sha1:21b7360a9aecac472d6b7b9716c8e57641f648d0Move coroutine layout logic to `rustc_abi`2025-03-08T15:16:23+00:00Moulinsarthur.heuillard@orange.fr2025-03-07T21:13:22+00:00urn:sha1:08530d3e99dd84eb0a32a00168a11cab44d70118Move SIMD layout logic to `rustc_abi`2025-03-08T11:35:32+00:00Moulinsarthur.heuillard@orange.fr2025-03-07T20:17:16+00:00urn:sha1:e69491ac6021572d4ac9cde1c14a04673b4ec859