[antlr-interest] Antlr 3.3 upgrade woes

Andreas Stefik stefika at gmail.com
Wed May 18 09:15:56 PDT 2011


Well, I've rolled our trunk back to the 3.1 version of antlr and
everything works again. I still don't know why 3.3 is causing problems
on our project, but at least things are working.

Stefik

On Mon, May 16, 2011 at 3:29 PM, Andreas Stefik <stefika at gmail.com> wrote:
> Hi folks,
>
> I've finally upgraded my little interpreter from Antlr 3.1 to Antlr
> 3.3, but I'm getting different behavior in the treewalkers than I did
> before and I'm not quite sure what to make of it. Specifically, I have
> a rule for parsing if statements in my grammar. It's nothing fancy,
> but here is a snippet:
>
> IF condition = root_expression if_then = THEN
> {
> //do some processing on the expressions
> process_this( $condition.eval.getType(), $condition.step);
> }
>
> What's odd, however, is that in  antlr 3.3, the values I pass into the
> condition in my returns statement seem to be null under conditions
> that I have not been able to ascertain. For example, in the "Object"
> class in my language, I have the following method:
>
> action Compare(Object object) returns CompareResult
>        CompareResult result
>        integer myHash = this:GetHashCode()
>        integer oHash = object:GetHashCode()
>
>        if(myHash < oHash) then
>            result:result = result:SMALLER
>        end else if myHash = oHash then
>            result:result = result:EQUAL
>        end else then
>            result:result = result:LARGER
>        end
>        return result
>    end
>
> And Antlr fails when it tries to process if(myHash < oHash) then in
> the tree walker. However, if I take basically the same code and place
> it into another method (e.g., or call it from somewhere, adjust it,
> really anything I've thought of), for example:
>
> action Main
>        CompareResult result
>        integer myHash = this:GetHashCode()
>        integer oHash = this:GetHashCode()
>        if myHash < oHash then
>        end
>    end
>
> The exact same comparison does not fail. So far as I can tell, both
> work correctly in Antlr 3.1. So, a few questions:
>
> 1. Did anything change between these versions that might cause
> something like this?
>
> 2. Did anything change with the way "returns" are done? I didn't
> notice anything in the documentation, but my expression rules in the
> tree grammar do lots of stuff like this:
>
> expression      returns[ExpressionValue eval, ExecutionStep step]
>        :
>                NOT expr = expression
>        {
>                //do some processing
>                $eval = result.getValue();
>                $step = result.getStep();
>        }
> Do I need to change this to be 3.3 compatible in some way?
>
> Any tips would be appreciated,
>
> Stefik
>


More information about the antlr-interest mailing list