-
Notifications
You must be signed in to change notification settings - Fork 144
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
Allow value parameters to be passed by copy instead of consuming #766
Conversation
c6d13d9
to
8ffeddc
Compare
5181a32
to
42796d6
Compare
7599310
to
e3dae3e
Compare
e3dae3e
to
29e26f4
Compare
29e26f4
to
5148d9f
Compare
5148d9f
to
499ebb5
Compare
Prior to this point, a value parameter of a C++ function consumed a UniquePtr<T>. With this change, a value parameter is now of type impl ValueParam<T> which can be either a UniquePtr<T> (avoiding any compatibility break) or a &T or various other things.
These are failing on Windows only for unknown reasons and will be investigated in #819.
3a047ea
to
5ba4b6b
Compare
if this.param.needs_stack_space() { | ||
this.space = Some(MaybeUninit::uninit()); | ||
this.param | ||
.populate_stack_space(Pin::new_unchecked(this.space.as_mut().unwrap())); |
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.
What prevents this Rust object (which is the storage for a C++ object) from being memcpyed to a different address? Some of the tests fail for me after this PR, I think because of this.
With some additional prints, it looks like the drop
for ValueParamHandler
is definitely being called with a different address.
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.
Hmm, thanks, I will revert or fix this tomorrow.
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.
Part of #379.