Skip to content

Conversation

@rusiaaman
Copy link

@rusiaaman rusiaaman commented Jun 2, 2025

Problem

Fixes #329

The parser was inconsistently handling code containing instantiation expressions followed by template literals (e.g., sql<never[]>`'[]'`). Removing certain lines from the code would cause the entire file to fail parsing, while keeping those lines would result in successful parsing with only minor warnings.

Root Cause

The issue was in the call_expression rule for template calls in /common/define-grammar.js. The template call rule only allowed primary_expression or new_expression as the function, but sql<never[]> is an instantiation_expression, which wasn't included in the allowed choices.

Solution

Modified the template call rule to include $.instantiation_expression:

// Before: prec('template_call', seq( field('function', choice($.primary_expression, $.new_expression)), field('arguments', $.template_string), )), // After: prec('template_call', seq( field('function', choice($.primary_expression, $.new_expression, $.instantiation_expression)), field('arguments', $.template_string), )),
Fixes tree-sitter#329 The issue was that template call expressions only allowed primary_expression or new_expression as the function, but instantiation expressions like `sql<Type[]>`template`` were not supported. This change adds $.instantiation_expression to the allowed function types for template calls, enabling proper parsing of patterns like: - sql<never[]>`'[]'` - tag<string>`Hello ${name}` - func<Type[]>`SELECT * FROM table` Testing shows this resolves the parsing inconsistency where removing certain lines would cause the entire file to fail parsing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant