Repository navigation
Multi-line binary expression: a runtime error reports the OPERATOR's line (decided: option a) #1425
Description
Found while building #1424. It predates that change, and the old and new binaries agree.
x is 0
z is 1 / (
0)
This reports Error line 3 (the operand's last line). The / operator is on line 2.
#1381's decision says: "a runtime error's line (the error header, e.line) is the physical line of the FAULTING sub-expression". That doesn't say which line counts when the faulting operation's operator and its operand are on different lines: the operator's line, the line the operand starts on, or the line it ends on. The VM's current answer is the line the last operand ends on, because that is the last OP_LINE executed before the op. The AOT mirrors whatever the VM does, so the answer here fixes both tiers.
Decision needed
Which line does a runtime error inside a multi-line binary expression report?
- (a) The operator's line (2). This reads naturally in an excerpt and caret, and needs the compiler to re-stamp the line before the op.
- (b) Today's behaviour, the last line executed (3). This costs nothing and needs no change.
- (c) The line the whole expression starts on. This matches the Decide: which line is a multi-line statement filed under (temporal queries see the LAST line today) #1381 filing rule for temporal queries.
Done when
- The owner picks one, it is recorded in
docs/SPEC.mdnext to the Decide: which line is a multi-line statement filed under (temporal queries see the LAST line today) #1381 error-line rule, and a suite test pins it in the interpreter, the JIT and OSR.
Activity
InauguralPhysicist commentedon Sep 30, 2026
Decision (owner, 2026-09-30): (a) the operator's line. A runtime error raised by a binary operation whose operands span lines reports the physical line of the OPERATOR (in
e.line, theError line Nheader, the excerpt and caret, and the traceback). Reason: the error message names the operation ("division by zero", "cannot apply '+'"), so the report should point at where that operation is written. The operand's last line depends on formatting and can point at an unrelated call.This is a refinement of #1381's error-line rule; temporal FILING (the first line) is unchanged. It decides binary operators only. Other constructs that span lines (call arguments, indexing, f-string pieces) are not decided here.
Implementation note: the compiler re-stamps the operator's line before emitting the op only when an operand ends on a different line, so single-line code pays nothing. It goes after #1434 (PR #1436) lands.
[-]Decide: which line does an error in a multi-line binary expression report (operator's or operand's)?[/-][+]Multi-line binary expression: a runtime error reports the OPERATOR's line (decided: option a)[/+]fix: scope binary operator lines to the faulting operation (#1425)
InauguralPhysicist commentedon Oct 1, 2026
Owner, 2026-10-01: compound field/index
+=(AST_DOT_ASSIGN/AST_INDEX_ASSIGN) keeps its current line attribution and is NOT covered by the operator-line rule. Only binary operators are (#1444). Revisit only if a real program needs it.InauguralPhysicist commentedon Oct 13, 2026
Status: the implementation in #1444 went stale against #1665 arm D (23 conflicting files), so it's closed. #1425 stays open and is queued for a re-implementation on current main, with #1444's diff as the reference.
InauguralPhysicist commentedon Oct 19, 2026
Decision record (decision pass, 2026-10-18; owner directive: make waiting decisions against the rules and goals). Already DECIDED: option a, a runtime error in a multi-line binary expression reports the OPERATOR's line. Only the implementation remains: a re-implementation on current main, with #1444's diff as the reference. Relabelled from
kind:decisiontokind:silent-wrong(an error names the wrong line).Generated by Claude Code