Skip to content

fix: parse newline ternary continuation after ellipsis#115

Merged
mhanberg merged 5 commits intoelixir-tools:mainfrom
mkaput:pr/aa39fdc-newline-ternary
Mar 4, 2026
Merged

fix: parse newline ternary continuation after ellipsis#115
mhanberg merged 5 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.

@mkaput mkaput force-pushed the pr/aa39fdc-newline-ternary branch from be958eb to c96069e Compare February 18, 2026 10:27
@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
@mkaput mkaput marked this pull request as ready for review February 20, 2026 09:05
mkaput added 4 commits March 3, 2026 21:49
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.
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.
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.
@mhanberg mhanberg force-pushed the pr/aa39fdc-newline-ternary branch from e48edd0 to 192697d Compare March 4, 2026 02:49
@mhanberg mhanberg merged commit 708da64 into elixir-tools:main Mar 4, 2026
35 of 37 checks passed
mhanberg pushed a commit that referenced this pull request Mar 4, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.3.8](v0.3.7...v0.3.8)
(2026-03-04)


### Bug Fixes

* handle ellipsis before <-, ::, and when
([#114](#114))
([221fe49](221fe49))
* parse newline ternary continuation after ellipsis
([#115](#115))
([708da64](708da64))
* preserve fn newline metadata after semicolons
([#112](#112))
([52099ff](52099ff))
* preserve leading nil in stab clause body
([#120](#120))
([f0a79a0](f0a79a0)),
closes [#113](#113)

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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.

2 participants