You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
tree-sitter-scss correctly parses the first declaration as property name. It ERRORs on the second declaration, and claims its best-fit is as a pseudo_class_selector.
I believe part of the confusion comes from an inappropriate declaration in tree-sitter-css, namely this one:
To the best of my knowledge, a tag_name cannot start with the -- sequence, yet here it's allowed, creating an ambiguity. Unfortunately, the confusion of tag_name with identifier goes pretty deep and recursive in the definition of _selector, leading to the problem.
Steps To Reproduce/Bad Parse Tree
Attempt to parse this file with $ tree-sitter parse file.scss:
# Related Links:
Addresses [Issue 7: tree-sitter parses complex declaration as pseudo-class instead of CSS custom
property](tree-sitter-grammars#7).
# What
This commit places a guard clause around the scanner expression for detecting a pseudo-class
selector colon. The guard clause ensures that the character *prior to* any `{` symbol was not the
start of interpolation.
I have also re-run the generate under 0.24.5, so the parser, headr files, and generated grammar have
been updated to the latest & greatest version. A `tree-sitter.json` file has also been generated,
and the corresponding tree-sitter clause removed from `package.json` (automatically, by tooling).
# Why
This declaration, which has been [added to the test cases](./test/corpus/declarations.txt).
```
div {
--#{$x}--left: var(--#{$y}--right);
}
```
As written, when `PSEUDO_CLASS_SELECTOR_COLON` is a valid possible symbol, the scanner clause for
pseudo-class selector detection passes if a `{` is detected before encountering a `}` or `;` symbol.
The expression `#{$y}` in the test case meets that criteria, the lexer result is marked incorrectly,
and the parser fails to parse the declaration correctly.
Adding a guard that the prior character seen was a `#` and that the `{` is not the start of a nested
block identified by a pseudo-class but is, instead, part of an interpolation, fixes this issue.
# Test steps
1. Run the tests under the old clause and see this failure:
```
correct / expected / unexpected
1. Interpolation on both sides of a declaration:
(stylesheet
(rule_set
(selectors
(tag_name))
(block
(declaration
(ERROR)
(property_name
(identifier)
(interpolation
(variable))
(identifier))
(call_expression
(function_name)
(arguments
(identifier)
(interpolation
(variable))
(identifier)))))))
```
2. Run it with the new clause and there is no more failure. :-) In fact, *all* of the tests now
pass.
Did you check existing issues?
Tree-Sitter CLI Version, if relevant (output of
tree-sitter --version
)tree-sitter 0.24.5
Describe the bug
In the following Sass rule_set.block:
tree-sitter-scss correctly parses the first declaration as property name. It ERRORs on the second declaration, and claims its best-fit is as a
pseudo_class_selector
.I believe part of the confusion comes from an inappropriate declaration in
tree-sitter-css
, namely this one:To the best of my knowledge, a tag_name cannot start with the
--
sequence, yet here it's allowed, creating an ambiguity. Unfortunately, the confusion oftag_name
withidentifier
goes pretty deep and recursive in the definition of_selector
, leading to the problem.Steps To Reproduce/Bad Parse Tree
$ tree-sitter parse file.scss
:Expected Behavior/Parse Tree
I would expect the second declaration to be correctly interpreted as a declaration.
Repro
The example is given above.
The text was updated successfully, but these errors were encountered: