-
Notifications
You must be signed in to change notification settings - Fork 340
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
How to reuse an opaque Rust type across bridges? #942
Comments
It should work if you handwrite the // add to src/handle.rs
+ use cxx::{type_id, ExternType};
+
+ unsafe impl ExternType for Process {
+ type Id = type_id!("zx::ffi::Process");
+ type Kind = cxx::kind::Opaque;
+ } // add to src/main.rs
mod ffi {
+ #[namespace = "zx::ffi"]
+ extern "C++" {
+ include!("cxx-handles-demo/src/handle.rs.h");
+
+ type Process = crate::handle::Process;
+ } |
Kudos to @dtolnay for providing the solution in dtolnay/cxx#942 (and, indeed, for providing the entire cxx crate :)
Yup, that works; thanks! The docs for |
Yeah you're right. |
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
Discovered that we can use `Pin<&mut ...>` to allow mutation of Rust types defined in another cxx bridge module, based on: - https://cxx.rs/extern-c++.html#opaque-c-types > Unlike extern Rust types and shared types, an extern C++ type is not > permitted to be passed by plain mutable reference &mut MyType across the > FFI bridge. For mutation support, the bridge is required to use Pin<&mut > MyType>. This is to safeguard against things like mem::swap-ing the > contents of two mutable references, given that Rust doesn't have > information about the size of the underlying object and couldn't invoke > an appropriate C++ move constructor anyway. - dtolnay/cxx#942
I've got a situation similar to #465, yet a bit different.
Suppose I have a module that produces a certain resource. The resource is represented by an opaque Rust type:
I also have a module that can act on that resource (this doesn't compile):
The idea is to use it on the C++ side like this:
The error I'm getting is:
If I apply the trick from #465, I get an error that
Process
doesn't implement theExternType
trait (which makes sense, because that type comes from Rust, so it's not external to Rust).The end-goal is the same as in #465: I want to define a bridged type once, and re-use it in many different bridges. I do see a few issues that mention sharing and opaque types, but none of them seem to fit this particular situation.
The text was updated successfully, but these errors were encountered: