feat(parser): binary-operator line continuation (SH-017); correct SH-020

SH-017 proper fix: statement-level expressions now continue across newlines when
a line begins with or follows a line ending in an unambiguous binary operator
(| & + * / % ^), so wrapped ||/&&/+ chains are valid instead of silently-wrong.
Excludes < > - = ! (generics/comparison/unary and the dangling-'let x =' /
leading-'!expr' footguns). scan.rs statement_end. Spec §A.1 gains the normative
statement-termination + continuation rule (fixing the stale 'not layout-sensitive'
claim). Fail fixture -> pass fixture (multiline-operator-continuation.rss).

SH-020: corrected — tuple returns + destructuring work (verified); the entry
over-claimed a non-existent 'no multi-value return' gap. Withdrawn.

Gated: full suite CARGO_EXIT=0 (static 628), self-host parity 551/551.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: olwang

crates/rsscript/src/syntax/parser/scan.rs

@@ -58,7 +58,7 @@ fn starts_top_level_item(tokens: &[Token], index: usize) -> bool {
 }
 
 pub(super) fn statement_end(tokens: &[Token], start: usize, limit: usize) -> usize {
-    let line = tokens[start].span.line;
+    let mut line = tokens[start].span.line;
     let mut depth = 0usize;
     let mut angle_depth = 0usize;
     let mut postfix_continuation_line = None;
@@ -76,6 +76,20 @@ pub(super) fn statement_end(tokens: &[Token], start: usize, limit: usize) -> usi
                 // `.map(...)` chain.
             } else if is_statement_postfix_token(token) {
                 postfix_continuation_line = Some(token.span.line);
+            } else if is_continuation_operator(token)
+                || tokens
+                    .get(index - 1)
+                    .is_some_and(|prev| is_continuation_operator(prev))
+            {
+                // Binary-operator line continuation: a line that *begins* with a
+                // binary operator (leading style) or *follows* a line ending in
+                // one (trailing style) continues the current statement's
+                // expression rather than starting a new statement. Absorb this
+                // line by advancing the reference line. Only the unambiguous
+                // operators in `is_continuation_operator` qualify (see there for
+                // why `<`/`>`/`-`/`=`/`!` are excluded), so a wrapped chain can
+                // never swallow the start of a genuinely new statement.
+                line = token.span.line;
             } else {
                 return index;
             }
@@ -100,6 +114,28 @@ fn is_statement_postfix_token(token: &Token) -> bool {
     token.symbol("?") || token.symbol(".")
 }
 
+/// Binary operators that make a statement-level expression continue across a
+/// newline (SH-017): `|` `&` `+` `*` `/` `%` `^` (so `||`, `&&`, `+`, `*`, … may
+/// wrap). The set is deliberately conservative so a wrapped chain can NEVER
+/// absorb the start of a genuinely new statement:
+/// - `<` / `>` are excluded (generic brackets / comparison).
+/// - `-` is excluded (unary minus can legitimately start a statement).
+/// - `=` is excluded (a dangling `let x =` must stay a *malformed statement*, not
+///   silently swallow the next line — that would reintroduce the very
+///   silent-merge footgun SH-017 fixes).
+/// - `!` is excluded (a leading `!expr` is a valid statement start).
+/// Consequently `==` / `!=` / `<=` / `>=` / `=` cannot wrap across lines — keep
+/// those on one line.
+fn is_continuation_operator(token: &Token) -> bool {
+    token.symbol("|")
+        || token.symbol("&")
+        || token.symbol("+")
+        || token.symbol("*")
+        || token.symbol("/")
+        || token.symbol("%")
+        || token.symbol("^")
+}
+
 pub(super) fn find_control_body_open(
     tokens: &[Token],
     start: usize,

crates/rsscript/tests/fixtures/fail/leading-operator-continuation.rss

@@ -0,0 +1,24 @@
+// A statement-level expression may now continue across newlines when a line
+// begins with, or ends with, an unambiguous binary operator (SH-017).
+
+// Leading-operator style: continuation lines start with `||`.
+fn is_kw_leading(word: read String) -> Bool {
+    return word == "if" || word == "else"
+        || word == "fn"
+        || word == "let"
+}
+
+// Trailing-operator style: lines end with the operator.
+fn sum_trailing(a: Int, b: Int, c: Int) -> Int {
+    return a +
+        b +
+        c
+}
+
+fn main() -> Unit {
+    let ok = is_kw_leading(word: read "fn")
+    let total = sum_trailing(a: 1, b: 2, c: 3)
+    Log.write(message: read String.from_bool(value: ok))
+    Log.write(message: read String.from_int(value: total))
+    return Unit
+}

crates/rsscript/tests/fixtures/pass/multiline-operator-continuation.rss

@@ -415,19 +415,23 @@ gap is VM value-representation / intrinsic-dispatch cost (the next big lever).
 - **Classification:** language / parser (missing operator-continuation) + a
   correctness-grade diagnostics gap (leading-operator form should error, not
   silently truncate).
-- **Decision:** rule for all self-hosted rss — **keep a statement-level
-  expression on one line**; break long boolean tests into a single line or into
-  helper predicates / early-return `if`s. Worked around by making `is_kw` a
-  single-line chain. Language-side follow-up: either support operator
-  continuation or make the leading-operator form a hard error.
-- **Tests:** `crate::selfhost_parity::lexer_parity_tiny_sample`;
-  fixture `tests/fixtures/fail/leading-operator-continuation.rss`.
-- **Status:** fixed: a leading-`||` statement continuation now emits RS0015
-  ("unsupported statement") instead of silently parsing as a discarded empty-arg
-  closure. Guard added in `syntax/parser/stmt.rs` `parse_stmt` (statement
-  fall-through only; `if`/`while`/`match` conditions and value/argument closures
-  are unaffected). Operator continuation itself is still not supported; keep
-  statement-level expressions on one line.
+- **Decision:** FIXED PROPERLY (2026-07-01) — statement-level expressions now
+  **continue across newlines** on an unambiguous binary operator, so the wrapped
+  chain that used to be silently-wrong is now *valid and correct*. In
+  `syntax/parser/scan.rs` `statement_end`, a line that begins with, or follows a
+  line ending in, one of `| & + * / % ^` continues the current statement (leading
+  and trailing styles both work); `<`, `>`, `-`, `=`, `!` are excluded (generics /
+  comparison / unary-minus, plus a dangling `let x =` and a leading `!expr` must
+  NOT silently swallow the next line — that would reintroduce the SH-017 footgun),
+  so a wrap can never swallow the start of a new statement. `==`/`!=`/`<=`/`>=`/`=`
+  stay single-line. The interim safety guard in `stmt.rs` stays as a backstop for a
+  genuine leading-`||` at a block start. Spec §A.1 updated with the normative
+  statement-termination + continuation rule (reconciling the stale
+  "not layout-sensitive" claim).
+- **Tests:** `tests/fixtures/pass/multiline-operator-continuation.rss` (leading
+  and trailing styles); the former fail fixture was removed (the construct is now
+  valid). Full suite + differential + self-host parity green.
+- **Status:** fixed (operator continuation supported).
 
 ### SH-018 — no cursor/state object: scan helpers must thread `(chars, n, index)` and return the new index
 
@@ -521,17 +525,18 @@ gap is VM value-representation / intrinsic-dispatch cost (the next big lever).
   }
   ```
 - **Backend:** all (language ergonomics).
-- **Root cause:** no ergonomic multi-value/tuple return and no mutable cursor, so
-  the classic "parser returns Result<Node, Err> while advancing self.pos" shape
-  collapses into an overloaded sentinel Int. Fine for a recognizer (which only
-  needs accept/reject), but a node-building parser would want a real result
-  struct per nonterminal.
-- **Classification:** language (ergonomics) + docs — same family as SH-018.
-- **Decision:** worked around with the `-1`-sentinel convention; reaches full
-  recognition parity (545/545). Recorded so the plumbing cost of a stateful
-  recursive-descent pass in rss is visible alongside SH-018.
-- **Tests:** `crate::selfhost_parity::parser_parity_corpus` (recognition, 545/545).
-- **Status:** decided (worked around).
+- **Root cause (CORRECTED 2026-07-01):** the "no lightweight tuple return" premise
+  was WRONG — verified that `fn f() -> (Bool, Int) { return (true, 5) }` with
+  `let (ok, n) = f()` compiles and runs on the VM. Multi-value return via tuples
+  works today, so a node-building parser CAN return `(new_index, node)`; the
+  sentinel-`Int` convention was an unforced choice, not a language limit. The only
+  genuine residual is the cursor plumbing itself (SH-018), which the
+  `mut`-scalar-param write-back fix removes (pass the cursor as `mut pos`).
+- **Classification:** docs (the original entry over-claimed a non-existent gap).
+- **Decision:** WITHDRAWN as a language gap. Tuple returns work; the remaining
+  ergonomic cost folds into SH-018 (cursor mutation), fixed separately.
+- **Tests:** verified by probe (`fn f() -> (Bool, Int)` + tuple destructuring).
+- **Status:** closed (not a gap — tuple returns work; over-claim corrected).
 
 ### SH-021 — `parse_source_raw` defers body validation: recognition parity under-tests the grammar
 

docs/ledgers/rss-selfhost-ledger.md

@@ -5815,8 +5815,20 @@ adds), but it fixes the surface shape so a parser and the prose agree.
 ```text
 Tokens         identifier | number | string | keyword | symbol | EOF
 Comment        `// ...` to end of line. There is no block-comment form.
-Whitespace     spaces, tabs, and newlines separate tokens and are otherwise
-               insignificant (the language is not layout-sensitive).
+Whitespace     spaces, tabs, and newlines separate tokens and produce no tokens
+               of their own. Newlines are significant only for statement
+               termination (below); they are otherwise insignificant.
+Statement end  A statement ends at a newline that sits at the top level of the
+               statement, EXCEPT when the expression is still open — i.e. an
+               unclosed `(` `[` `{`, a postfix continuation (`.`/`?` beginning or
+               ending the break), or a binary-operator continuation: a line that
+               begins with, or follows a line ending in, one of `| & + * / % ^`
+               (so `||`, `&&`, `+`, `*`, … chains may wrap across lines). `<`,
+               `>`, `-`, `=`, and `!` are deliberately NOT continuation operators
+               (generics/comparison, unary minus, and a dangling `let x =` or
+               leading `!expr` must not silently swallow the next line), so
+               `==`, `!=`, `<=`, `>=`, and `=` expressions must stay on one line.
+               An explicit `;` also ends a statement, allowing several per line.
 Identifier     ident-start (letter or `_`) followed by letters, digits, or `_`.
 Number         one or more digits, optionally `.` then one or more digits.
                A fractional part makes it a Float literal; otherwise an Int