-
-
Notifications
You must be signed in to change notification settings - Fork 151
New approach to handling optional chains #138
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
Conversation
|
Interesting. I'm trying this right away on typescript. |
|
Awesome! I haven't looked into optional chain support in typescript, but I just ran --- a/common/define-grammar.js
+++ b/common/define-grammar.js
@@ -99,7 +99,7 @@ module.exports = function defineGrammar(dialect) {
new_expression: $ => prec.right(PREC.NEW, seq(
'new',
- field('constructor', $._constructable_expression),
+ field('constructor', $._primary_expression),
field('type_arguments', optional($.type_arguments)),
field('arguments', optional($.arguments))
)),
@@ -677,7 +677,6 @@ module.exports = function defineGrammar(dialect) {
'boolean',
'string',
'symbol',
- 'void',
'export',
previous
),I'm not sure why |
|
I'm battling npm issues. I thought I upgraded my dependency on tree-sitter-javascript, but I actually I didn't. I selected the commit in package.json as follows: After What do you use to depend on the correct version of a dependency, Edit: I was looking at the history of tree-sitter-typescript because |
|
ok, I'm still not sure about how |
* Fix for compatibility with tree-sitter-javascript tree-sitter/tree-sitter-javascript#138 (commit 3d54934) * Add optional chaining to 'call_expression', similar to what is done for the javascript grammar. Co-authored-by: Martin Jambon <Martin Jambon>
After merging #137, I realized that there was an even simpler solution to the problem of resolving conflicts between
new_expression,call_expression, and all of the optional-chaining rules:The
?.operator in acall_expressionshould have the same precedence as the?.and.operators in member expressions and subscript expressions.This avoids having a runtime conflict between
new_expressionandcall_expression, and I think is more intuitive than the previous solution. I've also done a bit of cleanup, including renaming_constructable_expressionto_primary_expression, since it is used in more places than justnew_expressionnow. So I think we'll have to do the same rename intree-sitter-typescript./cc @mjambon - I think this may simplify the work required for tree-sitter/tree-sitter-typescript#84.