-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Shims ICE when a scalar argument isn't actually a scalar #3842
Comments
I think we want a new function like
|
Similar ICEs can occur when the return type of the function is wrong -- we end up calling If it is a ScalarPair, we can even end up writing things at wrong offsets. (But |
Can I look into this task? |
Definitely! However, this will require some design work. As mentioned in the issue description, we don't have a clear plan yet for how to best fix this issue. |
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.
made check_argument_compat public for use in miri Links to [issue](rust-lang/miri#3842) and it's [PR](rust-lang/miri#4185 (comment)) in miri.
Rollup merge of rust-lang#137056 - geetanshjuneja:pub, r=RalfJung made check_argument_compat public for use in miri Links to [issue](rust-lang/miri#3842) and it's [PR](rust-lang/miri#4185 (comment)) in miri.
For instance, consider:
I think to fix this properly we need to completely re-do the way we handle shim arguments: every
OpTy
needs to be transmuted to the right type before we do anything else with it. And we can't just just callOpTy::transmute
as that can't be used for arbitrary transmute, e.g. changing ABIs can fail spectacularly.Once this is consistently done everywhere, we can also remove the ScalarSizeMismatch error from the interpreter. This was added because otherwise ICEs can be triggered by using an incorrect scalar type in the signature of a function that has a Miri shim, but as we have seen, ICEs can still be triggered -- and once we use our own hard-coded types everywhere, ScalarSizeMismatch can no longer be triggered at all.
We probably want a macro that helps with that.
The text was updated successfully, but these errors were encountered: