9d29718f03
Enable static box method calls for boxes imported via `using` statement. Root cause: 3 interrelated issues 1. Cross-function ValueId: methodize created singleton with ValueId that can't be used across MIR function boundaries 2. Missing registration: using-imported static boxes weren't in static_box_decls (only AST-based boxes were registered) 3. Wrong dispatch: method.rs tried InstanceBox dispatch instead of MIR function table lookup for static boxes Fixes: - unified_emitter.rs: Use receiver=None for StaticCompiler boxes - vm.rs: Auto-detect and register static boxes from MIR function names - mod.rs: Add has_static_box_decl() helper - method.rs: Add MIR function table lookup path for static boxes - guard.rs: Trust methodize for StaticCompiler boxes without type info Test: JsonParserBox.toString() via using import now works correctly 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
MIR Builder — Calls SSOT
Scope
- This directory is the single source of truth for call shaping in the builder.
- Responsibilities: target resolution, extern mapping, method lookup, flags/effects, MIR emission.
Out of scope
- Runtime dispatch details (VM/LLVM) and legacy by-name resolution. The VM keeps a legacy resolver only behind a dev flag for bring-up.
Contract
- Builder must populate
MirInstruction::Callwith a concreteCalleewhenever possible. - Arity and canonical names are normalized here so runtimes can be simple routers.
Phase-3 alignment
- VM call resolver is treated as legacy-only. Default runtime disables by-name fallback.
- Extern interface normalization aligns with
handlers/calls/externs.rs(runtime SSOT for extern dispatch).