Tree Sitter解析遇错未回溯尝试备选路径问题求助

Tree Sitter的回溯行为由它的增量解析设计和有限GLR策略决定，核心规则是：它不会在已经消耗了token的分支失败后，回溯到之前的位置尝试其他choice选项——只有当某个分支从一开始就完全匹配失败（未消耗任何token）时，才会自动尝试下一个备选分支。

具体分析你的两种场景： #

1. 失败的破坏场景（seq部分匹配后出错）

当你使用以下规则时：

pattern: $ => choice(
  '1 -> 1',
  seq($._pattern_lhs, $.arrow_symbol, 'howdydoody', $._block),
)

解析器的执行逻辑是：

• 优先尝试第二个seq分支，先成功匹配_pattern_lhs（消耗了输入中的1），接着匹配arrow_symbol（消耗了->），此时已经消耗了两个关键token。
• 后续遇到的1无法匹配'howdydoody'，分支失败。但Tree Sitter不会回溯到with之后的初始位置去尝试第一个'1 -> 1'选项——因为前置的1和->已经被消耗，无法被重新匹配。为了保证增量解析的性能，Tree Sitter不做这种“回退已消耗token”的深度回溯，而是标记错误后继续向后解析。

2. 成功的破坏场景（seq从开头就匹配失败）

当你使用以下规则时：

pattern: $ => choice(
  '1 -> 1',
  seq('lol', $._pattern_lhs, $.arrow_symbol, $._block)),

解析器尝试第二个seq分支时，第一个token'lol'就和输入的1不匹配，没有消耗任何token，所以直接放弃这个分支，转而尝试第一个'1 -> 1'选项，最终完整匹配成功。

关键结论 #

Tree Sitter的choice分支尝试逻辑可以总结为：

• 若当前分支未消耗任何token就匹配失败，立即尝试下一个分支；
• 若当前分支已经消耗了token后匹配失败，不会回溯到分支开始前的位置，而是保留已匹配的部分，标记后续错误并继续解析。

这种设计是为了平衡解析速度和容错性，毕竟Tree Sitter的核心目标是支持编辑器的增量语法高亮和代码导航，而非像传统GLR解析器那样做完全回溯式的语法分析。

内容的提问来源于stack exchange，提问作者user1713450