-
Notifications
You must be signed in to change notification settings - Fork 231
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
uniffi::custom_newtype!(Newtype, u16)
gives Lift<UniFfiTag>
is not implemented for Newtype
#1988
Comments
uniffi::custom_newtype!
in crate a
gives Lift<UniFfiTag>
is not implemented for Newtype
in crate b
uniffi::custom_newtype!(Newtype, u16)
gives Lift<UniFfiTag>
is not implemented for Newtype
This is almost what's described at https://mozilla.github.io/uniffi-rs/proc_macro/index.html#types-from-dependent-crates, although I don't think this is supported for custom types. So I think the only path forward is to duplicate (or move) the |
Oh, are you suggesting that I do the macro invocation from the
Yeah, I think I agree with the non-global part. But I don't understand why this macro would do anything global? When I #[automatically_derived]
unsafe impl ::uniffi::FfiConverter<crate::UniFfiTag> for Newtype {
type FfiType = <u16 as ::uniffi::Lower<crate::UniFfiTag>>::FfiType;
fn lower(obj: Newtype) -> Self::FfiType {
<u16 as ::uniffi::Lower<
crate::UniFfiTag,
>>::lower(<Newtype as crate::UniffiCustomTypeConverter>::from_custom(obj))
}
// etc... That seems nice and local to me? Would this work better if I use UDL files instead? I've been hoping that I could do everything with proc macros, but if not, then I should abandon this for now. |
I probably misunderstood since I get an error when I try something like
pointing to the place where the |
Aha, I got it working! Using
in I first tried with I've only checked that this compiles with Rust — I don't know if it does something sensible in Kotlin or other languages 🙂 |
As a follow-up, Types from dependent crates gave me the impression that I don't need to do anything special when I depend on a proc-macro annotated type from a different crate. I got this impression from this sentence:
|
I've experimented some more and found that I now have a/src/lib.rs with: uniffi::setup_scaffolding!();
#[derive(Debug, uniffi::Object)]
pub struct Wrapper {
pub inner: String,
} and b/src/lib.rs with: uniffi::setup_scaffolding!();
#[uniffi::export]
pub fn use_wrapper(wrapper: a::Wrapper) {
println!("{wrapper:?}");
} Building
Adding uniffi::ffi_converter_forward!(a::Wrapper, a::UniFfiTag, crate::UniFfiTag); to b/src/lib.rs changes the error to
I found
I've been skimming different issues here and found #1865 where you discussed removing the |
Ah, just as I wrote this, I remembered that I saw something about using #[uniffi::export]
pub fn use_wrapper(wrapper: std::sync::Arc<a::Wrapper>) {
println!("{wrapper:?}");
} |
Yes this is local, which is why you're running into the issue. It's why
This is true for everything except custom types. The whole system is currently a bit of a mess, sorry that you're running into it.
Yup. I think the best solution for now is |
Hi @bendk, thanks for explaining!
It's alright — this still beats writing FFI by hand 😄 I'm so far having better luck with structs that have explicit fields (
It worked for the simple case I had here. I tried today with a newtype that wraps a |
On the latest release (0.27) this no longer works. I now get this error when using
Edit: I'm also getting the original error for record types. Edit2: I'll submit an example MR tomorrow morning with the issue in question. |
My apologies for the noise but it appears the issue was related to mixing to different versions of uniffi. One of the crates was not inheriting the workspace definitions. |
Hi @LBeernaertProton, just in case it helps you further: I've stopped trying to export types across crates like this. Instead, I'm now writing a thing wrapper API with UniFFI-compatible types. |
@mgeisler If you have time, could you give an example of this thing wrapper API? It would be useful for many who get stuck when trying to export types from dependency crates. |
Sure! The wrapper I've been created lives here: https://github.com/awslabs/mls-rs/blob/main/mls-rs-uniffi/src/lib.rs It's a separate crate for a two main reasons:
|
@mgeisler I have some use cases where I need to share Uniffi records from other crates. This would save me an extra step of converting a |
Hello!
I've been poking around at UniFFI for a few days and I really like what I see: the ability to automatically generate high-level APIs is amazing.
However, I think I've found a small bug. I have two crates,
a
andb
. Thea
crate defines a newtype which I hope to use fromb
:a/src/lib.rs:
b/src/lib.rs:
This fails with
It took me a while to spot the difference! 😄 The
Newtype
implementsLift<a::UniFfiTag>
but notLift<b::UniFfiTag>
.I'm not understanding the details of how the
UniFfiTag
struct is supposed to work, but I hope the above is more clear to someone here.The
Cargo.toml
files are nearly identical, but the one forb
has a path reference toa
:The text was updated successfully, but these errors were encountered: