rustc_abi: Add LayoutData::is_variant_uninhabited method - #160398
Conversation
|
Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri
cc @bjorn3 Some changes occurred to the CTFE machinery |
|
r? @mu001999 rustbot has assigned @mu001999. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustc_abi: Add `LayoutData::is_variant_uninhabited` method
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (4e9517e): comparison URL. Overall result: no relevant changes - no action neededBenchmarking 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 countThis 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.
CyclesResults (primary -0.2%, secondary -0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 490.376s -> 489.668s (-0.14%) |
|
@rustbot reroll |
|
Considering there's no measurable impact, is it worth having two ways to do the same thing? |
|
Well, I won't bury the lede: I find the concept of I'm also investigating providing a |
|
good motivation :D Please add a doc comment to r=me with that |
This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`
01aa949 to
187cf5d
Compare
|
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 review |
…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.
…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.
…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.
…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.
…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)
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.
|
@rust-timer build b4a4124 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (b4a4124): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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 countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
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.
CyclesResults (primary 2.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 458.35s -> 460.051s (0.37%) |
…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.
This is a cheaper alternative to
TyAndLayout::for_variant(_, idx).is_uninhabited(), which avoids the extra work done byTyAndLayout::for_variant.EDIT: Let me expand on the motivation from this comment:
TyAndLayout::for_variantis a curious API: the resulting layout doesn't represent a Rust type in the strict sense (not evenpattern_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.