[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