在寻找问题的解决方案时,我得到了 this question ,建议使用复合语法来消除代码太大
。问题在那里,我已经在使用语法导入,但是当我进一步扩展导入的语法之一时,根解析器语法显示错误。显然,问题在于ANTLR在分析整个语法后生成的许多标记和DFA定义。有没有办法/建议的方法来摆脱这个问题?它是否具有可扩展性,即它是否不依赖于足够小的变通办法所改变的部分?
编辑:为了明确这一点(链接的问题没有明确说明):代码太大
错误是生成的解析器代码上的编译器错误,据我了解,通常是由于语法太大而导致某些代码大于java规范的限制。就我而言,它是根解析器类的静态初始化程序,其中包含大量 DFA 前瞻变量,所有这些都会在初始化程序中生成代码。因此,理想情况下,ANTLR 应该能够在语法太大/用户告诉 ANTLR 这样做的情况下将其拆分。有这样的选择吗?
(我必须承认,链接问题的提问者有一个......有趣的规则,导致他的语法膨胀,这可能也是我的错误。但是可能性这不是语法作者的错误(在任何大型语法中),所以我认为这是一个有效的、非语法特定的 ANTLR 问题)
编辑结束
我的语法解析“Magic the Gathering”规则文本并可用 here ( git )。当将 this file 中的第 33 行替换为 34-36 时,该问题尤其出现。 。我使用 Maven 和 antlr3-maven-plugin 进行构建,所以理想情况下,使用该插件可以解决此问题,但如果不是,那问题比我现在遇到的问题要小......
非常感谢,我希望我没有看到任何对我有帮助的明显文档。
最佳答案
fragment
关键字只能在词法分析器规则之前使用,不能在解析器规则之前使用,正如我所见。首先在所有语法中更改它(我只查看了ObjectExpressions.g
)。不幸的是,当您尝试时 ANTLR 不会产生错误。但请相信我:这是错误的,并且可能会导致您的(部分)问题。
此外,第 34-36 行的规则:
qualities
: qualities0
| qualities0 (COMMA qualities0)+ -> qualities0+
| qualities0 (Or qualities0)+ -> ^(Or qualities0+)
;
应重写为:
qualities
: qualities0 (COMMA qualities0)* -> qualities0+
| qualities0 (Or qualities0)+ -> ^(Or qualities0+)
;
编辑
So, Ideally, ANTLR should be able to split that up in the case that the grammar is too big/the user tells ANTLR to do it. Is there such an option?
不,不幸的是没有这样的选项。您必须将语法分成(甚至更多)更小的语法。
关于java - ANTLR:解决根语法的静态初始化程序中代码太大的问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8000972/