You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We upgraded to the latest commit ref (c7c4809ed0e6bb9195b58855cc7cb211eac13290) (previously e796e00ad150f8b14b61a859a2e8c6497b35074e) and it seems that custom_type!() stopped working for us:
error[E0210]: type parameter `UT` must be used as the type parameter for some local type (e.g., `MyStruct<UT>`)
--> crates/yttrium/src/uniffi_compat.rs:25:1
|
25 | / uniffi::custom_type!(Address, String, {
26 | | try_lift: |val| Ok(val.parse()?),
27 | | lower: |obj| obj.to_string(),
28 | | });
| |__^ type parameter `UT` must be used as the type parameter for some local type
|
= note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local
= note: only traits defined in the current crate can be implemented for a type parameter
= note: this error originates in the macro `uniffi::custom_type` (in Nightly builds, run with -Z macro-backtrace for more info)
We are using the external crate's alloy::primitives::Address here, and lowering it to a string so it can be used on the Kotlin side easily as a string.
Do custom types no longer work in the latest version for remote types? Or is there possibly another reason for this error?
In our case, it would be convenient to continue lowering this to a string vs exposing a full Address type Kotlin-side requiring refactors.
The text was updated successfully, but these errors were encountered:
We upgraded to the latest commit ref (
c7c4809ed0e6bb9195b58855cc7cb211eac13290
) (previouslye796e00ad150f8b14b61a859a2e8c6497b35074e
) and it seems thatcustom_type!()
stopped working for us:We are using the external crate's
alloy::primitives::Address
here, and lowering it to a string so it can be used on the Kotlin side easily as a string.Do custom types no longer work in the latest version for remote types? Or is there possibly another reason for this error?
In our case, it would be convenient to continue lowering this to a string vs exposing a full
Address
type Kotlin-side requiring refactors.The text was updated successfully, but these errors were encountered: