Skip to content

rustc_abi: Add LayoutData::is_variant_uninhabited method - #160398

Merged
rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
moulins:layout-is-variant-uninhabited
Aug 6, 2026
Merged

rustc_abi: Add LayoutData::is_variant_uninhabited method#160398
rust-bors[bot] merged 2 commits into
rust-lang:mainfrom
moulins:layout-is-variant-uninhabited

Conversation

@moulins

@moulins moulins commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

This is a cheaper alternative to TyAndLayout::for_variant(_, idx).is_uninhabited(), which avoids the extra work done by TyAndLayout::for_variant.

EDIT: Let me expand on the motivation from this comment:

TyAndLayout::for_variant is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even pattern_type!(Enum is Variant { .. }); instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add TyAndLayout::variant_field(self, cx, variant_idx, field_idx) to deal with the next-most common case of only needing a variant layout for field lookups.

@rustbot

rustbot commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 2, 2026
@rustbot

rustbot commented Aug 2, 2026

Copy link
Copy Markdown
Collaborator

r? @mu001999

rustbot has assigned @mu001999.
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

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: codegen, compiler
  • codegen, compiler expanded to 75 candidates
  • Random selection from 20 candidates

@hanna-kruppe

Copy link
Copy Markdown
Contributor

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 2, 2026
@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Aug 2, 2026
rustc_abi: Add `LayoutData::is_variant_uninhabited` method
@rust-bors

rust-bors Bot commented Aug 2, 2026

Copy link
Copy Markdown
Contributor

☀️ Try build successful (CI)
Build commit: 4e9517e (4e9517ed78b554a781024590a80c4637001a0a3d)
Base parent: 28c66af (28c66af27578a28bc8cad1c5957be4b1e2e7fb8b)

@rust-timer

This comment has been minimized.

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (4e9517e): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (primary 0.4%, secondary 0.5%)

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

mean range count
Regressions ❌
(primary)
0.4% [0.4%, 0.4%] 1
Regressions ❌
(secondary)
0.5% [0.4%, 0.6%] 9
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.4% [0.4%, 0.4%] 1

Cycles

Results (primary -0.2%, secondary -0.4%)

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

mean range count
Regressions ❌
(primary)
0.7% [0.5%, 1.0%] 3
Regressions ❌
(secondary)
0.9% [0.5%, 1.5%] 6
Improvements ✅
(primary)
-0.6% [-1.0%, -0.5%] 6
Improvements ✅
(secondary)
-1.6% [-4.8%, -0.4%] 6
All ❌✅ (primary) -0.2% [-1.0%, 1.0%] 9

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.376s -> 489.668s (-0.14%)
Artifact size: 390.46 MiB -> 390.37 MiB (-0.02%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Aug 2, 2026
@mu001999

mu001999 commented Aug 3, 2026

Copy link
Copy Markdown
Member

@rustbot reroll

@rustbot rustbot assigned oli-obk and unassigned mu001999 Aug 3, 2026
@oli-obk

oli-obk commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Considering there's no measurable impact, is it worth having two ways to do the same thing?

@moulins

moulins commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Well, I won't bury the lede: I find the concept of TyAndLayout::for_variant deeply suspect (it doesn't even cleanly represent the layout of a potential pattern_type!(foo is Enum::Variant { .. })) and I think it should be used as little as possible.

I'm also investigating providing a fn variant_field(self, cx, variant_idx, field_idx) method to lookup a variant-specific field directly, which should cover most of the other use-cases of TyAndLayout::for_variant.

@oli-obk

oli-obk commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

good motivation :D Please add a doc comment to for_variant and update the main PR description with that motivation

r=me with that

@oli-obk oli-obk added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 4, 2026
@moulins
moulins force-pushed the layout-is-variant-uninhabited branch from 01aa949 to 187cf5d Compare August 5, 2026 13:39
@rustbot

rustbot commented Aug 5, 2026

Copy link
Copy Markdown
Collaborator

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.

@moulins

moulins commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

@rustbot review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 5, 2026

@oli-obk oli-obk left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rust-bors

rust-bors Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

📌 Commit 187cf5d has been approved by oli-obk

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 6, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 6, 2026
…ted, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 6, 2026
…ted, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 6, 2026
…ted, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Aug 6, 2026
…ted, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
rust-bors Bot pushed a commit that referenced this pull request Aug 6, 2026
…uwer

Rollup of 17 pull requests

Successful merges:

 - #159530 (Cap socket send length to c_int::MAX on Apple targets)
 - #159506 (Allow associated const equality constraints with GCA)
 - #160006 (Account for desugaring in method call move errors)
 - #160415 (Split `aarch64-apple{,-macos-26}` => `aarch64-apple{,-macos-26}-{1,2}` jobs)
 - #160464 (fix: Check the fallback map before queueing child in `visible_parent_map` breadth-first search)
 - #160555 (Split `apply_primary_terminator_effect`)
 - #160592 (Suggest if-let chain continuation on unclosed delimiter)
 - #160600 (Avoid the std DLL copy alongside rustc)
 - #160156 (check_consts: exhaustively match on CastKind)
 - #160211 (Rename `#[unroll]` => `#[rustc_unroll]` to mitigate nameres ambiguity)
 - #160304 (Add tests for fixed new solver issues)
 - #160398 (rustc_abi: Add `LayoutData::is_variant_uninhabited` method)
 - #160546 (Update error message in documentation comments)
 - #160568 (Use `VisitorResult` helper macros)
 - #160571 (Add regression test for array type recovery in generic arguments)
 - #160588 (add a test showing polonius alpha is not a subset of datalog polonius)
 - #160617 (Add a suggestion to MissingUnsafeOnExtern diagnostic)
@rust-bors
rust-bors Bot merged commit 592096b into rust-lang:main Aug 6, 2026
13 checks passed
@rustbot rustbot added this to the 1.99.0 milestone Aug 6, 2026
rust-timer added a commit that referenced this pull request Aug 6, 2026
Rollup merge of #160398 - moulins:layout-is-variant-uninhabited, r=oli-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
@JonathanBrouwer

Copy link
Copy Markdown
Contributor

@rust-timer build b4a4124

@rust-timer

This comment has been minimized.

@moulins
moulins deleted the layout-is-variant-uninhabited branch August 6, 2026 21:32
@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (b4a4124): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.4% [-0.5%, -0.2%] 7
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -6.8%)

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)
- - 0
Improvements ✅
(primary)
-6.8% [-6.8%, -6.8%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -6.8% [-6.8%, -6.8%] 1

Cycles

Results (primary 2.3%)

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

mean range count
Regressions ❌
(primary)
2.3% [2.0%, 2.5%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.3% [2.0%, 2.5%] 2

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 458.35s -> 460.051s (0.37%)
Artifact size: 398.64 MiB -> 398.69 MiB (0.01%)

bjorn3 pushed a commit to rust-lang/rustc_codegen_cranelift that referenced this pull request Aug 7, 2026
…i-obk

rustc_abi: Add `LayoutData::is_variant_uninhabited` method

This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`, which avoids the extra work done by `TyAndLayout::for_variant`.

EDIT: Let me expand on the motivation from this [comment](rust-lang/rust#160398 (comment)):

`TyAndLayout::for_variant` is a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not even `pattern_type!(Enum is Variant { .. })`; instead, it only describes the "variant-specific" fields, and fields shared between variants (e.g. the enum tag or coroutine captures) are entirely missing.

As such, I believe alternative APIs should be used instead to clarify intent, when possible. This PR deals with the simplest cases, and a future PR will add `TyAndLayout::variant_field(self, cx, variant_idx, field_idx)` to deal with the next-most common case of only needing a variant layout for field lookups.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants