textx中或子句内的前瞻断言失效问题咨询

这不是textX的bug，而是你在使用前瞻操作符和规则分支时踩了一个常见的误区，我来帮你拆解清楚其中的逻辑：

问题原因分析 #

先看你第一个语法的核心规则：

Sentence: 'foo' 'bar' ( '.' | &'end' );
Line: Block | Sentence;
Block: 'block' Line* 'end';

当解析block\nfoo bar end这段代码时，解析器的执行流程是这样的：

1. 先匹配block进入Block规则，开始处理Line*（即匹配任意数量的Line）。
2. 遇到foo bar，尝试匹配Line的Sentence分支：
   • 首先尝试匹配分支里的.，发现下一个符号是end，匹配失败。
   • 接着尝试&'end'前瞻断言——这个操作只是检查后面是否有end，不会消耗这个符号，所以断言匹配成功，Sentence规则完成。
3. 此时解析器会贪婪地继续尝试匹配Line*的下一个Line，但剩下的输入只有end，既无法匹配Block（需要block开头），也无法匹配Sentence（需要foo开头）。
4. 解析器回溯到Sentence的匹配决策点，试图寻找其他可行路径，但没有其他选项，最终抛出错误，提示期望.。

而你第二个语法把两种情况拆成了独立规则：

Line: Block | InnerSentence | Sentence;
Sentence: 'foo' 'bar' '.';
InnerSentence: 'foo' 'bar' &'end';

解析流程就顺畅了：

1. 同样先匹配block进入Block规则，处理Line*。
2. 遇到foo bar，依次尝试Line的分支：
   • Block分支不匹配，跳过。
   • 尝试InnerSentence分支，匹配foo bar并通过前瞻断言确认后面是end，匹配成功。
3. Line*完成匹配（没有更多Line可以匹配），接下来正好匹配Block的结束标记'end'，整个规则匹配成功。

为什么两种写法不等价？ #

textX的LL(*)解析器会按规则分支的顺序尝试匹配，并且默认是贪婪匹配——会尽可能多地消耗输入。在第一个语法中，Sentence把两种情况塞进同一个分支，解析器匹配&'end'后，会认为还有可能继续匹配更多Line，导致后续的end无法被Block的结束标记正确捕获。而第二个语法将两种场景拆分为独立规则，解析器匹配InnerSentence后，明确知道这是一个完整的Line，不会继续尝试额外的匹配，从而让后续的end顺利被Block规则处理。

修复第一个语法的替代方案 #

如果你不想拆分规则，也可以通过语义谓词明确告诉解析器，匹配&'end'后就停止Line的匹配：

Sentence: 'foo' 'bar' ( '.' | ( &'end' { _input.peek().value == 'end' } ) );

不过这种写法不如拆分规则直观，还是推荐你第二个语法的写法，可读性更强，也更符合textX的解析逻辑。

内容的提问来源于stack exchange，提问作者james.haggerty