This module provides an abstract representation of the interface provided by a UniFFI Rust Component, in high-level terms suitable for translation into target consumer languages such as Kotlin and Swift. It also provides facilities for parsing a WebIDL interface definition file into such a representation.
The entrypoint to this crate is the
ComponentInterface struct, which holds a complete definition
of the interface provided by a component, in two parts:
- The high-level consumer API, in terms of objects and records and methods and so-on
- The low-level FFI contract through which the foreign language code can call into Rust.
That’s really the key concept of this crate so it’s worth repeating: a
defines the shape and semantics of an interface between the Rust-based implementation of a component
and its foreign language consumers, including details like:
- The names of all symbols in the compiled object file
- The type and arity of all exported functions
- The layout and conventions used for all arguments and return types
If you have a dynamic library compiled from a Rust Component using this crate, and a foreign
language binding generated from the same
ComponentInterface using the same version of this
module, then there should be no opportunities for them to disagree on how the two sides should
General and incomplete TODO list for this thing:
It should prevent user error and the possibility of generating bad code by doing (at least) the following checks:
- No duplicate names (types, methods, args, etc)
- No shadowing of builtin names, or names we use in code generation We expect that if the user actually does one of these things, then they should get a compile error when trying to build the component, because the codegen will be invalid. But we can’t guarantee that there’s not some edge-case where it produces valid-but-incorrect code.
There is a lot of cloning going on, in the spirit of “first make it work”. There’s probably a good opportunity here for e.g. interned strings, but we’re nowhere near the point were we need that kind of optimization just yet.
Error messages and general developer experience leave a lot to be desired.
- Callback Interface definitions for a
- enum_ 🔒Enum definitions for a
- Low-level typesystem for the FFI layer of a component interface.
- function 🔒Function definitions for a
- object 🔒Object definitions for a
- record 🔒Record definitions for a
- The set of all
Types used in a component interface is represented by a
TypeUniverse, which can be used by the bindings generator code to determine what type-related helper functions to emit for a given component.
- Represents an argument to a function/constructor/method call.
- The main public interface for this module, representing the complete details of an interface exposed by a rust component and the details of consuming it via an extern-C FFI layer.
- Represents an enum with named variants, each of which may have named and typed fields.
- Represents a standalone function.
- An “object” is an opaque type that is passed around by reference, can have methods called on it, and so on - basically your classic Object Oriented Programming type of deal, except without elaborate inheritance hierarchies. Some can be instantiated.
- Represents a “data class” style object, for passing around complex values.
- Stateful iterator for yielding all types contained in a given type.
- Combines the return and throws type of a function/method
- Represents an individual variant in an Enum.
- Represents all the different high-level types that can be used in a component interface. At this level we identify user-defined types by name, without knowing any details of their internal structure apart from what type of thing they are (record, enum, etc).
- The list of traits we support generating helper methods for.
- Implemented by function-like types (Function, Method, Constructor)