-
-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(css_parser): introduce grit metavariable #3340
Conversation
CodSpeed Performance ReportMerging #3340 will degrade performances by 20.68%Comparing Summary
Benchmarks breakdown
|
Great start! I'm wondering if we can solve the problem in general. It seems all we need is to have a node that can be anywhere and not raise an invalid syntax error. We already have a bogus node type that can be anywhere in the tree; however, it produces a tree with errors. What do you think about having something like a bogus type that doesn't break the syntax tree? |
Sounds good! However, I am wondering if it will meet the needs of the plugin side, as they would like to know the exact node type of metavariable. @arendjr biome/crates/biome_grit_patterns/src/grit_target_language.rs Lines 230 to 231 in f663e6b
|
We do need to be able to check for the node type indeed. But as long as it’s a distinct kind that should be covered. I’m just not entirely sure how I should understand this sentence:
How does that differ from the current metavariable implementation exactly? We can let it appear anywhere we want and it doesn’t raise an error. I guess the subtlety lies in how we make it appear where we want? I would be fine with an alternative approach to using specialized syntax (like the μ character), but I’m not sure I see a better way? |
I agree, but I have slight concerns that we would have to adjust the grammar in many places to include I'm trying to understand if it's possible to implement something similar to what we have for the bogus node. |
I'm with @denbezrukov on this one. Considering the approach of the metavariables ( We've done this for other nodes, such as |
If I understand correctly, @denbezrukov and @ematipico are proposing something like the following:
Is that correct? |
Yes, I think that’s the gist of it. And now I see what @denbezrukov meant, I agree too. It would be best if we had a more generic way of handling these. Probably the solution indeed is that we should be able to specify in the |
We can try to improve it in another PR:) |
@@ -1326,6 +1353,7 @@ impl<'src> ReLexer<'src> for CssLexer<'src> { | |||
Some(current) => match context { | |||
CssReLexContext::Regular => self.consume_token(current), | |||
CssReLexContext::UnicodeRange => self.consume_unicode_range_token(current), | |||
CssReLexContext::GritMetavariable => self.re_lex_grit_metavariable(old_position), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why "re lex" and not "consume"? I don't see any re lexing inside the code
@@ -1315,6 +1317,31 @@ impl<'src> CssLexer<'src> { | |||
_ => false, | |||
} | |||
} | |||
|
|||
fn re_lex_grit_metavariable(&mut self, current_end: usize) -> CssSyntaxKind { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have the same logic inside JavaScript, this function should become part of the lexer trait. Not a blocker
// After parsing the compound selector, it then checks if this compound selector is a part of a complex selector. | ||
parse_compound_selector(p).and_then(|selector| parse_complex_selector(p, selector)) | ||
if p.options().is_grit_metavariable_enabled() { | ||
p.re_lex(CssReLexContext::GritMetavariable); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need the re-lexing here, because we aren't doing any backwards operation. Instead, you should use parsing with a different context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could try to move this logic inside the lexer.
By passing a new option to the lexer and, without any additional context, if the next token is μ
(Επιτέλους, τα ελληνικά μου ήταν χρήσιμα!) and the option is enabled, we can process it as a meta variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense. Addressed in 0ca8bd9
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just another nitpick, thanks!
Summary
Part of #3334
Grammar: https://github.com/getgrit/gritql/blob/main/resources/language-metavariables/tree-sitter-css/grammar.js
Test Plan
Add new tests