engine: db.rs is 1 line from the 6000-line lint cap; split before it blocks an unrelated commit #518

Activity

1. bpowers

   added a commit that references this issue on May 10, 2026

   engine: LTM cross-element aggregate scoring (aggregate nodes) (#519)

   ...

   29d4d70
2. bpowers commented on May 15, 2026

   

   bpowers

   on May 15, 2026

   OwnerAuthor

   More actions

   Recurrence during Vensim macro support work (Phase 3)

   This concern recurred on a completely independent feature stream, confirming it is a recurring tax rather than an artifact of the LTM work that originally surfaced it.

   During Phase 3 of the Vensim macro support implementation (docs/implementation-plans/2026-05-13-macros/, branch macros), the macro-registry compilation wiring tripped the MAX_LINES=6000 cap on db.rs multiple times across two separate tasks:

   • First over the cap at 6124 lines.
   • Then repeatedly back over at 6001 / 6002 lines while landing the registry wiring.

   Each occurrence forced defensive, off-task work to get back under the cap:

   • Extracted a new sibling module src/simlin-engine/src/db_macro_registry.rs (via the established #[path] mod ...; pattern, same precedent as db_ltm_ir / db_analysis / db_ltm / ltm_agg).
   • Condensed existing comments in db.rs to reclaim lines.

   After that work db.rs again sits with only ~1 line of margin under the 6000 cap, so the next change that touches it at all will trip the cap and force yet another unrelated decomposition/comment-trimming side quest.

   Why this strengthens the case

   The original report framed this as fallout from the LTM cross-element-aggregate-scoring work. This recurrence on the macro stream demonstrates the squeeze is structural: db.rs is the salsa-incremental-compilation hub where most new compilation/analysis wiring lands, so essentially every feature that adds a compilation pass pays this tax. Bumping headroom by one extraction at a time (db_ltm_ir, now db_macro_registry) keeps deferring the real fix.

   Recommended remediation (updated)

   Proactively split cohesive chunks of db.rs into sibling modules following the established db_ltm_ir / db_macro_registry pattern, targeting a comfortable margin (not ~1 line) under the cap. Candidate cohesive groups:

   • The sync_from_datamodel family.
   • The diagnostic-collection helpers.
   • (Per original report) the assemble_module / compute_layout layout-and-assembly section or its LTM-wiring portion, and/or the dependency-graph construction.

   Goal: bring db.rs to a comfortable margin under the 6000-line cap so routine changes stop tripping it.

   Context

   Identified during Phase 3 of the Vensim macro support work (docs/implementation-plans/2026-05-13-macros/). This is tech debt out of scope for the macro-support task; tracked here, not fixed there.
3. bpowers commented on May 15, 2026

   

   bpowers

   on May 15, 2026

   OwnerAuthor

   More actions

   Recurrence during GH #554 macro fix (intrinsic false self-recursion)

   A third+ recurrence, on a later commit than the Phase 3 comment above, on the same macros branch but a distinct task: landing the GH #554 fix (b0ef57a2 engine: fix false self-recursion for intrinsic macros).

   That fix touches the salsa-incremental compilation hub (it adds a salsa-tracked macro_body_owner map and threads macro-self-recursion detection through collect_called_macros / BuiltinVisitor::walk). Implementing it again pushed src/simlin-engine/src/db.rs over the MAX_LINES=6000 cap enforced by scripts/lint-project.sh (line 40, MAX_LINES=6000; check at line 46-47).

   To get back under the cap the implementer had to:

   • Relocate logic into the existing src/simlin-engine/src/db_macro_registry.rs sibling module (the same #[path] mod ...; decomposition template established by db_ltm_ir / db_macro_registry), and
   • Tighten an otherwise-unrelated in-context comment in db.rs purely to reclaim lines and fit the cap.

   After that work db.rs sits at exactly 6000 lines -- zero margin:

   $ wc -l src/simlin-engine/src/db.rs src/simlin-engine/src/db_macro_registry.rs src/simlin-engine/src/db_ltm_ir.rs
     6000 src/simlin-engine/src/db.rs
      384 src/simlin-engine/src/db_macro_registry.rs
      693 src/simlin-engine/src/db_ltm_ir.rs
   

   So the very next change that touches db.rs at all will trip the cap and force yet another unrelated decomposition / comment-trimming side quest -- exactly the failure mode this issue's title calls out.

   Why this strengthens the case

   This is now the third+ time the chronic db.rs cap has imposed an unrelated decomposition + comment-trimming tax on an in-flight feature change (the LTM cross-element-aggregate work in the original report, the macro Phase 2/3 work in the comment above, and now the GH #554 fix). The pattern is consistent and structural: db.rs is the salsa-incremental-compilation hub, so essentially every feature adding a compilation/analysis pass pays this tax, and each one-extraction-at-a-time bump (db_ltm_ir, then db_macro_registry) just re-arms the trap at ~0-1 lines of margin.

   The remediation already proposed in this issue still stands and is reinforced: proactively split cohesive chunks of db.rs into sibling modules following the established db_ltm_ir / db_macro_registry template, targeting a comfortable margin under the 6000 cap rather than landing back at the cap each time.

   Context

   Identified while landing the GH #554 fix (b0ef57a2) on branch macros (docs/implementation-plans/2026-05-13-macros/). Out of scope for the macro epic; recorded here as fresh recurrence evidence, not fixed there.
4. bpowers commented on May 19, 2026

   

   bpowers

   on May 19, 2026

   OwnerAuthor

   More actions

   Update (2026-05-19, surfaced by the element-cycle-resolution Phase 6c code review):

   Current measurements after element-cycle-resolution Phase 6:

   • src/simlin-engine/src/db.rs: 5895 lines (still under the 6000 cap; the squeeze recurs as predicted)
   • src/simlin-engine/src/vm.rs: 5920 lines (now also within ~80 lines of the cap)

   The relief pattern this issue recommends has continued: db.rs has since spun out db_dep_graph.rs, db_ltm_ir.rs, db_macro_registry.rs, and db_var_fragment.rs (in addition to the db_analysis.rs/db_ltm.rs/ltm_agg.rs named in the original description) specifically to stay under the cap.

   vm.rs is now in the same situation this issue describes for db.rs: it has already spun out vm_vector_elm_map.rs and vm_vector_sort_order.rs to manage headroom, and at 5920 lines a future task adding to it will be forced to split mid-stream. Filed as a separate, focused issue (cross-referenced) so the vm.rs half is tracked independently of the db.rs salsa-hub work.
5. bpowers

   added

   engineIssues with the rust-based simulation engineIssues with the rust-based simulation engine

   hygieneToil, but its useful to get get too behind on itToil, but its useful to get get too behind on it

   on Jun 8, 2026