Mark Hammond

The problem is that the functions in `uniffi_one` are still exported by uniffi - ie, the function `get_uniffi_one_async()` is exposed in the generated code, so the type must be too....

I think I understand what confused me before. In my example above, the code generated for the top-level module (imported_types_lib.kt in that example) does not contain a reference to `LocalType`,...

It describes what you need, but doesn't seem particularly actionable. It seems worth digging in a little more to work out the actual characteristics and how features don't quite do...

All that said though, I guess I can't see why it shouldn't be possible to generate only what's "reachable", which should be possible to determine once the entire CI is...

Sorry about the above and being somewhat dismissive - I'm not sure how I convinced myself it's not actionable nor an issue :( I'll open one and we'll track it...

It sounds like uniffi_bindgen can't find metadata for your "crate_error_codes" - how exactly are you running the bindgen? In this scenario we'd expect you to be passing it a .a...

I'm afraid I don't know much about cargo swift, but in general, UniFFI will need to know about both crates when generating bindings. It's probably not possible to generate the...

The problem in this case is that UniFFI knows there is a UDL in crate_error_codes, but it can't locate it. By default we use cargo_metadata to locate the source code...

Did you try running the .exe installer? I suspect that the pywin32_postinstall.py script hasn't been run in an elevated environment, which the .exe installer will do automatically.

> (@bendk [asked me to create an issue](https://github.com/mozilla/uniffi-rs/pull/2087#issuecomment-2166132975) ) > > Following up on [my comment in 2087](https://github.com/mozilla/uniffi-rs/pull/2087#issuecomment-2128711332), using UniFFI with a Workspace works well in the **land of Rust**...