Translate the Wasm CM world into the IR Module. Since a non-trivial Wasm component has a complex nested architecture (see basic-wallet example that has 3 components, 4 component instances, 3 core modules and 5 core module instances) it makes sense for the frontend to encapsulate all this complexity and inline everything to produce a single IR Module.
The Wasm CM export and import top-level directives + canonical definitions (canon) to be translated and stored in the IR Module for every imported(external) and exported IR module function.
Here is how the IR Type variants for list and variant might look like:
pub enum Type {
...
/// An enum variant type
Variant(VariantType),
/// A list of values of the same type
List(Box<Type>),
}
/// Variants are close to Rust `enum` declarations where a value is one of many
/// cases and each case has a unique name and an optional payload associated
/// with it.
#[derive(Clone, Hash, Eq, PartialEq, Debug)]
pub struct VariantType {
/// The representation to use for this type
pub(crate) repr: TypeRepr,
/// The computed size of this struct
pub(crate) size: u32,
/// The list of cases that this variant can take.
pub cases: Box<[VariantCase]>,
}
/// One case of a `variant` type which contains the name of the variant as well
/// as the payload.
#[derive(Clone, Hash, Eq, PartialEq, Debug)]
pub struct VariantCase {
/// Name of the variant, unique amongst all cases in a variant.
pub name: String,
/// Optional type associated with this payload.
pub ty: Option<Type>,
}
Implementation plan
To ease the review process and get the feedback early, I plan to split the Wasm CM support implementation into the following stages/PR sets:
Implementation details
Translate the Wasm CM
world
into the IRModule
. Since a non-trivial Wasm component has a complex nested architecture (see basic-wallet example that has 3 components, 4 component instances, 3 core modules and 5 core module instances) it makes sense for the frontend to encapsulate all this complexity and inline everything to produce a single IRModule
. The Wasm CMexport
andimport
top-level directives + canonical definitions (canon
) to be translated and stored in the IRModule
for every imported(external) and exported IR module function.Here is how the IR
Type
variants forlist
andvariant
might look like:Implementation plan
To ease the review process and get the feedback early, I plan to split the Wasm CM support implementation into the following stages/PR sets: