Using module_name or package_name with external types causes invalid code to be generated. about uniffi-rs

[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,