Summary
meld fuse produces an invalid fused core module for TinyGo filesystem-using components. wasm-tools validate and Meld's own --validate flag both catch it; any downstream consumer correctly refuses to instantiate.
Reproduction
The failing component is file_ops_component.wasm from pulseengine/wasm-component-examples (TinyGo, uses wasi:filesystem, wasi:cli, wasi:clocks, wasi:io/streams).
meld fuse --validate --verbose file_ops_component.wasm
Actual
[...truncated merger logs...]
[INFO meld_core] Generating adapters
[INFO meld_core] Encoding fused module
[INFO meld_core] Fusion complete: 2 components → 830875 bytes (96% of input)
Validating output...
Error: Validation failed
Caused by:
type mismatch: expected i32 but nothing on stack (at offset 0x1e449)
wasm-tools validate independently confirms: func 131 failed to validate: type mismatch: expected i32 but nothing on stack (at offset 0x1e449).
Context from merger log
The problematic func emerges after intra-component resolution of _initialize:
[DEBUG meld_core::merger] intra-comp func resolve: comp 0 mod 3 import (0) -> comp 0 mod 0 export _initialize[131] = merged 155
[INFO meld_core] Generating adapters
Suggests the adapter-generation phase is producing stack-mismatched code when rewriting the _initialize reference across module boundaries.
Scope
7 of 8 pulseengine command components round-trip cleanly through meld fuse + kilnd (hello_rust, hello_rust_host, hello_c_cli, hello_cpp_cli, datetime, loom, calculator). file_ops_component is the only failure in that corpus. The failing component is the only one that uses wasi:filesystem, so this may be specific to filesystem-resource adapter generation or to TinyGo-output components.
Recommendation
Enable --validate by default in meld fuse so adapter-gen regressions are caught eagerly rather than at downstream instantiation.
Environment
- Meld 0.2.0 (built from current main of pulseengine/meld)
- wasm-tools 1.243.0 (external oracle confirming)
- macOS darwin 25.4.0
Upstream consumer
Filed while investigating RFC #46 alignment for pulseengine/kiln. Kilnd correctly rejects the invalid module with "Failed to instantiate"; this is the expected behavior, the bug is upstream in Meld's adapter gen.
Summary
meld fuseproduces an invalid fused core module for TinyGo filesystem-using components.wasm-tools validateand Meld's own--validateflag both catch it; any downstream consumer correctly refuses to instantiate.Reproduction
The failing component is
file_ops_component.wasmfrom pulseengine/wasm-component-examples (TinyGo, useswasi:filesystem,wasi:cli,wasi:clocks,wasi:io/streams).Actual
wasm-tools validateindependently confirms:func 131 failed to validate: type mismatch: expected i32 but nothing on stack (at offset 0x1e449).Context from merger log
The problematic func emerges after intra-component resolution of
_initialize:Suggests the adapter-generation phase is producing stack-mismatched code when rewriting the
_initializereference across module boundaries.Scope
7 of 8 pulseengine command components round-trip cleanly through
meld fuse+ kilnd (hello_rust, hello_rust_host, hello_c_cli, hello_cpp_cli, datetime, loom, calculator).file_ops_componentis the only failure in that corpus. The failing component is the only one that useswasi:filesystem, so this may be specific to filesystem-resource adapter generation or to TinyGo-output components.Recommendation
Enable
--validateby default inmeld fuseso adapter-gen regressions are caught eagerly rather than at downstream instantiation.Environment
Upstream consumer
Filed while investigating RFC #46 alignment for pulseengine/kiln. Kilnd correctly rejects the invalid module with "Failed to instantiate"; this is the expected behavior, the bug is upstream in Meld's adapter gen.