adjust Miri to Pointer type overhaul #1851
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RalfJung
force-pushed
the
provenance-overhaul
branch
from
25da527
to
3132d62
Compare
RalfJung
force-pushed
the
provenance-overhaul
branch
2 times, most recently
from
3efb5aa
to
b96b922
Compare
RalfJung
force-pushed
the
provenance-overhaul
branch
from
b96b922
to
a1233a7
Compare
|
I think the only user-visible change of this (aside from ptr-to-int casts working in a few more places) is more accurate overflow detection for pointer arithmetic. I will try to craft some testcases for that. |
|
Hm, I actually can't think of an overflow test that would error now where it passed before, or vice versa... we just get more accurate error messages now, which is already reflected in some of the test changes (but I might add one or two more). |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 17, 2021
…oli-obk CTFE/Miri engine Pointer type overhaul This fixes the long-standing problem that we are using `Scalar` as a type to represent pointers that might be integer values (since they point to a ZST). The main problem is that with int-to-ptr casts, there are multiple ways to represent the same pointer as a `Scalar` and it is unclear if "normalization" (i.e., the cast) already happened or not. This leads to ugly methods like `force_mplace_ptr` and `force_op_ptr`. Another problem this solves is that in Miri, it would make a lot more sense to have the `Pointer::offset` field represent the full absolute address (instead of being relative to the `AllocId`). This means we can do ptr-to-int casts without access to any machine state, and it means that the overflow checks on pointer arithmetic are (finally!) accurate. To solve this, the `Pointer` type is made entirely parametric over the provenance, so that we can use `Pointer<AllocId>` inside `Scalar` but use `Pointer<Option<AllocId>>` when accessing memory (where `None` represents the case that we could not figure out an `AllocId`; in that case the `offset` is an absolute address). Moreover, the `Provenance` trait determines if a pointer with a given provenance can be cast to an integer by simply dropping the provenance. I hope this can be read commit-by-commit, but the first commit does the bulk of the work. It introduces some FIXMEs that are resolved later. Fixes rust-lang/miri#841 Miri PR: rust-lang/miri#1851 r? `@oli-obk`
|
@bors r+ |
|
📌 Commit 0d65d50 has been approved by |
|
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the Miri side of rust-lang/rust#87123.
This was a lot more work than I expected... lucky enough it is also (hopefully) the last large-scale refactoring I will do.^^
Fixes #224