Skip to content
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.

Sign up for GitHub

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

Jump to bottom

CxxVector<*mut Thing> #795

Open
adetaylor opened this issue Mar 29, 2021 · 3 comments · May be fixed by #1375
Open

CxxVector<*mut Thing> #795

adetaylor opened this issue Mar 29, 2021 · 3 comments · May be fixed by #1375
Labels
help wanted

Comments

@adetaylor
Copy link
Collaborator

I had a crack at implementing CxxVector<*mut T> and CxxVector<*const T> here:

master...adetaylor:ptr-vecs-wip

It didn't work out too well, (I think) because we try to impl ::cxx::private::VectorElement for *const BlobstoreClient and the orphan rule doesn't appear to allow us to do this.

error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
  --> demo/src/main.rs:26:33
   |
1  | #[cxx::bridge(namespace = "org::blobstore")]
   | -------------------------------------------- `*const BlobstoreClient` is not defined in the current crate
...
26 |                 fn foo(n: u64) -> UniquePtr<CxxVector<*const BlobstoreClient>>;
   |                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ impl doesn't use only types from inside the current crate
   |
   = note: define and implement a trait or new type instead

error: aborting due to previous error

For more information about this error, try `rustc --explain E0117`.

I may have the wrong idea for what went wrong here, but it looks like RFC1023 does indeed mention references but not pointers.

I'm unlikely to come back to this any time soon but thought I'd report my findings.
@dtolnay
Copy link
Owner

dtolnay commented Mar 29, 2021

I have not looked at your branch but naively I would expect to see:

// cxx crate
unsafe impl<T: MutPtrVectorElement> VectorElement for *mut T {}

// downstream crate
unsafe impl MutPtrVectorElement for Thing {}

Alternatively it's probably fine to assume std::vector<T*> has a consistent layout independent of T, and have just one impl instead of a generic one.

@adetaylor
Copy link
Collaborator Author

Thanks, that points me in the right direction.

@adetaylor adetaylor mentioned this issue Apr 1, 2021
Open
@adetaylor adetaylor mentioned this issue Jun 23, 2023
Closed
@makai410
Copy link

makai410 commented Sep 1, 2024 •
edited
Loading

I am considering writing structs like MutPtr<T> and ConstPtr<T> as bindings to T* and const T* to bypass the orphan rule. I am not sure if it's a good idea or if there are better ways to handle this.

@makai410 makai410 linked a pull request Sep 17, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support for CxxVector<*mut T> and CxxVector<*const T> makai410/cxx
3 participants
@adetaylor @dtolnay @makai410