fix: parse newline ternary continuation after ellipsis#115
Open
mkaput wants to merge 4 commits intoelixir-tools:mainfrom
Open
fix: parse newline ternary continuation after ellipsis#115mkaput wants to merge 4 commits intoelixir-tools:mainfrom
mkaput wants to merge 4 commits intoelixir-tools:mainfrom
Conversation
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.
be958eb to
c96069e
Compare
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
commented
Feb 18, 2026
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ellipsis was being treated as standalone before
//when ternary continuation arrived with newline metadata, which produced a mismatched AST for forms likex...\n//y.This change detects newline-associated ternary continuation in
parse_ellipsis_op/1and 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.