fuse --component emits an invalid component: every export lifted with an empty (func) type, so non-empty signatures fail wasm-tools validate

[avrabe]

Summary

meld fuse --component emits an invalid component for any export whose function signature is non-empty: every fused export is lifted with an empty component-level function type (func), regardless of the underlying core signature. wasm-tools validate rejects the output; the fused component cannot be instantiated. Silent — fusion prints "Fusion complete!" with no warning. The default core-module output for the same inputs is correct.

Repro

Inputs: two well-formed reloc-bearing components that validate and execute standalone (e.g. the two in harness/fixtures/meld_sleb/, exports get-b: [i32]→[i32], set-b: [i32,i32]→[], ptr-b: []→[i32]).

meld fuse --component a.wasm b.wasm -o out.wasm      # exit 0, "Fusion complete!"
wasm-tools validate --features all out.wasm
  → error: lowered parameter types `[]` do not match parameter types `[I32]` of core function 0

(A value-returning export gives the dual: lowered result types [] do not match result types [I32].)

The fused module's core types are correct — (type (func (param i32) (result i32))), (type (func (result i32))) — but the component-level lift is emitted as (type (;0;) (func)) + (func (canon lift (core func 0))), i.e. the component export type is not derived from the core function signature / the original component export type.

Reproduces under --memory multi, auto, and shared — independent of memory strategy. --component is documented as a plain option with no experimental caveat.

Fix direction

Derive each fused export's component-level function type from the core function signature (or carry through the original component export type) instead of emitting (func).

[avrabe]

Reproduced on 48410f1 (v0.41.1 + #352) with the exact fixtures — meld fuse --component a.wasm b.wasm prints "Fusion complete!" but wasm-tools validate --features all fails: lowered parameter types [] do not match parameter types [I32] of core function 0. The core types are correct; the component-level lift is empty.

Root cause (exact)

The culprit is the bare-function export path in meld-core/src/component_wrap.rs (~line 2042, "Handle bare function exports (e.g. run ...)"). It hardcodes:

let wrapper_func_type = define_bare_func_type(&mut component, &mut component_type_idx); // (func) — empty
canon.lift(aliased_core_func, wrapper_func_type, []);                                   // no options

i.e. it was written assuming bare exports are always run-style (func(), no params/results). Your fixtures are bare world exports (world root { export get-b: func(i: s32) -> u32; ... }) — kind Func, name with no # — so they land in exactly this path and every one is lifted with (func). (The {iface}#{func} interface path above it derives types correctly; only the bare-world path is broken.)

Why the obvious fix isn't a one-liner (heads-up for whoever implements)

"Carry the source export's lift type through" is the right direction, but the resolution is subtler than component_func_defs[comp_export.index]. I tried two variants (index-based, then name-based across all fused components) — both get the first bare export right and later ones wrong (get-b ✓, set-b/ptr-b get shifted/empty types). For these wasm-tools component new-produced components the export's referenced func index doesn't reliably land on the CanonicalEntry::Lift: re-export aliases interleave with lifts, so the component-func index space and the component_func_defs indexing diverge after the first export. The interface path's export.index → component_func_defs lookup works there but not for this bare re-export shape.

So the implementable fix is one of:

1. Resolve each bare export's lift by walking the component export→func→canonical chain with the correct index-space semantics (account for interleaved aliases), then define_source_type_in_wrapper.
2. Derive the component type from the core function signature (arity-correct; maps i32→s32 etc.) — unambiguous per export, but needs FusedModuleInfo to expose a core-func→type map (today it has exports: (name,kind,core_func_index) + func_types by type index, but not the func→type link), and it won't recover exact s32-vs-u32 typing.

Either way the empty-(func) fallback must go, and string/list-returning bare exports additionally need memory + encoding + cabi_post_<name> post-return options carried (the interface path already does this). This is a Tier-5 file (component_wrap.rs) so it wants a Mythos pass + a --component validate-oracle regression test on these fixtures.

I reverted my partial attempts rather than land a fix that only handles the first export. Tagging this precisely so it's ready to implement cleanly.