interpret: add sanity check in dyn upcast to double-check what codegen does #127856
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
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri The Miri subtree was changed cc @rust-lang/miri |
RalfJung
changed the title
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
interpret-cast-sanity
branch
from
dc7e6f9
to
b53180f
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
interpret-cast-sanity
branch
from
b53180f
to
a81ab4a
Compare
This comment has been minimized.
This comment has been minimized.
RalfJung
force-pushed
the
interpret-cast-sanity
branch
from
a81ab4a
to
a7b8081
Compare
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jul 19, 2024
…oli-obk interpret: add sanity check in dyn upcast to double-check what codegen does For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.) This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path. r? `@oli-obk`
This was referenced Jul 19, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 19, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#112328 (Feat. adding ext that returns change_time) - rust-lang#126199 (Add `isqrt` to `NonZero<uN>`) - rust-lang#127856 (interpret: add sanity check in dyn upcast to double-check what codegen does) - rust-lang#127934 (Improve error when a compiler/library build fails in `checktools.sh`) - rust-lang#127960 (Cleanup dll/exe filename calculations in `run_make_support`) - rust-lang#127963 (Fix display of logo "border") - rust-lang#127967 (Disable run-make/split-debuginfo test for RISC-V 64) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jul 19, 2024
Rollup merge of rust-lang#127856 - RalfJung:interpret-cast-sanity, r=oli-obk interpret: add sanity check in dyn upcast to double-check what codegen does For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.) This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path. r? ``@oli-obk``
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.
For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.)
This PR does the same for dyn trait upcasts. However, for casts not using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path.
r? @oli-obk