mirror of
https://github.com/apple/pkl.git
synced 2026-03-02 14:10:06 +01:00
[PR #1328] [MERGED] fix newline checks in parser #1020
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/apple/pkl/pull/1328
Author: @spyoungtech
Created: 11/20/2025
Status: ✅ Merged
Merged: 11/24/2025
Merged by: @stackoverflow
Base:
main← Head:fix-parsing-newline-checks📝 Commits (1)
d76b1cbfix newline checks in parser📊 Changes
4 files changed (+15 additions, -1 deletions)
View changed files
➕
pkl-core/src/test/files/LanguageSnippetTests/input/errors/binopDifferentLine.pkl(+5 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/errors/binopDifferentLine.err(+6 -0)📝
pkl-parser/src/main/java/org/pkl/parser/Parser.java(+3 -1)📝
pkl-parser/src/test/kotlin/org/pkl/parser/ParserComparisonTest.kt(+1 -0)📄 Description
In places where the parser tries to check or enforce that productions occur on the same line, 'affix' tokens present on subsequent lines, when followed by the expected/enforced production can confuse the parser. For example, this code is rejected by the old ANT parser, but accepted with the new parser in 0.28+:
Execution details
In versions <0.28:
In pkl 0.28+ this succeeds erroneously:
This is because of how the lexer (re)sets
newLinesBetweenwhen it encounters new tokens, including those often ignored by the parser. When those ignored tokens (specifically line comments, block comments, and semicolons) are encountered in, the count is reset and checks likelookahead.newLinesBetween == 0can fail to assert the necessary/intended state.Because checks on newLinesBetween generally are for
==0and coincide with!precededBySemicolonin practice, I think only block comments can cause this issue, even though semicolons and line comments also reset the count.This may also have an impact on how
expectlogically arrives at the error location in which to point.The proposed fix modifies
forceNextto keep track of newlines between tokens, including any newlines between tokens that are skipped, and accumulating the total into the presentedFullToken.This may also be needed for
forceNextCommentbut not sure.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.