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.
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
[const-prop] Handle remaining MIR Rvalue cases #64890
[const-prop] Handle remaining MIR Rvalue cases #64890
Changes from all commits
c8f7e18
a2e3ed5
4d89031
2d22063
8cf6c23
b71ea80
fd20dbe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this still needed, with the new machine hook and the const_prop machine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The alloc_local hook runs too late to fix this ICE because miri calls
InterpCx::size_and_align_of()
before accessing the local which expectsmetadata
to have a value. So this is still necessary.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean
access_local
is not actually helping?Is there a way we could reorder things to avoid this? (I have no idea which call to
size_and_align_of
is the problematic one.)Either way, this should be explained in a comment the code, not just in the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
access_local
hook works around a different issue which is that we may try to load values from uninitialized locals. In const prop, this happens for a few different reasons but mostly related to this block hererust/src/librustc_mir/transform/const_prop.rs
Lines 625 to 645 in 53aca55
If we aren't allowed to const prop a local, it will
LocalValue::Uninitialized
whenConstPropMachine
tries to access it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. So which call to
size_and_align_of
is the one that is guarded by the check here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So that seems to come via this call:
rust/src/librustc_mir/interpret/step.rs
Line 244 in ea45150
That's odd though... we call
eval_place
before that so if it was a local,access_local
could actually throw an error to never reach the later part?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems to be because
eval_place()
doesn't callaccess_local()
.access_local()
returns anOperand
whicheval_place()
wouldn't use at all since it just returns aPlaceTy
. Maybe we could generalizeaccess_local()
to just do validation? Perhaps something like:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, we even have a comment there saying
Except for unsized locals it doesn't... or well it does but only to initialize them; in this stacktrace we are taking a reference to them.
"validate" in Miri already refers to this so let's avoid that term. But also, I don't think that would be right: when calling
eval_place
for thedest
, we are fine with uninitialized locals as we will write to them!What basically happens here is that const_prop causes the engine to take a reference to an uninitialized unsized value. That's impossible to implement (taking a reference needs an allocation in memory but to have one we need a size, which we cannot determine for an unsized uninitialized value). Maybe this check is indeed better than the possible alternatives (though it would be nice for the comment here to explain that).
The comment here talks about arguments that are fat pointers; is that correct? Fat pointers are also just sized data (twice as big as normal pointers) and shouldn't be a problem. Unsized arguments however are a problem, if my analysis is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks!
Your analysis is correct; it was early and I hadn't yet had coffee when I wrote "fat pointers". The ICE I linked to occurs when processing:
and specifically with the unsized
self
parameter.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good, I think we reached a conclusion here then. :) Would be good to have that documented in the code, but right now I don't see a good way to handle this inside the engine.
I am really not happy with our (Miri's) treatment of unsized locals in general, and this puts the finger on what doesn't work well...