Ezno 项目中构造函数调用泛型参数解析问题分析

在 TypeScript 语法解析过程中，Ezno 项目遇到了一个关于构造函数调用时泛型参数处理的解析错误。这个问题涉及到语法树构建时的优先级处理和节点类型判断，值得深入探讨其技术细节。

当解析类似 new Y<3>(3) 这样的表达式时，解析器生成的语法树结构出现了异常。理想情况下，这应该被解析为一个带有泛型类型参数的构造函数调用，但实际输出却显示解析器将泛型参数错误地关联到了函数调用部分，而非构造函数部分。

从技术实现来看，问题核心出在表达式解析模块的优先级处理逻辑上。在解析构造函数调用时，解析器需要正确处理以下几种情况：

1. 构造函数标识符
2. 可选的泛型类型参数
3. 构造函数参数列表

当前实现中，解析器错误地将泛型参数<3>绑定到了函数调用节点，而非构造函数调用节点。这导致生成的语法树结构中，构造函数调用节点(ConstructorCall)的type_arguments字段为空，而其内部的函数调用节点(FunctionCall)却包含了类型参数。

这种解析错误会影响后续的语义分析阶段，因为类型检查器无法正确获取构造函数的泛型参数信息。在TypeScript中，构造函数泛型参数的正确解析对于类型推断和检查至关重要。

解决方案需要调整解析器在处理构造函数调用时的优先级逻辑，确保：

1. 泛型参数正确关联到构造函数调用节点
2. 保持与标准TypeScript解析行为的一致性
3. 不破坏现有其他表达式的解析

该问题的修复涉及解析器表达式处理模块的修改，特别是关于构造函数调用和泛型参数解析的交互逻辑。正确的实现应该能够区分普通函数调用的泛型参数和构造函数调用的泛型参数，并在语法树中正确反映这种区别。

对于开发者而言，理解这种解析差异有助于更好地处理TypeScript中复杂的泛型表达式，特别是在涉及构造函数和类型参数组合使用的场景下。这也提醒我们在实现编程语言解析器时，需要特别注意各种语法结构的优先级和关联性处理。