Converting certain component types from wasmparser to wasm_encoder

[thesuhas]

Hi,

I'm writing a WebAssembly Manipulation Library for the Component Model in Rust called Orca.

I'm converting the ComponentTypeSection from the wasmparser to the wasm_encoder and had a few questions.

1. To convert wasmparser::HeapType::Concrete to wasm_encoder::HeapType which is necessary for ComponentType::Resource, how do the indices map? I see that wasm_encoder::HeapType::Concrete takes a u32 index but in wasm_encoder::HeapType::Concrete it is an UnpackedIndex where each variant represents a index into a particular type space or elements. For now I've directly converted them here.
2. To convert ComponentType::Func from wasmparser to wasm_encoder, we need to convert wasmparser::ComponentFuncResult using the wasm_encoder::ComponentFuncTypeEncoder, where we need to convert both the named and unnamed types. The FuncTypeEncoder's results method expects (&str, ComponentValType) but ComponentFuncResult::Unnamed does not have a &str field. In this case would passing an empty string suffice for the encoder?

[alexcrichton]

You might be interested in #1628 which just landed. That's only got support for core modules but if you're interested in adding these conversions to wasm-encoder itself that'd be a welcome PR (and would "just" be extending the new Reencode trait). As for your questions:

For wasmparser::HeapType only the Module variant can be converted. The other two variants should trigger a panic or an error. They're transient states during validation and afterwards but will never show up if you're only parsing a component.

For component functions the Unnamed type would map to calling the result method, not results, so you'd basically call one or the other.

This'd definitely make sense to bake straight into wasm-encoder if you'd like.

[thesuhas]

Thanks! I'll get into adding this to the PR!

I had a few more questions as well.

I'm also trying to convert the ComponentTypeSection and in ComponentType there is a ComponentTypeDeclaration which has a CoreType. The CoreType has a Sub(SubType) variant which has a CompositeType of Functions, Arrays, and Structs.

On the wasm_encoder side, I see the ComponentTypeEncoder which I get from creating a new ComponentType and do .core_type to get a CoreTypeEncoder. I see that this encoder only has methods for functions and modules but not for Arrays and structs. Is this because they are still in the GC proposal? Or is there a way to convert them as well? I do see that wasm_encoder has a CoreType enum as well.

[alexcrichton]

That's correct that component encodings and such generally don't have full support for the GC proposal. For now I'd recommend returning an error or panicking until support is implemented. We'll want to add support for wasm GC to components eventually though, and in theory it should be just copying over a few things (and/or reusing the core bits).

[thesuhas]

Additionally, I see that ComponentType has a ComponentTypeDeclaration which recursively has another ComponentType.

I see that wasm_encoder has a ComponentType which has a .component method that takes a ComponentType. In the ComponentType I see that you can obtain encoders for all the wasm_parser::ComponentType.

I'm wondering how to recursively convert this as there is a bit of recursion in functions in both wasmparser and wasm_encoder. Does this mean that you can have a nested component in a component type section?

[alexcrichton]

There can be nested component types, but not nested components themselves. The recursive structure would need to be reflected, yes, and it's been a bit since I last reviewed the structure of the API in wasm-encoder but it's totally fine to add more knobs and functions as necessary (or edit existing ones)

[thesuhas]

Just to clarify, this means that you can have nested ComponentTypeSections right?

[alexcrichton]

I think I'm confusing myself, but no it's not a section-in-a-section. Within a component type there's a list of entries in a component type. One of those entries can be a nested list of entries making another component type. So nested lists, but not nested sections