Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
error[E0080]: evaluation of constant value failed
|
|
|
|
|
--> $DIR/uninhabited.rs:41:9
|
|
|
|
|
|
|
|
|
|
|
LL | assert!(false);
|
|
|
|
|
| ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:41:9
|
|
|
|
|
|
|
|
|
|
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
|
|
|
|
|
|
|
|
|
|
error[E0080]: evaluation of constant value failed
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
--> $DIR/uninhabited.rs:63:9
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
|
|
|
|
|
|
LL | assert!(false);
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
| ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:63:9
|
|
|
|
|
|
|
|
|
|
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
|
|
|
|
|
|
|
|
|
|
error[E0080]: evaluation of constant value failed
|
|
|
|
|
--> $DIR/uninhabited.rs:87:9
|
|
|
|
|
|
|
|
|
|
|
LL | assert!(false);
|
|
|
|
|
| ^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: false', $DIR/uninhabited.rs:87:9
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
|
|
|
|
|
|
= note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)
|
|
|
|
|
|
|
|
|
|
error[E0277]: `()` cannot be safely transmuted into `void::Void`
|
|
|
|
|
--> $DIR/uninhabited.rs:29:41
|
|
|
|
|
|
|
|
|
|
|
LL | assert::is_maybe_transmutable::<(), Void>();
|
|
|
|
|
| ^^^^ `void::Void` is uninhabited
|
|
|
|
|
|
|
|
|
|
|
note: required by a bound in `is_maybe_transmutable`
|
|
|
|
|
--> $DIR/uninhabited.rs:10:14
|
|
|
|
|
|
|
|
|
|
|
LL | pub fn is_maybe_transmutable<Src, Dst>()
|
|
|
|
|
| --------------------- required by a bound in this function
|
|
|
|
|
LL | where
|
2024-08-27 09:05:54 -05:00
|
|
|
LL | Dst: TransmuteFrom<Src, {
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
| ______________^
|
|
|
|
|
LL | | Assume {
|
|
|
|
|
LL | | alignment: true,
|
|
|
|
|
LL | | lifetimes: true,
|
|
|
|
|
... |
|
|
|
|
|
LL | | }
|
|
|
|
|
LL | | }>
|
|
|
|
|
| |__________^ required by this bound in `is_maybe_transmutable`
|
|
|
|
|
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
error[E0277]: `()` cannot be safely transmuted into `yawning_void_struct::Void`
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
--> $DIR/uninhabited.rs:49:41
|
|
|
|
|
|
|
|
|
|
|
LL | assert::is_maybe_transmutable::<(), Void>();
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
| ^^^^ `yawning_void_struct::Void` is uninhabited
|
|
|
|
|
|
|
|
|
|
|
note: required by a bound in `is_maybe_transmutable`
|
|
|
|
|
--> $DIR/uninhabited.rs:10:14
|
|
|
|
|
|
|
|
|
|
|
LL | pub fn is_maybe_transmutable<Src, Dst>()
|
|
|
|
|
| --------------------- required by a bound in this function
|
|
|
|
|
LL | where
|
2024-08-27 09:05:54 -05:00
|
|
|
LL | Dst: TransmuteFrom<Src, {
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
| ______________^
|
|
|
|
|
LL | | Assume {
|
|
|
|
|
LL | | alignment: true,
|
|
|
|
|
LL | | lifetimes: true,
|
|
|
|
|
... |
|
|
|
|
|
LL | | }
|
|
|
|
|
LL | | }>
|
|
|
|
|
| |__________^ required by this bound in `is_maybe_transmutable`
|
|
|
|
|
|
|
|
|
|
error[E0277]: `()` cannot be safely transmuted into `yawning_void_enum::Void`
|
|
|
|
|
--> $DIR/uninhabited.rs:71:41
|
|
|
|
|
|
|
|
|
|
|
LL | assert::is_maybe_transmutable::<(), Void>();
|
|
|
|
|
| ^^^^ `yawning_void_enum::Void` is uninhabited
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
|
|
|
|
|
|
note: required by a bound in `is_maybe_transmutable`
|
|
|
|
|
--> $DIR/uninhabited.rs:10:14
|
|
|
|
|
|
|
|
|
|
|
LL | pub fn is_maybe_transmutable<Src, Dst>()
|
|
|
|
|
| --------------------- required by a bound in this function
|
|
|
|
|
LL | where
|
2024-08-27 09:05:54 -05:00
|
|
|
LL | Dst: TransmuteFrom<Src, {
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
| ______________^
|
|
|
|
|
LL | | Assume {
|
|
|
|
|
LL | | alignment: true,
|
|
|
|
|
LL | | lifetimes: true,
|
|
|
|
|
... |
|
|
|
|
|
LL | | }
|
|
|
|
|
LL | | }>
|
|
|
|
|
| |__________^ required by this bound in `is_maybe_transmutable`
|
|
|
|
|
|
|
|
|
|
error[E0277]: `u128` cannot be safely transmuted into `DistantVoid`
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
--> $DIR/uninhabited.rs:92:43
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
|
|
|
|
|
|
LL | assert::is_maybe_transmutable::<u128, DistantVoid>();
|
|
|
|
|
| ^^^^^^^^^^^ at least one value of `u128` isn't a bit-valid value of `DistantVoid`
|
|
|
|
|
|
|
|
|
|
|
note: required by a bound in `is_maybe_transmutable`
|
|
|
|
|
--> $DIR/uninhabited.rs:10:14
|
|
|
|
|
|
|
|
|
|
|
LL | pub fn is_maybe_transmutable<Src, Dst>()
|
|
|
|
|
| --------------------- required by a bound in this function
|
|
|
|
|
LL | where
|
2024-08-27 09:05:54 -05:00
|
|
|
LL | Dst: TransmuteFrom<Src, {
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
| ______________^
|
|
|
|
|
LL | | Assume {
|
|
|
|
|
LL | | alignment: true,
|
|
|
|
|
LL | | lifetimes: true,
|
|
|
|
|
... |
|
|
|
|
|
LL | | }
|
|
|
|
|
LL | | }>
|
|
|
|
|
| |__________^ required by this bound in `is_maybe_transmutable`
|
|
|
|
|
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
2024-06-14 12:02:07 -05:00
|
|
|
error: aborting due to 7 previous errors
|
Compute transmutability from `rustc_target::abi::Layout`
In its first step of computing transmutability, `rustc_transmutability`
constructs a byte-level representation of type layout (`Tree`). Previously, this
representation was computed for ADTs by inspecting the ADT definition and
performing our own layout computations. This process was error-prone, verbose,
and limited our ability to analyze many types (particularly default-repr types).
In this PR, we instead construct `Tree`s from `rustc_target::abi::Layout`s. This
helps ensure that layout optimizations are reflected our analyses, and increases
the kinds of types we can now analyze, including:
- default repr ADTs
- transparent unions
- `UnsafeCell`-containing types
Overall, this PR expands the expressvity of `rustc_transmutability` to be much
closer to the transmutability analysis performed by miri. Future PRs will work
to close the remaining gaps (e.g., support for `Box`, raw pointers, `NonZero*`,
coroutines, etc.).
2024-03-19 09:49:13 -05:00
|
|
|
|
|
|
|
|
Some errors have detailed explanations: E0080, E0277.
|
|
|
|
|
For more information about an error, try `rustc --explain E0080`.
|