Type-checker OOM (16-32 GB allocation) on deeply-nested str_concat / format chains

[hyperpolymath]

Symptom

my check on a .my file with many deeply-nested str_concat chains and/or many multi-line format() templates triggers a runaway memory allocation (16-32 GB observed) and OOM-aborts the process:

my.exe : memory allocation of 34359738368 bytes failed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The same happens on my run of the same file (the type-checker runs first).

Reproducible against

A non-trivial Solo program with ~30 inline template-emitter functions, each containing chained str_concat/format() calls, totalling ~330 LOC. Stripped down to ~110 LOC (audit logic only, no template builders), the same file type-checks and runs in <1s.

The trigger appears to be aggregate complexity of nested string-building constructs, not any single construct. A minimal pathological case I could not narrow further in this session.

Approximate repro shape

fn build_a(name: String, lang: String) -> String {
    return str_concat(
        str_concat(
            str_concat(
                format("// SPDX-License-Identifier: PMPL-1.0-or-later\n= {}\n:toc:\n\n", [name]),
                format("Component: {} ({}).\n\n", [name, lang])
            ),
            format("== Status\n\nStandalone. Conforms to the standards.\n\n* RSR template floor.\n* Stapeln container build using {}.\n* Contractiles.\n* 6a2 machine-readable.\n\n", [lang])
        ),
        "\n== License\n\nPMPL-1.0-or-later.\n"
    );
}

// ... 27 more functions of similar shape ...
// Combined file -> OOM during `my check`

Environment

• my-lang HEAD: as of 2026-04-30 (with locally-applied stdlib additions for fs_*/env_args/format — see paired PR)
• Toolchain: stable-x86_64-pc-windows-msvc, rustc 1.95.0
• OS: Windows 11 Pro for Workstations 26300

Suspected cause

Type-checker likely has a non-memoised recursion over the AST of str_concat/format chains, producing exponential type-resolution cost. A minimal Array mismatch returns a clean TypeMismatch error in microseconds, so the OOM is specifically a complexity issue, not parser-level construct rejection.

Suggested fix direction

• Memoise type checks on common subexpressions (especially repeated str_concat/format AST nodes).
• Add a depth/size guard with a clear error when exceeded, rather than letting the allocator OOM.

Workaround in use

For the project that surfaced this (an idaptik scaffold tool), templates were moved out of .my source and into on-disk template files, read at runtime via fs_read_file + format(). The reduced AST type-checks fine.

Why this matters

This blocks using Solo for tooling that emits templated output (scaffolders, codegens, doc generators). Until fixed, every such tool has to use the on-disk-template workaround, which is a real ergonomic tax.

[hyperpolymath]

Update 2026-04-30 (later same day)

The on-disk-templates workaround helps but does not fully cure the OOM.

I refactored scaffold-component.my to load templates from disk via fs_read_file + a custom ${KEY} substitution pass (not format()'s {}, to avoid clashing with literal braces in the templates). The inlined str_concat/format chains were removed. The file dropped from ~330 LOC to ~280 LOC.

my check on the refactored file still OOMs at 32 GB.

So the trigger is broader than just nested string-building. Other suspects in the refactored file:

• Multiple recursive helpers (tmpl_apply_inner, audit_inner, deps_block_inner, print_missing, find_flag, collect_deps_inner).
• Multiple [String] parameters across mutually-recursive functions.
• if x == "literal" { return "literal"; } cascades in profile_chainguard_base / dep_purpose (Solo's checker may not memoise these).
• Mixed dynamic+literal [String] array constructions (e.g. ["NAME", name, "DESCRIPTION", desc, ...] where some elements are dynamic and some literal).

The minimal pared-down version (scaffold-audit.my, ~110 LOC, audit-only with no template work, no tmpl_* helpers, no profile accessors) type-checks and runs fine. So the trigger is somewhere in the additional surface added when the full-fat tool is in scope — possibly the combinatorial number of mutually-recursive [String]-handling functions.

If anyone wants to bisect: the diff between scaffold-audit.my and scaffold-component.my is the full template-rendering pipeline (tmpl_one, tmpl_apply_inner, tmpl_apply, render_tmpl, generate, emit, deps_block_inner, deps_block, profile_chainguard_base, dep_purpose). Removing them in halves should localise the trigger within ~3-4 iterations.

The on-disk-templates approach is still the right architectural move (avoids inlining huge string blobs into the AST), it's just not sufficient on its own.

[hyperpolymath]

Status summary

Closed by PR #12 (bc63c45), which adds a MAX_EXPR_DEPTH = 256 guard in crates/my-lang/src/checker.rs. Pathological inputs now emit a single CheckError::ExpressionTooDeep diagnostic — with an actionable hint ("refactor deeply nested calls into intermediate let bindings") — instead of OOM-aborting the process.

This addresses the symptom described here. The depth guard is sufficient for the original ergonomic complaint (scaffolders/codegens can either inline their templates and get a clean error, or keep using the fs_read_file workaround).

The two deeper questions raised by this issue are tracked separately so they don't get lost:

• Root cause of the 16–32 GiB allocation on Windows → Type-checker root-cause investigation: reproduce the 16–32 GiB allocation observed on Windows in #1 #14. I could not reproduce the OOM on Linux even with the issue's exact shape; the checker is structurally linear on the inputs I tested. If there's a real superlinear hotspot it still needs investigation against the actual ~330 LOC repro on stable-x86_64-pc-windows-msvc.
• Parser-side depth guard → Parser: add a depth guard mirroring the type-checker's MAX_EXPR_DEPTH #15. The parser is recursive-descent and SIGABRTs on inputs deep enough to exercise the new checker guard, before the checker ever runs.
• Memoisation of str_concat / format subexpressions (the issue's other suggested fix direction) → Type-checker: memoise type checks on common subexpressions (str_concat / format) #16. Deliberately deferred until Type-checker root-cause investigation: reproduce the 16–32 GiB allocation observed on Windows in #1 #14 produces measurements that justify the refactor.

PR #12 was a defensive symptom-fix, not a full resolution of the underlying complexity question. Re-open or comment if you hit a case where the depth guard rejects code that should be legal.

---

Generated by Claude Code