compute_caret_offset does not undo the multi-line paren-wrap offset shift

[leongdl]

Summary

Multi-line expressions are wrapped in parentheses for implicit line continuation (parse.rs, let to_parse = format!("({})", source)). The wrap shifts every offset the parser reports — AST ranges and error locations alike — by +1 relative to the unwrapped expression text.

There is no single place that undoes the shift. Four consumers compensate independently, and one does not compensate at all:

consumer	compensates?
Display for ExpressionError (error.rs:314)	yes, subtracts 1 from the column when the expression contains a newline
eval_number float passthrough (evaluator.rs:508)	yes, subtracts a shift derived the same way before slicing the unwrapped source
the keyword-rename retry (parse.rs)	yes, subtracts 1 from the parser's error offset
compute_caret_offset (error.rs:403)	no

compute_caret_offset indexes expr.as_bytes() with raw, still-shifted AST offsets while expr is the unwrapped source, so its backwards operator scan reads bytes one position to the right of the intended ones.

Impact

Cosmetic, and limited to the BinOp arm. The caret for a multi-line ** or // lands on the operator's second character:

~~~^     actual
~~^      correct

The Attribute/Call/Subscript arms are unaffected, because they subtract two shifted offsets from each other and the shift cancels.

The message itself is correct in all cases — it already names the operator and both operand types — so this misplaces a caret column rather than misreporting anything.

Existing coverage

There is an #[ignore]d test for this, added in #321, which fails with ~~~^ where ~~^ is correct. Un-ignoring it is the natural verification for a fix.

Suggested fix

Centralize the adjustment rather than adding a fourth independent - 1:

• record the shift on ParsedExpression at parse time, or
• normalize AST ranges once after a successful multi-line parse.

Either removes three copies of the same compensation and fixes the caret. Both change the diagnostic output of every multi-line BinOp error, so this needs its own regression tests and a decision about the intended caret placement — which is why it was left out of #321.

Context

Raised in review of #321 (#321 (comment) and the wrap-shift thread), where the reviewer asked that the in-code note be replaced by a tracked issue. The 25-line comment in parse.rs describing this is being reduced to a pointer here.

[leongdl]

Fixed in #340.

Took the "centralize" option: one parser_offset_shift(source) next to the wrap that causes the shift, and all four consumers go through it — the caret formatter, Display for ExpressionError, the eval_number float passthrough, and the keyword-rename retry. Three open-coded contains('\n') tests are gone.

Two things worth recording that the issue didn't capture.

Unshifting the offsets was necessary but not sufficient. With correct offsets, the byte between a multi-line operator and its right operand is the newline, and the backwards operator scan skipped spaces, tabs and ( but not line breaks. So it stopped on the newline and still never tested for a two-character operator — same ~~~^ output, different reason. The skip set now includes \n and \r.

The blast radius was wider than the ** / // case described here. Four existing tests pinned the off-by-one for ordinary single-character operators too, so every multi-line BinOp caret was one column right, not just two-character ones. Checked mechanically rather than by eye — the old column landed on the space after the operator in all four:

test	operator col	old caret	new caret
multiline_type_error_in_parens	6	7 (a space)	6 (+)
multiline_type_error_in_list	6	7 (a space)	6 (+)
multiline_type_error_on_first_line	4	5 (a space)	4 (+)
multiline_type_error_deeply_nested	8	9 (a space)	8 (+)

The new output agrees with bare_multiline_error_shows_correct_line and every single-line case, which already expected caret-on-operator, so those four were inconsistent with the rest of the suite rather than encoding an intended convention.

The #[ignore]d test is un-ignored, plus a single-line control (no shift to undo, must render identically) and a multi-line single-character-operator case.