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

Deprecate -Zmiri-allow-uninit-numbers? #2187

Closed
RalfJung opened this issue Jun 4, 2022 · 0 comments · Fixed by rust-lang/rust#100043
Closed

Deprecate -Zmiri-allow-uninit-numbers? #2187

RalfJung opened this issue Jun 4, 2022 · 0 comments · Fixed by rust-lang/rust#100043
Labels
A-interpreter Area: affects the core interpreter C-cleanup Category: cleaning up our code

Comments

@RalfJung
Copy link
Member

RalfJung commented Jun 4, 2022

I would love to deprecate the -Zmiri-allow-uninit-numbers flag some time later this year. Removing that flag would allow us to do some significant cleanup in the interpreter -- we could entirely remove the ScalarMaybeUninit type!

@RalfJung RalfJung added A-interpreter Area: affects the core interpreter C-cleanup Category: cleaning up our code labels Jun 5, 2022
bors added a commit that referenced this issue Jun 13, 2022
deprecate -Zmiri-allow-uninit-numbers and -Zmiri-allow-ptr-int-transmute

Cc #2187 #2188
bors added a commit that referenced this issue Jul 19, 2022
remove deprecated options

These have been deprecated a month ago and nobody said they need them. Is that enough time? We can also let this PR sit a little.

Cc #2187 #2188
(keeping them open to track removing their supporting infrastructure in the core interpreter)
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Aug 26, 2022
…-obk

interpret: remove support for uninitialized scalars

With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.

I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.

Fixes rust-lang/miri#2187
r? ``@oli-obk``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Aug 26, 2022
…-obk

interpret: remove support for uninitialized scalars

With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.

I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.

Fixes rust-lang/miri#2187
r? ```@oli-obk```
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Aug 26, 2022
…-obk

interpret: remove support for uninitialized scalars

With Miri no longer supporting `-Zmiri-allow-uninit-numbers`, we no longer need to support storing uninit data in a `Scalar`. We anyway already only use this representation for types with *initialized* `Scalar` layout (and we have to, due to partial initialization), so let's get rid of the `ScalarMaybeUninit` type entirely.

I tried to stage this into meaningful commits, but the one that changes `read_immediate` to always trigger UB on uninit is the largest chunk of the PR and I don't see how it could be subdivided.

Fixes rust-lang/miri#2187
r? ````@oli-obk````
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-interpreter Area: affects the core interpreter C-cleanup Category: cleaning up our code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant