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 read_discriminant: return a scalar instead of raw underlying bytes #72419

Merged
merged 7 commits into from
May 30, 2020

Conversation

RalfJung
Copy link
Member

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 21, 2020
}
};
// Compute the size of the scalar we need to return.
// FIXME: Why do we not need to do a cast here like we do above?
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one particularly confused me -- we should resolve that question before landing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the niche layout, the variant indices have to not overflow host u32 nor the target (type-checking) discriminant type (isize by default but I guess it could be u8/i8).

So you can add an assert that it fits as a positive number in the discriminant type, but no cast should be necessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Scalar::from_u32 already has such an assert (at least on debug builds).

@bors

This comment has been minimized.

@RalfJung
Copy link
Member Author

This makes the generator-related Miri tests fail:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Size { raw: 4 }`,
 right: `Size { raw: 8 }`: Size mismatch when writing bits', /home/r/src/rust/rustc.2/src/libstd/macros.rs:16:9

I'll need to investigate.

Comment on lines 605 to 606
// - The field storing the discriminant has a layout, which my be a pointer.
// This is `discr_val.layout`; we just use it for sanity checks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"storing the discriminant" could be something more like "encoding the discriminant as a tag/niche".

That might make it clearer why the type differs: the only reason to have a simple encoding is cheap decoding, it could be any arbitrary mapping as long as you have enough values for every possible discriminant to be represented.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"encoding the discriminant as a tag/niche".

But the layout of the tag/niche is discr_layout, right? The second item in my list? And then discr_ty is the high-level thing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the layout of the tag/niche is discr_layout, right?

If this is correct I'll rename the variables to tag_layout or so.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did that, and also opened #72497 for the general terminology cleanup.

Comment on lines 607 to 609
// - The discriminant has a layout for tag storing purposes, which is always an integer.
// This is `discr_layout` and is used to interpret the value we read from the
// discriminant field.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what this refers to. Is this a tag/niche-sized integer? So for e.g. a pointer niche, it would be a pointer-sized integer?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the layout stored in Variants::Multiple::discr. So I think the answer to your questions is "yes".

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 comments (@oli-obk could take a look at the more miri-specific parts of this, which I'm not too familiar with)

@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@RalfJung
Copy link
Member Author

This PR now also includes a discriminant_ty helper method to determine the discriminant type for any type. This is shared between Rvalue type computation and Miri. And indeed it fixes a bug in the former which uses isize as discriminant type for non-enum ADTs (instead of u8).

@RalfJung RalfJung force-pushed the read-discriminant branch 3 times, most recently from 27bb80b to 9fbdad0 Compare May 25, 2020 13:33
@RalfJung
Copy link
Member Author

Rebased as my cast-cleanup-PR also included a commit from this one.

@oli-obk
Copy link
Contributor

oli-obk commented May 26, 2020

@bors r=oli-obk,eddyb

@bors
Copy link
Contributor

bors commented May 26, 2020

📌 Commit 95b853c has been approved by oli-obk,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 May 26, 2020
RalfJung added a commit to RalfJung/rust that referenced this pull request May 29, 2020
…bk,eddyb

Miri read_discriminant: return a scalar instead of raw underlying bytes

r? @oli-obk @eddyb
@RalfJung
Copy link
Member Author

Failed in #72737 (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 May 29, 2020
@RalfJung
Copy link
Member Author

Fixes type sanity check assertions.
@bors r=oli-obk,eddyb

@bors
Copy link
Contributor

bors commented May 29, 2020

📌 Commit c4b6224 has been approved by oli-obk,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 May 29, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request May 30, 2020
Rollup of 10 pull requests

Successful merges:

 - rust-lang#72033 (Update RELEASES.md for 1.44.0)
 - rust-lang#72162 (Add Extend::{extend_one,extend_reserve})
 - rust-lang#72419 (Miri read_discriminant: return a scalar instead of raw underlying bytes)
 - rust-lang#72621 (Don't bail out of trait selection when predicate references an error)
 - rust-lang#72677 (Fix diagnostics for `@ ..` binding pattern in tuples and tuple structs)
 - rust-lang#72710 (Add test to make sure -Wunused-crate-dependencies works with tests)
 - rust-lang#72724 (Revert recursive `TokenKind::Interpolated` expansion for now)
 - rust-lang#72741 (Remove unused mut from long-linker-command-lines test)
 - rust-lang#72750 (Remove remaining calls to `as_local_node_id`)
 - rust-lang#72752 (remove mk_bool)

Failed merges:

r? @ghost
@bors bors merged commit a5fb7fc into rust-lang:master May 30, 2020
@RalfJung RalfJung deleted the read-discriminant branch May 30, 2020 12:06
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 16, 2020
tag/niche terminology cleanup

The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).

After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).

This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in rust-lang#72419.

(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)

r? @eddyb
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 16, 2020
tag/niche terminology cleanup

The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).

After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).

This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in rust-lang#72419.

(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)

r? @eddyb
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 18, 2020
tag/niche terminology cleanup

The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).

After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).

This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in rust-lang#72419.

(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)

r? @eddyb
RalfJung added a commit to RalfJung/rust that referenced this pull request Jun 19, 2020
tag/niche terminology cleanup

The term "discriminant" was used in two ways throughout the compiler:
* every enum variant has a corresponding discriminant, that can be given explicitly with `Variant = N`.
* that discriminant is then encoded in memory to store which variant is active -- but this encoded form of the discriminant was also often called "discriminant", even though it is conceptually quite different (e.g., it can be smaller in size, or even use niche-filling).

After discussion with @eddyb, this renames the second term to "tag". The way the tag is encoded can be either `TagEncoding::Direct` (formerly `DiscriminantKind::Tag`) or `TagEncoding::Niche` (formerly `DiscrimianntKind::Niche`).

This finally resolves some long-standing confusion I had about the handling of variant indices and discriminants, which surfaced in rust-lang#72419.

(There is also a `DiscriminantKind` type in libcore, it remains unaffected. I think this corresponds to the discriminant, not the tag, so that seems all right.)

r? @eddyb
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.

5 participants