用rust-peg写Go解析器遇if语句问题：语法二义性还是库问题？

嘿，我来帮你拆解下这个问题——这不是rust-peg库的bug，而是你的语法设计踩了PEG解析器的几个常见陷阱，具体来说有这几个核心问题：

1. 间接左递归导致无限递归 #

PEG解析器（包括rust-peg）本质是递归下降实现的，天生不支持左递归，不管是直接还是间接的。你的语法里藏着一条间接左递归链：
stmt → if_stmt → expression → block → stmt
当解析器尝试匹配stmt时，会进入if_stmt，接着找expression，如果匹配到带block的分支，又会回到stmt，无限循环下去，最后要么栈溢出，要么解析超时。这是PEG的核心特性，不是库的问题。

2. expression规则的歧义破坏了if_stmt结构 #

看你的expression规则：

expression = "x" sep block / "x"

PEG是左优先匹配，一旦匹配上左边的分支就不会回溯。比如当你输入if x { x }时，解析器会把x { x }整个当成expression（匹配第一个分支），而不是把x作为if_stmt的表达式、{x}作为它的块——这直接破坏了if_stmt的结构，导致后续匹配失败。

而且从Go语法的逻辑来说，表达式本身也不应该直接包含块，块是语句的容器，这个规则设计本身就不符合常规语法的分层逻辑。

3. 块规则的空格处理逻辑有瑕疵 #

你的block规则：

block = "{" ( sep stmt )* "}"

这个规则允许{stmt}（前面没空格）或者{ stmt stmt }（语句之间没空格），但实际语法里我们希望块内语句之间有分隔符。调整成block = "{" sep ( stmt sep )* "}"会更合理，既能允许块内前后的空格，又能确保语句之间有分隔。

针对这些问题，调整后的语法应该是这样（消除左递归，明确语法分层）：

sep = ( " " / "\n" )*
// 先定义最基础的表达式单元，避免和块混淆
primary_expr = "x"
// 表达式就是基础单元，和块解耦
expression = primary_expr
// 先匹配简单的表达式，再匹配复杂的if语句，打破左递归链
stmt = expression / if_stmt
if_stmt = "if" sep expression sep block
// 优化块内的空格和语句分隔逻辑
block = "{" sep ( stmt sep )* "}"
pub file = sep ( stmt sep )*

如果你以后再遇到类似问题，可以给rust-peg的规则加上#[trace]属性，这样能看到解析器每一步的匹配尝试，快速定位是哪里的规则冲突或者递归问题。

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