[antlr-interest] Rewrite bug?

[Surj Basan]

Hi,

No replies yet, so I'm guessing I've either missed something or this is a
genuine bug.

If anyone knows, could you send a quick reply so I can move forward.

To recap: ANTLR is producing code that does not have a variable declaration
in the Parser.

Thanks,
Surj

On 16 July 2012 07:24, Surj Basan <s.basan at surge.it> wrote:

> Hi All,
>
> I have a Java grammar (taken from the openjdk, one linked off
> the ANTLR site:
> http://openjdk.java.net/projects/compiler-grammar/antlrworks/Java.g).
>
> One of the rewrite rules produces Java code which does not have a var
> decl, and so does not compile.
>
> I took the rule straight out of Terrence Parr's page on rewrite rules and
> added it to the grammar (
> http://www.antlr.org/wiki/display/ANTLR3/Tree+construction, paragraph
> beginning "Using a rewrite rule at a non-extreme-right-edge-of-production
> location is ok..").
>
> Can someone explain if this is a bug in ANTLR? Code is below, for ref.
>
> Grammar rule:
>
> statement
>     :   [more rules here]
>     |   'if' parExpression s1=statement ('else' s2=statement -> ^('if'
> parExpression $s1 $s2)
>                                         |                      -> ^('if'
> parExpression $s1)
>                                         )
>     [more rules here]
>     ;
>
>
> Generated parser code:
>
>     // $ANTLR start synpred139_AntlrJava
>     public final void synpred139_AntlrJava_fragment() throws
> RecognitionException {
>         void  =null;
>
>
>         // AntlrJava.g:926:42: ( 'else' s2= statement )
>         // AntlrJava.g:926:42: 'else' s2= statement
>         {
>
> match(input,KEYWORD_ELSE,FOLLOW_KEYWORD_ELSE_in_synpred139_AntlrJava4927);
> if (state.failed) return ;
>
>         pushFollow(FOLLOW_statement_in_synpred139_AntlrJava4931);
>         s2=statement();
>
>         state._fsp--;
>         if (state.failed) return ;
>
>         }
>
>     }
>
> (For what it's worth, I find that various permutations of rewrite rules
> exhibit the same behaviour: missing var decls in the generated parser.
> Java.g is a pretty complex grammar. Would I have more luck if I split the
> grammar into the lexer/parser and a separate tree building one, instead of
> combining it all into a single file?)
>
> Any help greatly appreciated.
>
> Thanks,
> Surj
>