Angular ESLint模板解析器中的Call表达式接收器遍历问题解析

问题背景

在Angular模板开发中，Angular ESLint工具链的@angular-eslint/template-parser包负责解析模板语法并生成抽象语法树(AST)。最近发现该解析器在处理函数调用表达式(Call Expression)时存在一个关键缺陷——它未能正确遍历调用表达式的接收器(receiver)部分。

问题表现

这个缺陷会导致一些重要的模板校验规则失效，特别是template/no-call-expression规则。例如：

<!-- 当allowList设置为['ok']时，notOk()调用不会被检测到 -->
{{ notOk().ok() }}

<!-- 嵌套调用本应报告多个错误，但只产生一个 -->
{{ foo().bar() }} {{ foo()() }}

技术原理分析

在AST遍历过程中，ESLint依赖于visitorKeys配置来确定应该访问AST节点的哪些属性。当前@angular-eslint/template-parser在处理Call表达式时，没有正确配置接收器部分的访问键(visitor keys)，导致ESLint跳过了这部分节点的遍历。

具体来说，一个典型的Call表达式AST节点结构包含：

• callee：被调用的函数或方法
• arguments：调用参数
• receiver：方法调用的接收对象(在链式调用中尤为重要)

当前的实现中，getFallbackKeys函数逻辑存在缺陷，未能正确处理接收器节点的类型信息，导致遍历过程不完整。

影响范围

这个缺陷主要影响以下场景：

1. 链式方法调用校验
2. 嵌套函数调用校验
3. 任何依赖完整AST遍历的模板分析规则

特别是安全相关的规则，可能会因为部分调用未被检测到而产生潜在的安全漏洞。

解决方案

修复方案相对直接，需要完善visitorKeys配置，确保包含Call表达式的所有关键部分：

1. 显式添加Call表达式的访问键配置
2. 确保接收器节点类型信息正确设置
3. 完善测试用例覆盖链式调用场景

测试挑战

在实现修复过程中，测试工具convertAnnotatedSourceToFailureCase在处理多个错误位置重叠时存在局限性。理想情况下，我们希望标记如下的错误范围：

{{ foo()() }}
   ~~~~~    [第一个错误]
   ^^^^^^^  [第二个错误]

但目前测试工具尚不支持这种精确的多重错误定位表示方式。

总结

这个问题的修复将显著提升Angular模板静态分析的准确性，特别是对于复杂函数调用链的检测能力。开发者在升级后应该注意检查之前可能被忽略的非法调用模式，确保模板代码的质量和安全性。