| callbacks.rs |
# Callback Interface definitions for a `ComponentInterface`.
This module converts callback interface definitions from UDL into structures that
can be added to a `ComponentInterface`. A declaration in the UDL like this:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
callback interface Example {
string hello();
};
# "##, "crate_name")?;
# Ok::<(), anyhow::Error>(())
```
Will result in a [`CallbackInterface`] member being added to the resulting
[`crate::ComponentInterface`]:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
# callback interface Example {
# string hello();
# };
# "##, "crate_name")?;
let callback = ci.get_callback_interface_definition("Example").unwrap();
assert_eq!(callback.name(), "Example");
assert_eq!(callback.methods()[0].name(), "hello");
# Ok::<(), anyhow::Error>(())
``` |
11188 |
| enum_.rs |
|
24251 |
| ffi.rs |
# Low-level typesystem for the FFI layer of a component interface.
This module provides the "FFI-level" typesystem of a UniFFI Rust Component, that is,
the C-style functions and structs and primitive datatypes that are used to interface
between the Rust component code and the foreign-language bindings.
These types are purely an implementation detail of UniFFI, so consumers shouldn't
need to know about them. But as a developer working on UniFFI itself, you're likely
to spend a lot of time thinking about how these low-level types are used to represent
the higher-level "interface types" from the [`Type`] enum. |
14202 |
| function.rs |
# Function definitions for a `ComponentInterface`.
This module converts function definitions from UDL into structures that
can be added to a `ComponentInterface`. A declaration in the UDL like this:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
namespace example {
string hello();
};
# "##, "crate_name")?;
# Ok::<(), anyhow::Error>(())
```
Will result in a [`Function`] member being added to the resulting [`crate::ComponentInterface`]:
```
# use uniffi_bindgen::interface::Type;
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {
# string hello();
# };
# "##, "crate_name")?;
let func = ci.get_function_definition("hello").unwrap();
assert_eq!(func.name(), "hello");
assert!(matches!(func.return_type(), Some(Type::String)));
assert_eq!(func.arguments().len(), 0);
# Ok::<(), anyhow::Error>(())
``` |
13006 |
| mod.rs |
# Component Interface Definition.
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 `ComponentInterface` completely
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
interact.
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. |
56988 |
| object.rs |
# Object definitions for a `ComponentInterface`.
This module converts "interface" definitions from UDL into [`Object`] structures
that can be added to a `ComponentInterface`, which are the main way we define stateful
objects with behaviour for a UniFFI Rust Component. An [`Object`] is an opaque handle
to some state on which methods can be invoked.
(The terminology mismatch between "interface" and "object" is a historical artifact of
this tool prior to committing to WebIDL syntax).
A declaration in the UDL like this:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
interface Example {
constructor(string? name);
string my_name();
};
# "##, "crate_name")?;
# Ok::<(), anyhow::Error>(())
```
Will result in an [`Object`] member with one [`Constructor`] and one [`Method`] being added
to the resulting [`crate::ComponentInterface`]:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
# interface Example {
# constructor(string? name);
# string my_name();
# };
# "##, "crate_name")?;
let obj = ci.get_object_definition("Example").unwrap();
assert_eq!(obj.name(), "Example");
assert_eq!(obj.constructors().len(), 1);
assert_eq!(obj.constructors()[0].arguments()[0].name(), "name");
assert_eq!(obj.methods().len(),1 );
assert_eq!(obj.methods()[0].name(), "my_name");
# Ok::<(), anyhow::Error>(())
```
It's not necessary for all interfaces to have constructors.
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
# interface Example {};
# "##, "crate_name")?;
let obj = ci.get_object_definition("Example").unwrap();
assert_eq!(obj.name(), "Example");
assert_eq!(obj.constructors().len(), 0);
# Ok::<(), anyhow::Error>(())
``` |
31948 |
| record.rs |
# Record definitions for a `ComponentInterface`.
This module converts "dictionary" definitions from UDL into [`Record`] structures
that can be added to a `ComponentInterface`, which are the main way we define structured
data types for a UniFFI Rust Component. A [`Record`] has a fixed set of named fields,
each of a specific type.
(The terminology mismatch between "dictionary" and "record" is a historical artifact
due to this tool being loosely inspired by WebAssembly Interface Types, which used
the term "record" for this sort of data).
A declaration in the UDL like this:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
dictionary Example {
string name;
u32 value;
};
# "##, "crate_name")?;
# Ok::<(), anyhow::Error>(())
```
Will result in a [`Record`] member with two [`Field`]s being added to the resulting
[`crate::ComponentInterface`]:
```
# let ci = uniffi_bindgen::interface::ComponentInterface::from_webidl(r##"
# namespace example {};
# dictionary Example {
# string name;
# u32 value;
# };
# "##, "crate_name")?;
let record = ci.get_record_definition("Example").unwrap();
assert_eq!(record.name(), "Example");
assert_eq!(record.fields()[0].name(), "name");
assert_eq!(record.fields()[1].name(), "value");
# Ok::<(), anyhow::Error>(())
``` |
8928 |
| universe.rs |
The set of all [`Type`]s 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.
|
4770 |
| visit_mut.rs |
|
5554 |