[antlr-interest] Getting rid of class cast exceptions to CommonTree

Felix Dorner felix_do at web.de
Sat May 24 03:42:44 PDT 2008


Terence Parr wrote:
>
> On May 22, 2008, at 11:04 AM, Felix Dorner wrote:
>
>> >So probably not ANTLR's fault?
>> No, its in the generated code.. When I say antlr tries to.. I should 
>> really mean the runtime and not the generated code I guess.
>
> Well,I mean both runtime and tool when I say ANTLR. so, what specific 
> line or operation in the runtime is getting typecast problem.
> T
Terence,

I'm sorry being so imprecise. It is neither in the Tool, nor in the 
Runtime. It in the generated tree parser. I just was wondering what happens:

In the tree grammar I use this style to check for semantics, e.g for 
expressions:

expr:  ^(binop e1=expr e2=expr)
         {$e1.start.evalType() != null}?
         {$e2.start.evalType() != null}?
         $expr.start.evalType = validateExpr ($binop, e1.start e2.start);

validateEpr returns the Type of the whole expression. In case of an 
error, I return null and print out a useful error message. Further, I 
override reportError like this:

@Override
     public void reportError(RecognitionException e){     
         if (!( e instanceof FailedPredicateException )){
             // I expect only failed predicate exceptions,
             // anything else is a tampered ast... For a failed 
predicate, I already output a message, so ignore those
             Logger.logException(e);
         }
         errors.add(e);
     }

Now somehow in those predicates (after a failing preceding predicate) 
instead of an AST object, I get a CommonTreeNode with an Up or a down 
Token.. So there seems to be a sync problem during error recovery 
somehow. But I am really new, so might well be that I mess smth. up.

Thanks,
Felix










More information about the antlr-interest mailing list