-
Notifications
You must be signed in to change notification settings - Fork 214
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
Custom Types from external crate do not generate correct binding function signature when used in exports #2025
Comments
This is a little unfortunate, but IIUC is just a side-effect of external types. All generated callers to these should do the right thing. What problems are you seeing because of this? |
The main issue I am having is that, I can not export uniffi functions that use external new types such as the example above that wrap scalar/basic types such as integers. We are currently working around this by just exposing the wrapped type to the bindings and internally converting it to the new type. That being said, custom new types that are more "complex" such as |
Ah, yeah - I can reproduce this, thanks. |
a30a67f is a repro, but I suspect this will be very difficult to fix? |
I am afraid that at this point in time I can not answer that question 😅 |
lol, sorry, it wasn't a question for you - it was more a statement of my understanding of the situation, with a glimmer of questioning that @bendk might see something I missed :) |
I think it means updating the ExternalKind enum to also include primitive types and then wiring up the rest of the code to generate/handle those variants. I'd estimate that as difficult, but doable. |
What I don't understand here is how the "importing" code can know what the primitive type is, unless we come up with another special declaration in that importing crate - which IMO would not really be OK - it shouldn't be necessary for that importing crate to know that a particular name is actually a custom type backed buy a |
Tested with uniffi v0.26.1.
When using custom types declared in another crate, the generated uniffi binding code does not generate the correct function signature for the bindings. This may be potentially related to #1988. I have verified this happens with the Swift binding generator, but could also affect other languages
Example
Crate A:
Crate B:
Crate A will generate the following function signature:
Where as Crate B will generate:
I'm happy to assist in resolving this issue if someone can provide me some pointers on where this is handled in the code.
The text was updated successfully, but these errors were encountered: