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.
Attribute definitions for a
Callback Interface definitions for a
Enum definitions for a
Error definitions for a
Low-level typesystem for the FFI layer of a component interface.
Function definitions for a
Support for literal values.
Namespace definition for a
Object definitions for a
Record definitions for a
Basic typesystem for defining a component interface.
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 an Error that might be thrown by functions/methods in the component interface.
Represents a standalone function.
A namespace is currently just a name, but might hold more metadata about the component in future.
An “object” is an opaque type that can be instantiated and passed around by reference, have methods called on it, and so on - basically your classic Object Oriented Programming type of deal, except without elaborate inheritence hierarchies.
Represents a “data class” style object, for passing around complex values.
Stateful iterator for yielding all types contained in a given type.
Trait to help build a
ComponentInterface from WedIDL syntax nodes.
Trait to help convert WedIDL syntax nodes into