Antlr 4 - warning: the rule contains an optional block with at least one alternative that may correspond to an empty string

Question

I am working with antlr v4 to write a t-sql parser. Is this warning a problem?

"sqlCommit rule contains an optional block with at least one alternative that may correspond to an empty string

My code is:

sqlCommit: COMMIT (TRAN | TRANSACTION | WORK)? id?; id: ID | CREATE | PROC | AS | EXEC | OUTPUT| INTTYPE |VARCHARTYPE |NUMERICTYPE |CHARTYPE |DECIMALTYPE | DOUBLETYPE | REALTYPE |FLOATTYPE|TINYINTTYPE|SMALLINTTYPE|DATETYPE|DATETIMETYPE|TIMETYPE|TIMESTAMPTYPE|BIGINTTYPE|UNSIGNEDBIGINTTYPE.......... ; ID: (LETTER | UNDERSCORE | RAUTE) (LETTER | [0-9]| DOT | UNDERSCORE)* 

In the version, before I used the lexer rule identifier directly instead of the parser rule identifier in sqlCommit. But after changing the ID to id, a warning appears.

( Hint , if you are confused about the ID and id: I want to use the identifier of the analyzer rule instead of ID, because the identifier may be a literal, which may already correspond to another lexer rule)

Hello

EDIT Using "280Z28" I solved the problem. There was one more slash in the id id parser rule than needed: BITTYPE | CREATE | PROC | | AS | EXEC | OUTPUT |

So | | includes that the parser rule may match an empty string.

Answer 1

From google search:

ErrorType.EPSILON_OPTIONAL

Compiler Warning 154.

Rule rule

contains an optional block with at least one option that may correspond to an empty string

A rule contains an optional block ( (...)? ) Around an empty alternative.

The following rule throws this warning.

 x : ; y : x?; // warning 154 z1 : ('foo' | 'bar'? 'bar2'?)?; // warning 154 z2 : ('foo' | 'bar' 'bar2'? | 'bar2')?; // ok 

WITH:
4.1

The issue described in this warning is primarily a performance issue. By wrapping a zero-length string in an optional block, you have added a completely unnecessary solution to the grammar (whether it is an optional block or not), which has a high probability of forcing the prediction algorithm through the slowest path. This is similar to wrapping Java code in the following:

 if (slowMethodThatAlwaysReturnsTrue()) { ... }