New system for remote / custom / external types #2087
Commits on May 23, 2024
-
Updating the docs for remote / custom / external types
As discussed in mozilla#1865, this is how I think we should update our code for remote / custom / external types: - Make remote types a first-class feature. - Make UDL generate blanket ffi trait impls for all UniFfiTags. Remove the `use_udl_*` since we don't need them anymore. - Add `use_remote_type!` to handle the one case where we do need to forward ffi traits impls to another crate's tag. - Use a macro to define custom types. - Update the UDL external syntax so that `[Extern]` can work with any type. Benefits are: - UDL and proc-macros will be consistent in their handling of UniFfiTag. - First-class remote types would enable things like using anyhow::Error in interfaces. - The custom type macro is easier for users to use then the current code. It allows us to hide the complexity of things like the `UniFffiTag`. - External types get a little less hacky. - 3rd party crates can provide built-in UniFFI support and implement the FFI traits for all their consumers.
-
This can be used from proc-macros to specify that an item is remote and therefore the FFI traits should only be implemnted for the local `UniFfiTag`. Added an example where this is used to use anyhow::Error in as your error type. Also added the `[Remote]` tag for UDL. It doesn't do anything yes because all UDL-based generation currently uses the local tag. I'm going to change that in the next commit though. Require that error types to implement `Display + Debug` rather than `Error`. For some reason `anyhow::Error` doesn't actually implement error.
-
Implemented the custom type system descibed in the new docs. This is working for single crates, but multi-crate setup is currently broken. It should start working again once we change how UDL generation handles UniFfiTag. Removed the nested-module-import fixture. The custom type code will no longer test it, since it's not using `UniffiCustomTypeConverter`. I couldn't think of a way to make it work again.
-
Make UDL generation implement FFI traits for all tags (mozilla#1865)
This means it works exactly like the proc-macro code which simplifies things significantly. Also, this fixes the ext-types fixture to work with types that are custom, remote, and external. Removed the `use_udl_*` macros, they're not needed anymore. Added the `remote_type!` macro, it's now needed for using remote types who's FFI trait impls are defined in another crate (which is now possible from using UDL and proc-macros) One feature that we've lost in defining callback/trait interfaces using traits defined in a remote crate. I doubt anyone is using that feature, but I think the plan should be to re-implement it before the next release. As part of the same work, I think we can also support methods on remote interfaces.
-
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.