Handle multiply-instantiated modules #24
Description
Context
BA RFC #46 (bytecodealliance/rfcs#46) identifies multiply-instantiated modules as an open question for component lowering. A component may instantiate the same core module more than once, each needing its own memory and globals.
Meld does not currently handle this case.
Options (from RFC analysis)
| Option | Trade-off |
|---|---|
| Reject (fail-fast) | Safest. Clear error message. Limits component coverage. |
| Duplicate functions | Full coverage but potential bloat. Leaf functions (no memory/globals) can be shared. |
| Multi-module output | Full coverage, no bloat, but requires external linker metadata and new packaging format. |
STPA assessment
- Reject: no new hazards (safe default, aligns with SC-8/SC-9)
- Duplicate: H-3 (index remapping) applies per-instance; RH-5 (shared state semantics change); RL-5 (bloat)
- Multi-module: new trust surface (linker metadata format)
Recommendation
Start with reject (detect and report error). Add duplicate mode when real-world components require it — the existing merger infrastructure (index remapping, proven correct for N components) extends naturally to N instances of the same module.
Related
- STPA analysis:
safety/stpa/rfc46-comparative-analysis.md(gap MG-3) - BA RFC: Propose tools and APIs for lowering components to core modules bytecodealliance/rfcs#46