"FOLLOW_set_in _" ... is undefined in the generated parser

Question

I wrote a grammar for an undefined Java-like DSL. Although there are still some problems with it (it does not recognize all the inputs as I would like), what worries me most is that the generated C code does not compile.

I am using AntlrWorks 1.5 with Antlr 3.5 (Antlr 4 does not seem to support target C).

The problem is the rules of expression. I have prio14Expression rules for prio0Expression that handle operator priority. The problem is priority 2, which evaluates the prefix and postfix operators:

... prio3Expression: prio2Expression (('*' | '/' | '%') prio2Expression)*; prio2Expression: ('++' | '--' | '!' | '+' | '-')* prio1Expression ('++' | '--')*; prio1Expression: prio0Expression ( ('.' prio0Expression) | ('(' (expression (',' expression)*)? ')') | ('[' expression (',' expression)* ']') )*; prio0Expression: /*('(') => */('(' expression ')') | IDENTIFIER | //collectionLiteral | coordinateLiteral | 'true' | 'false' | NUMBER | STRING ; ... 

The expression is a label for prio14Expression. You can see the full grammar here .

The code generation itself is successful (without any errors or serious warnings). It generates the following code:

 CONSTRUCTEX(); EXCEPTION->type = ANTLR3_MISMATCHED_SET_EXCEPTION; EXCEPTION->name = (void *)ANTLR3_MISMATCHED_SET_NAME; EXCEPTION->expectingSet = &FOLLOW_set_in_prio2Expression962; RECOVERFROMMISMATCHEDSET(&FOLLOW_set_in_prio2Expression962); goto ruleprio2ExpressionEx; 

What is not built with the error " Error 5 error C2065: 'FOLLOW_set_in_prio2Expression962' : undeclared identifier ".

Did I do something wrong in the grammar? No other rules cause this error, and if I reformulate the corresponding rule a little, the generated code will be valid (but then the grammar will not do what I want). What can I do to fix this problem?

Thanks for any help.

Answer 1

I ran into the same problem.

I think this happens if the parser rule has part of a simple OR-ed token like this:

 problem_case: problematic_rule; problematic_rule: 'A' | 'B' ; 

This does not happen if it is a lexer rule.

 workaround1: As_lexer_rule; As_lexer_rule: 'A' | 'B' ; 

Or, if this is a complex rule (not a simple OR-ed token).

 workaround2: make_it_complicated_needlessly; make_it_complicated_needlessly: 'A' | 'B' | {false}? NeverUsedRule; NeverUsedRule: /* don't care*/ ; 

(I used the semantic predicate "{false}?" For this modification. I believe that this does not change the grammar of the target language.)

Answer 2

this seems to be an old post, but still maybe it is still useful for someone (as it was for me).

I ran into the same issue with C antlr 3.5 runtime.

Another easy workaround that doesn't change the grammar:

 problem_case: problematic_rule; problematic_rule: a='A' | b='B' ;