Incremental compilation gaps: modules, builtins, variable layout #295

Summary

The incremental compilation path (assemble_simulation/assemble_module in src/simlin-engine/src/db.rs) does not yet handle several important model configurations. These gaps are currently masked because compile_project_incremental returns Err for affected models, causing simlin_sim_new to fall back to the monolithic compilation path. No correctness bugs result, but extending the incremental path would eliminate unnecessary fallback overhead.

Gaps Identified

1. Module variables don't receive stock-phase bytecodes

• compile_var_fragment only generates stock_bytecodes for is_stock variables
• However, model_dependency_graph includes modules in runlist_stocks
• Module variables should get stock-phase bytecodes to participate correctly in the stock phase

2. Implicit variables from SMOOTH/DELAY/TREND builtin expansion lack layout slots

• When builtins expand (e.g., SMOOTH(x, tau) → synthesized level/rate variables), the implicit generated variables have no SourceVariable entries
• These variables receive no layout slots in compute_layout
• This prevents correct bytecode resolution for equations depending on builtin results

3. module_models is always empty in compile_var_fragment

• module_models is never populated in the incremental pipeline
• This prevents resolution of module output references (e.g., module1.output_var)
• Without this context, module variable equations cannot be compiled correctly

4. Module input sets are not passed through the incremental pipeline

• All module instances compile with identical bytecodes
• Input bindings (the external variables driving each module instance) are not differentiated
• Each instance should generate instance-specific bytecodes based on its input wiring

Impact

• Models using modules, builtins (SMOOTH/DELAY/TREND), or both currently fall back to monolithic compilation
• Fallback compilation works correctly but incurs recompilation overhead on each simlin_sim_new call
• Fixing these gaps would allow incremental compilation to handle additional models

Context

Identified during code review of PR #289 (incremental compilation implementation).

Acceptance Criteria

These are design extensions, not blocking issues. Prioritize based on:

1. Measurement: what % of real-world models hit these gaps?
2. Overhead impact: how significant is the fallback cost?
3. Effort: cost/benefit of incremental pipeline vs. monolithic performance (incremental has startup/memory costs)