-
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
Allow Rust traits to be exposed as an interface. #1457
Conversation
939624b
to
b62138a
Compare
b62138a
to
16f6b52
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool and I'm excited to start using it.
I think there's one FfiConverter
issue to figure out before we can merge this, but everything else looks good to me.
uniffi_bindgen/src/interface/mod.rs
Outdated
@@ -999,7 +1007,12 @@ fn convert_type(s: &uniffi_meta::Type) -> Type { | |||
convert_type(key_type).into(), | |||
convert_type(value_type).into(), | |||
), | |||
Ty::ArcObject { object_name } => Type::Object(object_name.clone()), | |||
Ty::ArcObject { object_name } => Type::Object { | |||
// XXX - needs love for traits and associated types. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this comment line be removed?
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Removed the blanket `Arc<T>` impl from `uniffi_core` and made it so we invoke a macro for each interface. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * Removing the blanket `Arc<T>` implementation allows us to customize the `FfiConverter` code for each interface. I think this makes mozilla#1457 easier. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs and add some features to them.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Removed the blanket `Arc<T>` impl from `uniffi_core` and made it so we invoke a macro for each interface. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * Removing the blanket `Arc<T>` implementation allows us to customize the `FfiConverter` code for each interface. I think this makes mozilla#1457 easier. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs and add some features to them.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
* Split out the proc-macro code to generate `FfiConverter` implementations and added standalone macros for that. * Removed the `FfiConverter` implementations from the Askama template code. Instead, the templates now invoke the macros. * Made the blanket `Arc<T>` impl in `uniffi_core` depend on a separate `Interface` trait that gets defined by macros. * Added attribute to generate a `try_lift` method for flat errors. This is required to support callback interface errors. The reason for this is: * I want to add some more functionality to `FfiConverter`, but don't want to implement it twice and test it two different ways. * The Interface trait allows us to customize the `Arc<T>` implementation. I plan to push some code that takes advantage of this and I also think it could be useful for mozilla#1457. * Everything goes through one code path, which should give us some more confidence as we migrate to proc-macros. This change caused me to fix some bugs with the macro-code and add some features.
b93fcb4
to
d44dc2c
Compare
This seems so so close -
Which confuses me. Out of time for today, but if anyone has a clue please share it with me :) |
37431e7
to
edf92de
Compare
f73f4bc
to
0dec0a6
Compare
So this all works and now uses a macro to implement FfiConverter - however, it's a bit different from how objects are done and I haven't even tried to support traits with proc-macros yet as I still need to understand how that works for structs! But it does seem to be in a fairly good place. |
dcf9e41
to
b77c626
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great to me. I left a couple of small bikeshedding comments, but nothing big. I'd be happy to merge this as-is.
b380a52
to
73f2428
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready to roll! Ben already approved it, but I think it's worth taking another look given the number of changes which happened underneath me since the last version.
/// an object with the given name. | ||
/// Includes `r#`, traits get a leading `dyn`. If we ever supported associated types, then | ||
/// this would also include them. | ||
pub fn rust_name_for(&self, name: &str) -> String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems oddly named and vaguely mis-placed, but all other names and places seem worse :)
0870081
to
fdd8f1d
Compare
This PR allows Rust traits to be exposed as interfaces, including when they have associated types. It supersedes #1308 (the memory leaks discussed there were easy to resolve once the other shoe dropped for me)
Instead of repeating what I hope are comprehensive docs and tests, please see the docs for this, see the new example (and the coveralls fixture exercises them quite thoroughly).
It has required zero changes to the generated bindings and it all fell out quite cleanly IMO. I've also got a POC in application-services for my specific use-case there, and it works perfectly!