Fix: Allow leading local bindings and assertions in object comprehensions #25
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.


TL;DR: This PR fixes a correctness issue where the current grammar fails to parse certain legal Jsonnet object comprehensions.
Note
The first commit contains the major change, while the second commit contains changes from running
tree-sitter generate.When parsing an object comprehension, the current grammar cannot handle the following legal cases:
Field with a trailing comma:
{ ['f' + i]: i, for i in std.range(1, 10) }What makes it worse, by default,
jsonnetfmtadds a trailing comma when the field is on a separate line.Field with a leading object local binding:
{ local j = 1, ['f' + i]: i + j, for i in std.range(1, 10) }Field with a leading assertion:
{ assert true, ['f' + i]: i + j for i in std.range(1, 10) }This is because the field with a trailing comma, the leading object local binding, and the leading assertion always match
commaSep($.member, true)branch, making it impossible to match the$.objforloopbranch.Following the Jsonnet specification, a Jsonnet object comprehension allows:
Unfortunately, all these combined make building a grammar strictly following the specification non-trivial, and lead to convoluted grammar rules.
Note
The current grammar does not strictly follow the specification either, as it allows static field names in object comprehensions, which is illegal, e.g.:
{ f: i for i in std.range(1, 10) }This PR suggests a fix with a more relaxed but much simpler grammar. Basically, an
objinsideis now 1 or moremembers followed by optionalforspecandcompspec. However, it comes with the following drawbacks, which are arguably acceptable:It allows multiple fields in an object comprehension.
For example, the new grammar does not fail the following illegal document:
{ ['x' + i]: i + j, ['x' + i]: i + j, for i in std.range(1, 10) }For object comprehensions the current grammar parses, this PR removes the
objforloopnode, which is a somewhat backward-incompatible change. However, it does not affect any existing queries.Given the following document:
{ ['item' + i]: i for i in std.range(0,10) }Before this PR:
After this PR:
Note that the
objforloopnode is replaced by amembernode, and the childforspecnode is lifted as a sibling of themembernode.