Skip to content

Comments

fix: parse newline ternary continuation after ellipsis#115

Open
mkaput wants to merge 4 commits intoelixir-tools:mainfrom
mkaput:pr/aa39fdc-newline-ternary
Open

fix: parse newline ternary continuation after ellipsis#115
mkaput wants to merge 4 commits intoelixir-tools:mainfrom
mkaput:pr/aa39fdc-newline-ternary

Conversation

@mkaput
Copy link
Contributor

@mkaput mkaput commented Feb 18, 2026

Ellipsis was being treated as standalone before // when ternary continuation arrived with newline metadata, which produced a mismatched AST for forms like x...\n//y.

This change detects newline-associated ternary continuation in parse_ellipsis_op/1 and keeps existing semicolon-separated behavior intact (x...;//y).

It also adds regression assertions for newline and semicolon-separated ternary continuation cases in the property-regression test block.

Ellipsis was treated as standalone before `//` when the ternary operator arrived with newline metadata, producing a mismatched AST for forms like `x...\n//y`.

Detect newline-associated ternary continuation and keep existing semicolon-separated behavior intact (e.g. `x...;//y`).

Adds a regression assertions in the property-regression test block.
@mkaput mkaput force-pushed the pr/aa39fdc-newline-ternary branch from be958eb to c96069e Compare February 18, 2026 10:27
Fix ellipsis continuation detection for newline ternary parsing so semicolons still terminate the previous expression.

The previous newline ternary check skipped both newlines and semicolons, which caused inputs like x...\n;//y and x...\n;\n//y to be parsed as ellipsis continuation and emit an unknown eol token error.

Use newline-only lookahead for the continuation check, and add regression assertions for semicolon-separated newline forms (including an intervening comment) next to the existing x...;//y coverage.
@mkaput mkaput marked this pull request as draft February 18, 2026 11:58
@mkaput mkaput marked this pull request as draft February 18, 2026 11:58
Update parser semantics around ellipsis and range-step handling to match Elixir behavior for edge cases involving //.

What changed:

- In parse_infix_expression/2, handle infix // as a range-step operator only when the lhs is a range node, producing :..//.

- For non-range lhs, record the same range-step diagnostic intent Elixir uses, instead of silently accepting a generic binary //.

- In parse_ellipsis_op/1, treat :ternary_op as a continuation candidate rather than a standalone-ellipsis stop token, which fixes newline forms like x...\n//y.

- Add a regression test asserting non-range // produces an error path for x...//y.

Why:

The previous behavior diverged from Elixir in two directions: it accepted non-range infix // and parsed x...\n//y as ternary continuation instead of preserving ellipsis unary continuation semantics. This change resolves both at grammar/parse semantics level rather than adding context-specific lookahead hacks.

Special considerations:

- Tokenizer behavior was already aligned with Elixir for these inputs; the fix is parser-only.

- Existing semicolon-separated ellipsis cases remain covered and passing.
@mkaput mkaput marked this pull request as ready for review February 20, 2026 09:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant