Lark LALR语法解析RISC-V Trace转CSV的正则匹配异常问题

你的DECODED_INSTRUCTION正则匹配失败，核心原因是前瞻终止条件覆盖不全以及行尾匹配逻辑未适配Lark的正则默认行为，具体问题和解决方法如下：

常见问题点 #

1. 前瞻条件未覆盖所有后续字段
   如果你只在前瞻中判断了REG:，但Trace行后续还可能出现MEM:、CYCLE:等其他字段，正则会因为找不到REG:而持续匹配，直到超出DECODED_INSTRUCTION的范围，导致后续语法规则无法识别后续字段的字符。

2. 行尾匹配逻辑失效
   Lark的正则默认是单行模式，此时$匹配的是整个输入文本的结尾，而非单条Trace行的行尾。如果你的解析逻辑是逐行处理Trace输出，$无法正确匹配单行的末尾，导致无后续字段的行匹配失败。

3. 非贪婪匹配的回溯问题
   即使使用了.*?非贪婪匹配，若前瞻条件不满足，正则会回溯并尝试匹配更多内容，最终覆盖后续字段的起始字符，引发“无法识别字符”的错误。

修正后的正则规则 #

针对上述问题，调整正则如下（替换你原有的DECODED_INSTRUCTION规则）：

DECODED_INSTRUCTION: /.*?(?=\s+(?:REG:|MEM:|CYCLE:)|(?=\n|$))/

规则说明 #

• \s+(?:REG:|MEM:|CYCLE:)：匹配后续所有可能的字段前缀（根据你的Trace实际字段扩展括号内的内容），确保正则在遇到任何后续字段时停止匹配。
• (?=\n|$)：同时匹配换行符或输入结尾，解决单行模式下无法匹配行尾的问题，覆盖无后续字段的末尾行场景。
• .*?：保持非贪婪匹配，避免过度回溯。

如果你的Trace输出是严格逐行分隔的，也可以开启多行模式让$匹配行尾，写法如下：

DECODED_INSTRUCTION: /(?m).*?(?=\s+(?:REG:|MEM:|CYCLE:)|$)/

(?m)是正则的多行模式标记，开启后$会匹配每一行的行尾而非整个输入的结尾。

额外验证建议 #

• 测试边界场景：分别验证有REG字段、有MEM字段、无任何后续字段的Trace行，确保正则都能正确截断DECODED_INSTRUCTION的内容。
• 检查字段前缀：确认你列出的所有后续字段前缀和Trace输出完全一致（注意大小写、空格等细节）。

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