CODEWITHSUNDEEP
antlrantlr4
phil
phil

Reputation: 1359

antlr 4 - warning: rule contains an optional block with at least one alternative that can match an empty string

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

"rule 'sqlCommit' contains an optional block with at least one alternative that can match an empty string"

My Code:

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 a version before I used directly the lexer rule ID instead of the parser rule id in sqlCommit. But after change ID to id the warning appears.

(Hint if you are confused of ID and id: I want to use the parser rule id instead of ID because an identifier can be a literal which maybe already matched by an other lexer rule)

Regards

EDIT With the help of "280Z28" I solved the problem. In the parser rule "id" was one slash more than needed: BITTYPE|CREATE|PROC| |AS|EXEC|OUTPUT|

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

Upvotes: 8

Views: 4631

Answers (2)

pfa
pfa

Reputation: 135

I'm struggling to see how this rule also suffers from this warning (with antlr 4.7.1)

join_type: (INNER | (left_right_full__join_type)? (OUTER)?)? JOIN;

left_right_full__join_type: LEFT | RIGHT | FULL;

JOIN:        J O I N;
INNER:       I N N E R;
OUTER:       O U T E R;

AFAICT it always returns JOIN and optionally preceded by the type.

Upvotes: 0

Sam Harwell
Sam Harwell

Reputation: 99889

From a Google search:

ErrorType.EPSILON_OPTIONAL

Compiler Warning 154.

rule rule contains an optional block with at least one alternative that can match an empty string

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

The following rule produces this warning.

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

Since:
4.1

The problem described by this warning is primarily a performance problem. By wrapping a zero-length string in an optional block, you added a completely unnecessary decision to the grammar (whether to enter the optional block or not) which has a high likelihood of forcing the prediction algorithm through its slowest path. It's similar to wrapping Java code in the following:

if (slowMethodThatAlwaysReturnsTrue()) {
  ...
}

Upvotes: 8

Related Questions