问题描述
我正在使用ANTLR和ANTLRWorks 2创建我的第一个语法.我基本上已经完成了语法本身(它可以识别用所描述的语言编写的代码并构建正确的解析树)，但是我还没有开始做任何其他事情.
I'm creating my first grammar with ANTLR and ANTLRWorks 2. I have mostly finished the grammar itself (it recognizes the code written in the described language and builds correct parse trees), but I haven't started anything beyond that.
让我担心的是，在解析器规则中第一次出现令牌时，都会用黄色的下划线标出在解析器规则中隐含令牌定义".
What worries me is that every first occurrence of a token in a parser rule is underlined with a yellow squiggle saying "Implicit token definition in parser rule".
例如，在此规则中，'var'具有该形式:
For example, in this rule, the 'var' has that squiggle:
variableDeclaration: 'var' IDENTIFIER ('=' expression)?;
它的外观如何:
奇怪的是，ANTLR本身似乎并不介意这些规则(在进行测试装备测试时，我在解析器生成器的输出中看不到这些警告中的任何警告，只是关于在我的计算机上安装了不正确的Java版本的信息机器)，所以这只是ANTLRWorks的抱怨.
The odd thing is that ANTLR itself doesn't seem to mind these rules (when doing test rig test, I can't see any of these warning in the parser generator output, just something about incorrect Java version being installed on my machine), so it's just ANTLRWorks complaining.
是要担心的事情还是应该忽略这些警告?我应该在词法分析器规则中明确声明所有标记吗?官方圣经中的大多数例句最终的ANTLR参考似乎完全按照我编写代码的方式来完成.
Is it something to worry about or should I ignore these warnings? Should I declare all the tokens explicitly in lexer rules? Most exaples in the official bible The Defintive ANTLR Reference seem to be done exactly the way I write the code.
推荐答案
我强烈建议以任何重要的代码纠正此警告的所有实例.
此警告是由我创建的，实际上是为了提醒您类似以下情况:
This warning was created (by me actually) to alert you to situations like the following:
shiftExpr : ID (('<<' | '>>') ID)?;
由于ANTLR 4鼓励以目标语言在单独的文件中编写操作代码，而不是将它们直接嵌入语法中，因此能够区分<<和>>是很重要的.如果没有为这些运算符显式创建标记，则将为它们分配任意类型，并且没有命名常量可用于引用它们.
Since ANTLR 4 encourages action code be written in separate files in the target language instead of embedding them directly in the grammar, it's important to be able to distinguish between << and >>. If tokens were not explicitly created for these operators, they will be assigned arbitrary types and no named constants will be available for referencing them.
此警告还有助于避免以下有问题的情况:
This warning also helps avoid the following problematic situations:
- 解析器规则包含拼写错误的令牌引用.如果没有警告，这可能会导致静默创建可能永远不会匹配的其他令牌.
-
解析器规则包含无意的令牌引用，例如:
- A parser rule contains a misspelled token reference. Without the warning, this could lead to silent creation of an additional token that may never be matched.
A parser rule contains an unintentional token reference, such as the following:
number : zero | INTEGER;
zero : '0'; // <-- this implicit definition causes 0 to get its own token
这篇关于是“解析器规则中的隐式令牌定义"吗?有什么需要担心的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！