-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Deduplicate some code between miri and const prop #64419
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
cfd0efd
to
13bb10a
Compare
@bors r+ |
📌 Commit 13bb10a17c2572b0c5ecdda9aad4f792c300c28a has been approved by |
This comment has been minimized.
This comment has been minimized.
@bors r- |
13bb10a
to
0b333ef
Compare
Fixed by adding |
@bors r+ |
📌 Commit 0b333ef has been approved by |
…li-obk Deduplicate some code between miri and const prop r? @oli-obk
Failed in #64461 (comment), @bors r- |
I think I understand what's going on but not what to do about it:
|
Heh, that's a bug in the miri engine. The reason we never encountered it before (and never will in const eval) is that we have very few tests around the various ways to do UB in const eval. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=eaade80ea70ed29998b57c9aa11e4050 shows the ICE on stable. I'll open an issue and we'll fix it there. Until then... a possible workaround may be to remove variables of uninhabited type from the list of variables to const prop |
⌛ Testing commit dd486dd with merge ab3bd45112a1ac58136d4f6aa2cbcbf672450299... |
…li-obk Deduplicate some code between miri and const prop r? @oli-obk
@bors retry rolled up... (don't ask why...) |
⌛ Testing commit dd486dd with merge a6f3ffb269ab0e067c2df49e118a13fc037be236... |
dd486dd
to
ba2d6c4
Compare
I fixed the mir-opt test that was failing on the |
@bors r+ |
📌 Commit ba2d6c4 has been approved by |
@@ -1,3 +1,5 @@ | |||
// compile-flags: -O |
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.
Shouldn't this warn in debug mode too?
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.
@oli-obk Just in case this has been overlooked: we should always run the constant-folding pass and only commit the results when optimizations are enabled (although maybe we shouldn't care about optimization level at all?).
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's what we do, the differences arise because the MIR differs and thus different lints are reported
Deduplicate some code between miri and const prop r? @oli-obk
☀️ Test successful - checks-azure |
@@ -389,6 +389,10 @@ pub enum UnsupportedOpInfo<'tcx> { | |||
/// Free-form case. Only for errors that are never caught! | |||
Unsupported(String), | |||
|
|||
/// FIXME(#64506) Error used to work around accessing projections of | |||
/// uninhabited types. | |||
UninhabitedValue, |
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 "unsupported" the right category for this?
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.
To me, it seemed similar to some of the other "unsupported" cases like ReadForeignStatic
, NoMirFor
, DerefFunctionPointer
, OutOfTls
etc in that it represents allowed behavior in a valid program that simply isn't implemented (or can't be implemented) in miri. I dismissed InvalidProgramInfo
because this doesn't indicate an invalid program, however reading the doc comment, it sounds like that may actually be a more appropriate classification. Thoughts?
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.
Looks like @oli-obk is already working on removing this again so whatever.
frame.locals[local].access() | ||
} | ||
|
||
/// Called before a `StaticKind::Static` value is accessed. |
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.
Please specify what "access" means here. Is this called when the address of a static is taken? Or just on reads/writes?
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 will double check and improve the comment in the other open PR I have but I believe this is just on reads/writes.
@@ -132,7 +132,7 @@ impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> InterpCx<'mir, 'tcx, M> { | |||
/// | |||
/// There is no separate `eval_rvalue` function. Instead, the code for handling each rvalue | |||
/// type writes its results directly into the memory specified by the place. | |||
fn eval_rvalue_into_place( | |||
pub fn eval_rvalue_into_place( |
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.
Oh, why this? We're trying to keep a clean interface for the interpreter, that'll never work if everyone just adds pub
whenever they feel like 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.
Looking at the const_prop changes, it seems like what happened is that const_prop moved up a layer or two of the interpreter abstractions. Shouldn't that mean that while some new operations need to be public now, some of the previously used one can be made private? If you could scan the functions that const_prop no longer needs and make them private, that would make me much less concerned about this change. :)
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.
Shouldn't that mean that while some new operations need to be public now, some of the previously used one can be made private?
Yes, I think you're correct. I'll do that in the other PR as well.
r? @oli-obk