-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miri visitor: detect primitive types based on type, not layout (also, more tests) #69646
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo nits (mostly comments, really).
| ty::Dynamic(..) | ||
| ty::Closure(..) | ||
| ty::Generator(..) | ||
| ty::GeneratorWitness(..) => Ok(false), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GeneratorWitness
also has a layout that we can traverse, right? I have no idea what that type kind dos (and its doc comment is pretty useless as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @Zoxc but I think it's meant like a builtin PhantomData
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A value cannot have the type GeneratorWitness
. GeneratorWitness
may only appear inside a ty::Generator
. I think having it panic here would be the right choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GeneratorWitness may only appear inside a ty::Generator.
But doesn't that mean that a value of ty::Generator
type might contain a GeneratorWitness
?
The doc comment says something similar and I don't understand what "only appear inside a Generator
means.
But I'll happily make it panic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's in the Substs
of the Generator
, but not as field type. This is why I mentioned PhantomData
.
enum UninhDiscriminant { | ||
A, | ||
B(!), | ||
C, | ||
D(Never), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope this is the kind of enum that triggers interesting uninhabited variants?
Also see the ones with Result
below.
@eddyb I think I took care of the comments, and I also pointed to some parts that I'd prefer you to double-check. :) |
This comment has been minimized.
This comment has been minimized.
@bors r+ |
📌 Commit e4ae6e6566a572692537af665982d5421ed84662 has been approved by |
☔ The latest upstream changes (presumably #69550) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased. @bors r=eddyb |
📌 Commit bd4c9a167b05a45c9ca52213a57f16c0ba642646 has been approved by |
Failed in #69819 (comment), @bors r- |
Argh, a 32bit-only failure... sorry for that! |
@bors r=eddyb |
📌 Commit e623ea5350a22a670a1e4d9a838eb50f0acec9f7 has been approved by |
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
This comment has been minimized.
This comment has been minimized.
Tidy is merciless and almighty. |
📌 Commit a95f00f has been approved by |
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
Rollup of 8 pull requests Successful merges: - #69631 (remove non-sysroot sources from rust-src component) - #69646 (Miri visitor: detect primitive types based on type, not layout (also, more tests)) - #69651 (Try to ensure usize marker does not get merged) - #69668 (More documentation and simplification of BTreeMap's internals) - #69685 (unix: Don't override existing SIGSEGV/BUS handlers) - #69771 (Cleanup E0390 explanation) - #69777 (Add missing ` in doc for File::with_options()) - #69812 (Refactorings to method/probe.rs and CrateId) Failed merges: r? @ghost
Rollup of 7 pull requests Successful merges: - #69631 (remove non-sysroot sources from rust-src component) - #69646 (Miri visitor: detect primitive types based on type, not layout (also, more tests)) - #69651 (Try to ensure usize marker does not get merged) - #69668 (More documentation and simplification of BTreeMap's internals) - #69771 (Cleanup E0390 explanation) - #69777 (Add missing ` in doc for File::with_options()) - #69812 (Refactorings to method/probe.rs and CrateId) Failed merges: r? @ghost
Ensure that validity only raises validity errors For now, only as a debug-assertion (similar to const-prop detecting errors that allocate). Now includes rust-lang#69646. [Relative diff](RalfJung/rust@layout-visitor...RalfJung:validity-errors). r? @oli-obk
Ensure that validity only raises validity errors For now, only as a debug-assertion (similar to const-prop detecting errors that allocate). Now includes rust-lang#69646. [Relative diff](RalfJung/rust@layout-visitor...RalfJung:validity-errors). r? @oli-obk
Ensure that validity only raises validity errors For now, only as a debug-assertion (similar to const-prop detecting errors that allocate). Now includes rust-lang#69646. [Relative diff](RalfJung/rust@layout-visitor...RalfJung:validity-errors). r? @oli-obk
Ensure that validity only raises validity errors For now, only as a debug-assertion (similar to const-prop detecting errors that allocate). Now includes rust-lang#69646. [Relative diff](RalfJung/rust@layout-visitor...RalfJung:validity-errors). r? @oli-obk
--> $DIR/ub-enum.rs:92:1 | ||
| | ||
LL | const BAD_UNINHABITED_WITH_DATA2: Result<(i32, !), (i32, Never)> = unsafe { mem::transmute(1u64) }; | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a value of uninhabited type Never at .<enum-variant(Err)>.0.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it supposed to be deterministic that this fails on the Err
variant?
On s390x, I'm seeing an error on the Ok
variant instead for both of these Result
tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it then also says !
instead of Never
?
That is odd... it means that data layout is very different on s390x? Could this be an endianess thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the test failure looks like this:
---- [ui] ui/consts/const-eval/ub-enum.rs stdout ----
diff of stderr:
90 --> $DIR/ub-enum.rs:90:1
91 |
92 LL | const BAD_UNINHABITED_WITH_DATA1: Result<(i32, Never), (i32, !)> = unsafe { mem::transmute(1u64) };
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a value of the never type `!` at .<enum-variant(Err)>.0.1
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a value of uninhabited type Never at .<enum-variant(Ok)>.0.1
94 |
95 = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
96
98 --> $DIR/ub-enum.rs:92:1
99 |
100 LL | const BAD_UNINHABITED_WITH_DATA2: Result<(i32, !), (i32, Never)> = unsafe { mem::transmute(1u64) };
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a value of uninhabited type Never at .<enum-variant(Err)>.0.1
+ | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered a value of the never type `!` at .<enum-variant(Ok)>.0.1
102 |
103 = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
104
The actual stderr differed from the expected stderr.
I just checked for endianness -- it failed the same way on powerpc64, but passed on powerpc64le and the rest of our little-endian targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this makes sense, the 1
in the u64
moves to the other end of the 8-byte range and thus doesn't land on the tag any more.
I think it is fine to use 0
instead of 1
as the constant here, which should make this endianess-independent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will prepare a PR to change this to 0.
I also converted the union-based transmutes to use
mem::transmute
for increased readability.r? @eddyb @oli-obk