Custom Types from external crate do not generate correct binding function signature when used in exports

[LBeernaertProton]

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:

pub struct MyType(u64);

uniffi::custom_new_type(MyType,u64);

#[uniffi::export]
pub fn crate_a_test(t:MyType); 

Crate B:

use crate_a::MyType;

// Due to #1988
uniffi::ffi_converter_forward(crate_a::MyType, crate_a::UniFfiTtag, crate::UniFiiTag);

#[uniffi::export]
pub fn crate_b_test(t:MyType); 

Crate A will generate the following function signature:

uniffi_crate_a_fn_crate_a_test(uin64 t);

Where as Crate B will generate:

uniffi_crate_b_fn_crate_b_test(RustBuffer t);

I'm happy to assist in resolving this issue if someone can provide me some pointers on where this is handled in the code.

[mhammond]

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?

[LBeernaertProton]

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 String work without issues since these always translate down to a binding function that needs a RustBuffer.

[mhammond]

That being said, custom new types that are more "complex" such as String work without issues

Ah, yeah - I can reproduce this, thanks.

[mhammond]

a30a67f is a repro, but I suspect this will be very difficult to fix?

[LBeernaertProton]

I am afraid that at this point in time I can not answer that question 😅

[mhammond]

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 :)

[bendk]

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.

[mhammond]

I think it means updating the ExternalKind enum to also include primitive types

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 u64.