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.

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

External type fails for some corner cases #2121

Open
bendk opened this issue May 21, 2024 · 1 comment
Open

External type fails for some corner cases #2121

bendk opened this issue May 21, 2024 · 1 comment

Comments

@bendk
Copy link
Contributor

bendk commented May 21, 2024

It's tricky to get the FFI function signatures correct for external types since we don't know the concrete actual type. Here's where we determine the FFI type to use. I can think of at least 2 cases where this will fail:

  • A external custom type that wraps a primitive type. There's no way to represent that with ExternalKind
  • A "doubly external" type: crate1 defines a type, crate2 uses it as an external type, crate3 uses that type from crate2 as it's external type. In this case, the RustBuffer crate name will be wrong. This is a pretty weird case, but if we could support it it would be nice.

Now that the proc-macro metadata code has matured, I think we can fix both of these issues by:

  • Replacing ExternalKind with the actual type definition.
  • Making name refer to the crate that the type was originally defined in.
@mhammond
Copy link
Member

mhammond commented Jun 3, 2024

This is kinda #2025? I'm really starting to think we should rethink external types and insist on being able to resolve them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants