Remove redundant information in `rustc_abi::Variants` by moulins · Pull Request #151742 · rust-lang/rust

moulins · 2026-01-27T14:26:28Z

Follow-up to #151040; partially addresses #113988.

Replaces the nested LayoutData in Variants::Multiple by a new, smaller VariantLayout struct, and adjust LayoutData::for_variantand the layout algorithm in consequence.
This PR is best reviewed commit-by-commit.

rustbot · 2026-01-27T14:26:32Z

This PR changes rustc_public

cc @oli-obk, @celinval, @ouz-a, @makai410

rustbot · 2026-01-27T14:26:35Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

moulins · 2026-01-27T14:28:30Z

+#[derive(PartialEq, Eq, Hash, Clone, Debug)]
+#[cfg_attr(feature = "nightly", derive(HashStable_Generic))]
+pub struct VariantLayout<FieldIdx: Idx> {
+    pub size: Size,


Can't be removed, as it is used by the variant_size_differences lint.

moulins · 2026-01-27T14:31:15Z

+#[cfg_attr(feature = "nightly", derive(HashStable_Generic))]
+pub struct VariantLayout<FieldIdx: Idx> {
+    pub size: Size,
+    pub backend_repr: BackendRepr,


I don't know enough about codegen to confidently say if it requires accurate reprs for enum variants, so I've left this field for now.

Enum variants should not need their own BackendRepr, but it is probably a good idea to leave this cleanup for a future PR.

moulins · 2026-01-27T14:33:53Z

+    pub size: Size,
+    pub backend_repr: BackendRepr,
+    pub field_offsets: IndexVec<FieldIdx, Size>,
+    fields_in_memory_order: IndexVec<u32, FieldIdx>,


Note: this field could be removed and recomputed from the field offsets in Layout::from_variant; it's unclear whether this is worth it.

moulins · 2026-01-27T14:35:01Z

+                // Remove discriminant values of the other variants from the largest niche. This assumes
+                // that the largest niche, when it exists, always corresponds to the enum discriminant.


This assumption was already implicitly made by the original code.

moulins · 2026-01-27T14:38:24Z

                let min = valid_range.start.min(valid_range.end);
                let min = tag.size(cx).truncate(min);

                let max = valid_range.start.max(valid_range.end);
                let max = tag.size(cx).truncate(max);


I think this logic is broken for valid ranges wrapping around uN::MAX? In any case, fixing this is out-of-scope of the PR, so I've left it as-is.

Maybe leave a FIXME comment?

Kobzol · 2026-01-28T08:03:09Z

@bors try @rust-timer queue

Remove redundant information in `rustc_abi::Variants`

rust-bors · 2026-01-28T10:17:01Z

☀️ Try build successful (CI)
Build commit: 968e542 (968e5428d360caed1ceef0036386d8f8959a91bf, parent: e96bb7e44fbcc23c1e6009e8d0ee8ab208668fb4)

rust-timer · 2026-01-28T10:58:24Z

Finished benchmarking commit (968e542): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.3%, -0.0%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 1.4%, secondary -2.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.8%	[1.6%, 5.7%]	4
Regressions ❌ (secondary)	1.9%	[0.5%, 3.4%]	3
Improvements ✅ (primary)	-1.7%	[-2.0%, -1.4%]	3
Improvements ✅ (secondary)	-4.7%	[-5.6%, -2.4%]	7
All ❌✅ (primary)	1.4%	[-2.0%, 5.7%]	7

Cycles

Results (secondary 3.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[3.9%, 5.5%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.0%]	1

Bootstrap: 470.891s -> 473.88s (0.63%)
Artifact size: 383.44 MiB -> 383.70 MiB (0.07%)

apiraino · 2026-03-26T12:34:01Z

r? compiler

cc @makai410 since you approved #151040?

makai410 · 2026-03-26T13:36:06Z

cc @workingjubilee IIRC you were involved in the related discussion on discord?

chenyukang · 2026-03-26T13:47:37Z

@rustbot reroll

jieyouxu · 2026-03-27T10:24:08Z

I'm finding another compiler reviewer for this PR.

Remove redundant information in `rustc_abi::Variants` Follow-up to #151040; partially addresses #113988. Replaces the nested `LayoutData` in `Variants::Multiple` by a new, smaller `VariantLayout` struct, and adjust `LayoutData::for_variant`and the layout algorithm in consequence. This PR is best reviewed commit-by-commit.

rust-bors · 2026-04-29T13:17:36Z

💔 Test for cad8c01 failed: CI. Failed job:

auto - x86_64-gnu-llvm-21-1 (web logs, enhanced plaintext logs)

JonathanBrouwer · 2026-04-29T13:31:04Z

The rollup failed with the same error, so not spurious
#155960 (comment)

JonathanBrouwer · 2026-04-29T13:41:02Z

And the try job on the rollup just succeeded, fascinating. I'll leave it to y'all to figure out what to do with this
#155960 (comment)

saethlin · 2026-04-29T13:57:44Z

SIGSEGV from unit tests wat

JonathanBrouwer · 2026-04-29T14:02:06Z

@bors try jobs=x86_64-gnu-llvm-21-1
lets get one more datapoint

Remove redundant information in `rustc_abi::Variants` try-job: x86_64-gnu-llvm-21-1

rust-bors · 2026-04-29T15:12:23Z

💔 Test for 27a14b2 failed: CI. Failed job:

try - x86_64-gnu-llvm-21-1 (web logs, enhanced plaintext logs)

moulins · 2026-04-29T16:15:25Z

I can't reproduce this on my machine (linux, x86) with ./x --stage 2 test src/tools/rust-analyzer, so I don't have a clue to what's going on here :(

saethlin · 2026-05-04T00:27:29Z

The job that failed at least the last time above sets -Zrandomize-layout:

rust/src/ci/docker/host-x86_64/x86_64-gnu-llvm-21/Dockerfile

Line 54 in ad3a598

--set rust.randomize-layout=true \

In general when trying to reproduce a CI failure, it is good to run the CI scripts. Yes they can be very slow because they don't reuse your normal build artifacts, but they pull in all the configuration. You should be able to run CI locally, the docs for how to do that are here right now: https://rustc-dev-guide.rust-lang.org/tests/ci.html#docker

JonathanBrouwer · 2026-05-14T09:52:16Z

FYI the ci error was spurious, so feel free to retry when the open comment is resolved

For now, this is a 1-to-1 copy of `LayoutData`, but this will change.

It was always set to `Variants::Single`.

Enum variants always have `Arbitrary` layout, so the enum isn't needed.

This field is only used during layout calculations, so re-synthetized `LayoutData`s for enum variants can use a dummy value instead.

Reusing the alignment of the enclosing enum in `LayoutData::for_variant` doesn't appear to cause any issues.

rustbot · 2026-05-15T02:37:15Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Jan 27, 2026

rustbot assigned wesleywiser Jan 27, 2026

moulins commented Jan 27, 2026

View reviewed changes