Validate transmute in CTFE #144030
Validate transmute in CTFE #144030
Conversation
rustbot
added
S-waiting-on-review
|
@bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Validate transmute in CTFE fixes #142230 let's see what perf says, maybe we need to restrict it to literal transmutes, and not all the implicit ones happening in mir interpreter internal situations r? `@ghost`
rustbot
added
the
S-waiting-on-perf
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (e6b0b5d): comparison URL. Overall result: ❌ regressions - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.0%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.5%, secondary 348.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 464.891s -> 467.195s (0.50%) |
rustbot
added
perf-regression
oli-obk
force-pushed
the
validate-transmute
branch
from
d032919 to
1aa2951
Compare
|
Limited validation to explicit @bors2 try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Validate transmute in CTFE fixes #142230 let's see what perf says, maybe we need to restrict it to literal transmutes, and not all the implicit ones happening in mir interpreter internal situations r? `@ghost`
rustbot
added
the
S-waiting-on-perf
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (c41f0b4): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (secondary 2.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -12.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 463.571s -> 465.557s (0.43%) |
rustbot
removed
the
S-waiting-on-perf
|
yay. html5ever has a small regression in const eval, but everything else seems to be fine. @rust-lang/wg-const-eval what do you think about doing validation only for the result of |
RalfJung
left a comment
RalfJung
left a comment
There was a problem hiding this comment.
This doesn't fix the underlying problem that our errors during evaluation vs during validation are worded very differently... but yeah adding extra checks here sounds good, if we can do it in a way that doesn't affect Miri.
| // Even if general validation is disabled, transmutes should always check their result. | ||
| if !M::enforce_validity(self, dest.layout) { |
There was a problem hiding this comment.
Miri has a flag for disabling validity checking -- this code makes it not work properly any more.
So this still needs to be somehow controlled by the machine, with a way for the machine to entirely disable all validity checking. Maybe enforce_validity should return a 3-state enum?
There was a problem hiding this comment.
Hmm... I was just gonna add a const block for extra validation checks, but that may work, too
There was a problem hiding this comment.
This could also be inside copy_op_allow_transmute or rather copy_op_inner. The code there knows when source and target type differ.
|
☔ The latest upstream changes (presumably #144145) made this pull request unmergeable. Please resolve the merge conflicts. |
Dylan-DPC
added
S-experimental
oli-obk
force-pushed
the
validate-transmute
branch
from
1aa2951 to
2dcbaea
Compare
|
The Miri subtree was changed cc @rust-lang/miri |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
oli-obk
force-pushed
the
validate-transmute
branch
from
2dcbaea to
af11474
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
7 participants
fixes #142230
let's see what perf says, maybe we need to restrict it to literal transmutes, and not all the implicit ones happening in mir interpreter internal situations
r? @ghost