descargar - antlr4 github

¿Es la "definición de token implícita en la regla del analizador" algo de qué preocuparse?

Question

Estoy creando mi primera gramática con ANTLR y ANTLRWorks 2. Principalmente he terminado la gramática (reconoce el código escrito en el lenguaje descrito y construye los árboles de análisis correctos), pero no he comenzado nada más allá de eso.

Lo que me preocupa es que cada vez que aparece un token en una regla del analizador está subrayado con un garabato amarillo que dice "Definición de token implícita en la regla del analizador".

Por ejemplo, en esta regla, la ''var'' tiene ese garabato:

variableDeclaration: ''var'' IDENTIFIER (''='' expression)?;

Cómo se ve exactamente:

Lo extraño es que a ANTLR en sí no le importan estas reglas (al realizar una prueba de instalación, no puedo ver ninguna de estas advertencias en la salida del generador del analizador, solo algo sobre la instalación de una versión incorrecta de Java en mi máquina). Así que solo es ANTLRWorks quejándose.

¿Es algo de qué preocuparse o debo ignorar estas advertencias? ¿Debo declarar todos los tokens explícitamente en las reglas de lexer? La mayoría de los ejemplos en la biblia oficial. La referencia de ANTLR Defintive parece que se hace exactamente de la misma manera que escribo el código.

Answer 1

Si está escribiendo una gramática lexer que no se usaría en múltiples gramáticas del analizador, entonces puede ignorar esta advertencia mostrada por ANTLRWorks2.

Answer 2

Recomiendo encarecidamente corregir todas las instancias de esta advertencia en el código de importancia.

Esta advertencia fue creada (en realidad por mí) para alertarte sobre situaciones como las siguientes:

shiftExpr : ID ((''<<'' | ''>>'') ID)?;

Dado que ANTLR 4 recomienda que el código de acción se escriba en archivos separados en el idioma de destino en lugar de incluirlos directamente en la gramática, es importante poder distinguir entre << y >> . Si los tokens no se crearon explícitamente para estos operadores, se les asignarán tipos arbitrarios y no habrá constantes con nombre para hacer referencia a ellos.

Esta advertencia también ayuda a evitar las siguientes situaciones problemáticas:

• Una regla de analizador contiene una referencia de token mal escrita. Sin la advertencia, esto podría llevar a la creación silenciosa de un token adicional que nunca puede ser igualado.

• Una regla de analizador contiene una referencia de token no intencionada, como la siguiente:

  number : zero | INTEGER;
  zero : ''0''; // <-- this implicit definition causes 0 to get its own token