-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Miri: avoid comparing layouts #70801
Conversation
(ty::Ref(_, src_pointee, _), ty::Ref(_, dest_pointee, _)) => { | ||
// After optimizations, there can be assignments that change reference mutability. | ||
// This does not affect reference layout, so that is fine. | ||
src_pointee == dest_pointee |
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 am slightly paranoid here about comparing the wrong thing (in an earlier version I accidentally compared mutabilities here instead of types, by using the wrong pattern). Is there any good way to assert that these things are types?
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.
You can probably use Ty::eq
to call the implementation of ==
, but idk if it looks pretty.
The other option is I guess ascription, i.e. (src_pointeee: Ty) == (dest_pointee: Ty)
.
That example is extremely complex, I can't follow it. It should be trivial to use subtyping: fn simple(x: for<'a> fn(&'a ())) -> fn(&'static ()) {
x
}
fn nested(x: (for<'a> fn(&'a ()), String)) -> (fn(&'static ()), String) {
x
} |
There's a trap you may have fallen into, looking again at your example: |
I tried to get around exactly that by adding the intermediate |
@eddyb ah, your |
This PR is definitely wrong then, closing. See #70804 for the issue. |
This is a follow-up to #70532.
r? @eddyb so I tried to find a case where the "subtyping on assignment" happens with a larger type, not just immediately with a function pointer. So far, I failed.
Here's my last attempt:
If such a case exists, the assertion here is still wrong (as the larger type might or might not be a
Scalar
/ScalarPair
). If such a case does not exist, the fully type-based check should actually work. Thus, this PR cannot actually make things any less correct. Am I missing something?