Generating bad sempred method

[parrt]

The resulting grammar is accepted by latest Honey Badger (the one pulled from parrt/antlr). However, the resulting parser contains errors: an unused sempred method with errors is produced. Since it is unused, I simply deleted it. However, the parser still does not match the input correctly. I guess both things have are symptoms of the same bug.

Here is (a simplified version of) the grammar producing the erroneous parser:

rule returns [String r]
   :  t=ID  ':' alts+=expr ('|' alts+= expr)* ';'
       {  $r = "x"; }
   ;

strongExpr returns [String r]
   : ID                      { $r = "x"; }
   | '(' ep=parenExpr ')'               { $r = "x"; }
   | e1=strongExpr '?'             { $r = "x"; }
   ;

expr returns [String r]
   : e=strongExpr (e2=expr)? { $r = "x"; }
   | e1=expr '->' ID {$r = "x"; }
   ;

parenExpr returns [String r]
   : e1=expr '|' e2=parenExpr { $r = "x"; }
   | expr              {$r = $expr.r; }
   ;

ID  :   ('A'..'Z'|'a'..'z'|'_') ('a'..'z'|'A'..'Z'|'0'..'9'|'_')*
     ;

the resulting unused sempred with errors:

public boolean sempred(RuleContext _localctx, int ruleIndex, int predIndex) {
    switch ( ruleIndex ) {
    case 1 : return strongExpr_sempred((StrongExprContext)_localctx, predIndex);    
    case 2 : return expr_sempred((ExprContext)_localctx, predIndex);
    }
    return true;
}

The problems are the casts (StrongExprContext)_localctx and (ExprContext)_localctx, since _localctx is a RuleContext here. As mentioned, the sempred is not called anyway.

[sharwell]

The example grammar contains an LR rule (expr) containing a left-edge rule reference to a different LR rule (strongExpr). However, since strongExpr does not contain a left-edge rule reference back to expr, the grammar after LR translation does not contain any left recursion so it could be correctly generated. Whether or not ANTLR will support LR rules invoking other LR rules is left to be determined.

The tool should either generate working code or produce an error message and fail to generate code.

[JFinis]

is it possible to fix this issue in the near future? It is a real blocker for my current project (yes, I know, I should not depend on an ea version ;).

@sharwell: Ter stated that only mutually left recursive rules are forbidden. The example is not mutually left recursive, so it should compile fine.

[parrt]

ha! I just figured this out!!! don't use rule as a rule name because it becomes RuleContext which is the predefined context object.

[JFinis]

great, the sempred is gone. I guess you should disallow rules with that name. However, the generated parser still does not work, see the new issue: #45

[sharwell]

I created #77 to address the naming problems.