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

interpret: use AllocRange in UninitByteAccess #98979

Merged
merged 1 commit into from
Jul 7, 2022

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Jul 6, 2022

also use nice new format string syntax in interpret/error.rs, and use the # flag to add 0x prefixes where applicable.

r? @oli-obk

also use nice new format string syntax in interpret/error.rs
@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 6, 2022
@rustbot
Copy link
Collaborator

rustbot commented Jul 6, 2022

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 6, 2022
@@ -2,7 +2,7 @@ error[E0080]: evaluation of constant value failed
--> $DIR/intrinsic-raw_eq-const-padding.rs:6:5
|
LL | std::intrinsics::raw_eq(&(1_u8, 2_u16), &(1_u8, 2_u16))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ reading 4 bytes of memory starting at alloc3, but 1 byte is uninitialized starting at alloc3+0x1, and this operation requires initialized memory
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ reading memory at alloc3[0x0..0x4], but memory is uninitialized at [0x1..0x2], and this operation requires initialized memory
Copy link
Member Author

Choose a reason for hiding this comment

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

Here I wasn't quite sure if we want the second range to repeat the alloc3 or not? It will always be the same allocation as for the first range.

Copy link
Contributor

Choose a reason for hiding this comment

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

nope, no repeating is better. I even stumbled over memory being mentioned twice, but just using it isn't better either, so let's just do this.

@oli-obk
Copy link
Contributor

oli-obk commented Jul 7, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Jul 7, 2022

📌 Commit 27b7b3d has been approved by oli-obk

@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 Jul 7, 2022
@RalfJung
Copy link
Member Author

RalfJung commented Jul 7, 2022

@bors rollup

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 7, 2022
interpret: use AllocRange in UninitByteAccess

also use nice new format string syntax in `interpret/error.rs`, and use the `#` flag to add `0x` prefixes where applicable.

r? `@oli-obk`
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 7, 2022
…askrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#97917 (Implement ExitCodeExt for Windows)
 - rust-lang#98844 (Reword comments and rename HIR visiting methods.)
 - rust-lang#98979 (interpret: use AllocRange in UninitByteAccess)
 - rust-lang#98986 (Fix missing word in comment)
 - rust-lang#98994 (replace process exit with more detailed exit in src/bootstrap/*.rs)
 - rust-lang#98995 (Add a test for rust-lang#80471)
 - rust-lang#99002 (suggest adding a derive for #[default] applied to variants)
 - rust-lang#99004 (Add a test for rust-lang#70408)
 - rust-lang#99017 (Replace boolean argument for print_where_clause with an enum to make code more clear)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 9064147 into rust-lang:master Jul 7, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jul 7, 2022
@RalfJung RalfJung deleted the more-alloc-range branch July 8, 2022 00:51
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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants