Using module_name or package_name with external types causes invalid code to be generated.

[LBeernaertProton]

Tested on uniffi v0.26.1 with proc macros

The issues below can be reproduced by having a target library (final product) which uses external types exported in by dependent crates.

Swift

When setting module_name in uniffi.toml for the target crate the bindings generated for swift only include the glue code produced by uniffi. All the exported types from the current and external crates are missing.

Kotlin

When setting package_name for the target crate the bindings generated for kotlin do not compile and they have a mixture of Redeclartion and Unresolved Reference errors for all the ffi functions.

E.g:

Redeclaration: RustBuffer,
Redeclaration: Usize 
Redeclaration: UniffiLib 
Redeclaration: FfiConverterULong

Type mismatch: inferred type is Unit but RustBuffer.ByValue was expected

Unresolved reference: uniffi_<TARGET_CRATE>_fn_func_<FUNCTION_NAME>

[mhammond]

I don't quite understand this report. We do have some tests which use external types, so it would be ideal if you can reproduce this problem in our https://github.com/mozilla/uniffi-rs/tree/main/fixtures/ext-types test - that will both help explain the report and give us the start of a test-case for any fix.

[LBeernaertProton]

The gist of it is if package_name or module_name are set in the uniffi binding config file in library mode with proc macros does not generate working bindings.

When I have time I'll produce a pull request with an example case.

[LBeernaertProton]

I have pushed and example to my fork.

Generate the bindings with library mode in the lib_main crate

cargo build
uniffi-bindgen generate --library ../../../target/debug/liblib_main.so --config uniffi.toml --language swift --out-dir ./tmp/swift
uniffi-bindgen generate --library ../../../target/debug/liblib_main.so --config uniffi.toml --language kotlin --out-dir ./tmp/kotlin

Observe that the swift bindings do not have any of the exported types and that the kotlin code has compilation issues.

[mhammond]

Your fork adds new crates and no tests - you will find all these types already exist in that ext-types fixture and it has tests. It's likely your uniffi.toml configs aren't quite correct, but you will need to be a little more concrete with the exact problem for us to help.

[mhammond]

(eg,

uniffi-rs/fixtures/ext-types/lib/src/lib.rs

Line 5 in fa0d0fd

use ext_types_guid::Guid;

is a custom type imported into another crate)

[LBeernaertProton]

Thanks for that, I am a bit busy this week, but I will try to adapt that example next week,