require full validity when determining the discriminant of a value#90895
Merged
bors merged 1 commit intorust-lang:masterfrom Nov 18, 2021
Merged
require full validity when determining the discriminant of a value#90895bors merged 1 commit intorust-lang:masterfrom
bors merged 1 commit intorust-lang:masterfrom
Conversation
Contributor
|
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
rust-highfive
added
the
S-waiting-on-review
RalfJung
force-pushed
the
read-discriminant-valid
branch
from
4869098 to
a125e39
Compare
This comment has been minimized.
This comment has been minimized.
Member
Author
Actually, that failure is legit -- this change made discriminant reading and validation mutually recursive. D'oh. |
RalfJung
force-pushed
the
read-discriminant-valid
branch
from
a125e39 to
498ebc4
Compare
RalfJung
changed the title
Member
Author
|
I changed the PR to use a different approach -- but now it has no effect during CTFE, so it cannot be tested here. |
wesleywiser
approved these changes
Nov 16, 2021
Contributor
|
@bors r+ rollup |
Collaborator
|
📌 Commit 498ebc4 has been approved by |
bors
added
S-waiting-on-bors
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Nov 18, 2021
…=oli-obk require full validity when determining the discriminant of a value This resolves (for now) the semantic question that came up in rust-lang#89764: arguably, reading the discriminant of a value is 'using' that value, so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just "doing their job". The alternative would be to just require that the discriminant itself is valid, if any -- but then what do we do for types that do not have a discriminant, which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types, but I would rather not special case that. I don't think this can be tested in CTFE (since validity is not enforced there), I will add a compile-fail test to Miri: ```rust #[allow(enum_intrinsics_non_enums)] fn main() { let i = 2u8; std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB } ``` (I tried running the check even on the CTFE machines, but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp, but that simply does not seem worth the effort currently.) r? `@oli-obk`
apiraino
added
the
T-compiler
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 18, 2021
Rollup of 8 pull requests Successful merges: - rust-lang#90386 (Add `-Zassert-incr-state` to assert state of incremental cache) - rust-lang#90438 (Clean up mess for --show-coverage documentation) - rust-lang#90480 (Mention `Vec::remove` in `Vec::swap_remove`'s docs) - rust-lang#90607 (Make slice->str conversion and related functions `const`) - rust-lang#90750 (rustdoc: Replace where-bounded Clean impl with simple function) - rust-lang#90895 (require full validity when determining the discriminant of a value) - rust-lang#90989 (Avoid suggesting literal formatting that turns into member access) - rust-lang#91002 (rustc: Remove `#[rustc_synthetic]`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Member
Author
|
Ah, turns out this uncovered a quirk/bug in MIR building: #91029. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This resolves (for now) the semantic question that came up in #89764: arguably, reading the discriminant of a value is 'using' that value, so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of arbitrary type; all the other primitive MIR operations work on specific types (e.g.
boolor an integer) and basically implicitly require validity as part of just "doing their job".The alternative would be to just require that the discriminant itself is valid, if any -- but then what do we do for types that do not have a discriminant, which kind of validity do we check? This code means we have to at least reject uninhabited types, but I would rather not special case that.
I don't think this can be tested in CTFE (since validity is not enforced there), I will add a compile-fail test to Miri:
(I tried running the check even on the CTFE machines, but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp, but that simply does not seem worth the effort currently.)
r? @oli-obk