[Low] Recursion-detected hard abort doesn't match OpenSCAD's exact diagnostic wording (ERROR/TRACE lines)

[particlesector]

Follow-up to #83.

Location: src/lang/Interpreter.{h,cpp} (recursionAborted()/m_recursionAborted*), src/csg/CsgEvaluator.cpp (checkRecursionAbort()).

Background: #83 implemented real tail-call optimization plus a hard-abort mechanism for detected infinite recursion (kMaxCallDepth/kMaxTailHops guards tripping), matching real OpenSCAD's behavior for recursion-test-function.scad and issue3118-recur-limit.scad: no further script output, an Error diagnostic, geometry empty.

Remaining gap: the diagnostic wording doesn't match byte-for-byte. Real OpenSCAD emits:

ERROR: Recursion detected calling function 'crash' in file recursion-test-function.scad, line 1
TRACE: called by 'crash' in file recursion-test-function.scad, line 3
TRACE: called by 'echo' in file recursion-test-function.scad, line 3

ChiselCAD currently emits only:

ERROR: Recursion detected calling function 'crash'

— missing the in file X, line Y location suffix (the location is tracked internally — Interpreter::recursionAbortedLoc() — but not yet included in CsgEvaluator::checkRecursionAbort()'s message) and the TRACE: called by ... call-stack lines entirely (which would need call-stack-with-locations tracking ChiselCAD doesn't currently maintain during expression evaluation).

Impact: low/cosmetic, same category as #85 (diagnostic-wording parity) — doesn't change any computed value, geometry, or control flow, only diagnostic-panel text. Confirmed via a live OpenSCAD 2021.01 binary and the actual upstream test files (fetched from openscad/openscad, not present in this repo).

Fix direction:

1. The in file X, line Y suffix is cheap — checkRecursionAbort() already has d.loc/d.filePath populated correctly, just needs appending to the message text to match OpenSCAD's exact phrasing.
2. The TRACE: lines need an actual call-stack (function name + call-site SourceLoc per frame) threaded through evalFunctionBody()'s trampoline and the ordinary recursive path, captured at the moment the guard trips. Probably fold into whatever [Low] Missing arity-mismatch / file-not-found diagnostic wording parity with OpenSCAD (cosmetic) #85 ends up doing for diagnostic-message parity generally, rather than a one-off for just this case.

[particlesector]

Note on scope: this issue was filed after implementing #83's hard-abort mechanism in the same session — the abort behavior itself (script halts, correct diagnostic, empty geometry) is done and verified as part of #83. This issue is specifically the leftover cosmetic remainder: byte-exact ERROR:/TRACE: wording parity with real OpenSCAD, which was deliberately not attempted here (same "not worth doing until it's an actual user-facing requirement" reasoning the project already applied to #85).

Leaving this open rather than closing it myself, since nothing here has actually been implemented yet — up to you whether it's worth doing now, later, or folding into #85/closing as not-planned given the low value.

---

Generated by Claude Code

[particlesector]

Pushed a fix for the first half of this issue on claude/issue-list-review-461qfl: checkRecursionAbort() now appends the in file X, line Y suffix using the location Interpreter::recursionAbortedLoc() already tracked, matching OpenSCAD's wording (e.g. Recursion detected calling function 'crash' in file recursion-test-function.scad, line 1). Added a fixture-based test (tests/fixtures/eval_diag/function_recursion.scad) exercising the file/line-known path, plus the whole suite (643 cases) still passes.

The TRACE: called by ... call-stack lines are still not implemented — as noted in the issue, that needs actual call-stack-with-locations tracking through evalFunctionBody()'s trampoline and the ordinary recursive path, which is a bigger change I didn't attempt here. Leaving this issue open for that remaining half.

---

Generated by Claude Code