Skip to content
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

Merged
merged 10 commits into from
Mar 8, 2020

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Mar 2, 2020

I also converted the union-based transmutes to use mem::transmute for increased readability.

r? @eddyb @oli-obk

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 2, 2020
@rust-highfive

This comment has been minimized.

Copy link
Member

@eddyb eddyb left a 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),
Copy link
Member Author

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).

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member

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.

Comment on lines +67 to +72
enum UninhDiscriminant {
A,
B(!),
C,
D(Never),
}
Copy link
Member Author

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.

@RalfJung
Copy link
Member Author

RalfJung commented Mar 2, 2020

@eddyb I think I took care of the comments, and I also pointed to some parts that I'd prefer you to double-check. :)

@rust-highfive

This comment has been minimized.

@eddyb
Copy link
Member

eddyb commented Mar 2, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Mar 2, 2020

📌 Commit e4ae6e6566a572692537af665982d5421ed84662 has been approved by eddyb

@bors bors 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 Mar 2, 2020
@bors
Copy link
Contributor

bors commented Mar 4, 2020

☔ The latest upstream changes (presumably #69550) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 4, 2020
@RalfJung
Copy link
Member Author

RalfJung commented Mar 4, 2020

Rebased. @bors r=eddyb

@bors
Copy link
Contributor

bors commented Mar 4, 2020

📌 Commit bd4c9a167b05a45c9ca52213a57f16c0ba642646 has been approved by eddyb

@bors bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 4, 2020
Centril added a commit to Centril/rust that referenced this pull request Mar 8, 2020
Miri visitor: detect primitive types based on type, not layout (also, more tests)

I also converted the union-based transmutes to use `mem::transmute` for increased readability.

r? @eddyb @oli-obk
@Centril
Copy link
Contributor

Centril commented Mar 8, 2020

Failed in #69819 (comment), @bors r-

@bors bors 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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 8, 2020
@RalfJung
Copy link
Member Author

RalfJung commented Mar 8, 2020

Argh, a 32bit-only failure... sorry for that!

@RalfJung
Copy link
Member Author

RalfJung commented Mar 8, 2020

@bors r=eddyb

@bors
Copy link
Contributor

bors commented Mar 8, 2020

📌 Commit e623ea5350a22a670a1e4d9a838eb50f0acec9f7 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Mar 8, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@bors bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 8, 2020
@rust-highfive

This comment has been minimized.

@RalfJung
Copy link
Member Author

RalfJung commented Mar 8, 2020

Tidy is merciless and almighty.
@bors r=eddyb

@bors
Copy link
Contributor

bors commented Mar 8, 2020

📌 Commit a95f00f has been approved by eddyb

@bors
Copy link
Contributor

bors commented Mar 8, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

Centril added a commit to Centril/rust that referenced this pull request Mar 8, 2020
Miri visitor: detect primitive types based on type, not layout (also, more tests)

I also converted the union-based transmutes to use `mem::transmute` for increased readability.

r? @eddyb @oli-obk
bors added a commit that referenced this pull request Mar 8, 2020
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
bors added a commit that referenced this pull request Mar 8, 2020
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
@bors bors merged commit c31b704 into rust-lang:master Mar 8, 2020
@RalfJung RalfJung deleted the layout-visitor branch March 8, 2020 21:05
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
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
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
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
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
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
Centril added a commit to Centril/rust that referenced this pull request Mar 9, 2020
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
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants