Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd lifetimes for Handle and MutableHandle #393
Conversation
|
This will require some updates to the unit tests, too. |
|
This is exciting work! There are some cases where it's really easy to create 'static lifetimes that I'd like to see if we could avoid, though. |
| @@ -180,7 +181,7 @@ fn clamp_to<D>(d: f64) -> D | |||
| // https://heycam.github.io/webidl/#es-void | |||
| impl ToJSValConvertible for () { | |||
| #[inline] | |||
| unsafe fn to_jsval(&self, _cx: *mut JSContext, rval: MutableHandleValue) { | |||
| unsafe fn to_jsval(&self, _cx: *mut JSContext, mut rval: MutableHandleValue) { | |||
This comment has been minimized.
This comment has been minimized.
jdm
Mar 5, 2018
Member
We should modify the ToJSValConvertible trait to accept a lifetime argument and use it for the rval argument.
| } | ||
| // REVIEW: is this equivalent to? | ||
| // pub fn handle(&self) -> Handle<T> | ||
| pub fn handle(&'a self) -> Handle<'a, T> { |
This comment has been minimized.
This comment has been minimized.
| RawMutableHandle::from_marked_location(ptr).into() | ||
| } | ||
|
|
||
| pub fn handle(&self) -> RawHandle<T> { |
This comment has been minimized.
This comment has been minimized.
| @@ -853,9 +984,9 @@ impl<T: GCMethods + Copy> Heap<T> { | |||
| self.ptr.get() | |||
| } | |||
|
|
|||
| pub fn handle(&self) -> Handle<T> { | |||
| pub fn handle(&self) -> RawHandle<T> { | |||
This comment has been minimized.
This comment has been minimized.
jdm
Mar 5, 2018
Member
We should definitely return a non-raw Handle here, and return a MutableHandle from handle_mut that is not using the 'static lifetime.
This comment has been minimized.
This comment has been minimized.
marmistrz
Mar 12, 2018
Author
Contributor
Are you sure that it's not using the 'static lifetime now? I'm not so sure of it.
This comment has been minimized.
This comment has been minimized.
jdm
Mar 12, 2018
Member
I'm not even sure which code is being referred to any more. I believe that any code with a &self argument that returns a Handle will have the lifetime inferred to match the self argument, but it would be valuable to write that out explicitly.
| } | ||
| } | ||
| } | ||
|
|
||
| impl<'a> HandleValue<'a> { | ||
| pub fn null() -> Self { |
This comment has been minimized.
This comment has been minimized.
| } | ||
| } | ||
|
|
||
| impl<'a, T> From<RawMutableHandle<T>> for MutableHandle<'a, T> { |
This comment has been minimized.
This comment has been minimized.
jdm
Mar 5, 2018
Member
How important are the From<Raw> impls for the safe handles? It makes me uncomfortable that we can create safe handles with 'static lifetimes from arbitrary handles that do not actually have static lifetimes.
This comment has been minimized.
This comment has been minimized.
| Handle { ptr: ptr } | ||
| } | ||
|
|
||
| pub unsafe fn from_marked_location(ptr: *const T) -> Self { |
This comment has been minimized.
This comment has been minimized.
jdm
Mar 5, 2018
Member
Is this used outside of this crate? If we could avoid making it public, that would be useful.
|
Honestly, I don't really have an idea what we could test here. That's just mimicking the Handle's behavior, all the checks are done by the compiler. |
|
We could write some compile_fail doctests that demonstrate that handle values with lifetimes can't outlive the objects from which they were obtained. |
|
|
|
Oh, and to be clear when I said "updates to the unit tests", I was specifically referring to the fact that they do not compile any longer according to TravisCI :) |
…reak servo
|
The changes here look good to me as long as we can make Servo build with them before merging them. |
|
|
| @@ -0,0 +1,17 @@ | |||
| #!/bin/sh | |||
| # This is one big heuristic but seems to work well enough | |||
This comment has been minimized.
This comment has been minimized.
jdm
Mar 23, 2018
•
Member
This is a clever solution! Let's add documentation like the following:
The script extracts a list of all the JSAPI functions that accept FFI Handle and MutableHandle arguments.
|
@jdm Could some macros guru to review my macro? The macro rule duplication here is atrocious but I don't know if the macro system allows for anything more than copy paste. |
| @@ -238,7 +239,7 @@ unsafe fn convert_int_from_jsval<T, M>(cx: *mut JSContext, value: HandleValue, | |||
| // https://heycam.github.io/webidl/#es-boolean | |||
| impl ToJSValConvertible for bool { | |||
| #[inline] | |||
| unsafe fn to_jsval(&self, _cx: *mut JSContext, rval: MutableHandleValue) { | |||
| unsafe fn to_jsval(&self, _cx: *mut JSContext, mut rval: MutableHandleValue) { | |||
This comment has been minimized.
This comment has been minimized.
| wrap!(@inner $saved <> ($($acc,)* $arg,) <> $($rest)*); | ||
| }; | ||
| (@inner ($func_name:ident ($($args:tt)*) -> $outtype:ty) <> ($($argexprs:expr,)*) <> ) => { | ||
| pub unsafe fn $func_name($($args)*) -> $outtype { |
This comment has been minimized.
This comment has been minimized.
| use libc::FILE; | ||
| use super::{Handle, HandleId, HandleObject, HandleValue}; | ||
| use super::{MutableHandle, MutableHandleObject, MutableHandleValue}; | ||
| include!("jsapi_wrappers.rs"); |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| wrap!(pub fn $func_name($($args)*) -> ()); | ||
| } | ||
| } | ||
| pub mod wrappers { |
This comment has been minimized.
This comment has been minimized.
jdm
Mar 23, 2018
•
Member
Let's add documentation like:
Wrappers for JSAPI methods that accept FFI Handle and MutableHandle arguments. The new methods are identical except that they accept Handle and MutableHandle arguments that include lifetimes instead.
This comment has been minimized.
This comment has been minimized.
marmistrz
Mar 23, 2018
Author
Contributor
You mean:
Wrappers for JSAPI methods that accept lifetimed Handle and MutableHandle arguments.
?
This comment has been minimized.
This comment has been minimized.
|
@marmistrz AFAICT skimming through that macro, the only way to require less clauses is to unconditionally transform all arguments, as opposed to just the ones with |
|
|
|
Hmm, Unbox seems to be a platform-specific function for some reason:
|
|
@bors-servo r+ |
|
|
Add lifetimes for Handle and MutableHandle Servo compiled fine for me with the following patch set. Since the `From` trait consumes the object, I created a `raw` method for `MutableHandle`. This is not ideal, since `into()` would be more idiomatic. Is there anything better I could do or should I just leave it as it is? There are two questions marked with `// REVIEW` since I'm not sure if the explicit lifetimes are the same what compiler inferred. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-mozjs/393) <!-- Reviewable:end -->
|
|
Remove stray comments asking for review :) They were introduced by #393 and meant to be removed once the questions had been answered - but they ended up merged. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/rust-mozjs/421) <!-- Reviewable:end -->
Our current wrappers held in rust::wrappers accept the Handles by consume/Copy. This was introduced in servo#393 to make it feasible to migrate the API calls on the Servo side in finite time. This, in particular, requires unsafe code in the implementation of MutableHandle. This change introduces a second set of wrappers, which will now borrow MutableHandles instead of relying on impl Copy for MutableHandle. The Servo code should gradually move to the new wrappers, rust::jsapi_wrapped, so that we can eventually remove rust::wrappers.
marmistrz commentedMar 4, 2018
•
edited
Servo compiled fine for me with the following patch set.
Since the
Fromtrait consumes the object, I created arawmethod forMutableHandle. This is not ideal, sinceinto()would be more idiomatic. Is there anything better I could do or should I just leave it as it is?There are two questions marked with
// REVIEWsince I'm not sure if the explicit lifetimes are the same what compiler inferred.Closes #153.
This change is