AST with fixed nodes instead of error nodes in antlr

I have an antlr generated Java parser th开发者_如何学Pythonat uses the C target and it works quite well. The problem is I also want it to parse erroneous code and produce a meaningful AST. If I feed it a minimal Java class with one import after which a semicolon is missing it produces two "Tree Error Node" objects where the "import" token and the tokens for the imported class should be.

But since it parses the following code correctly and produces the correct nodes for this code it must recover from the error by adding the semicolon or by resyncing. Is there a way to make antlr reflect this fixed input it produces internally in the AST? Or can I at least get the tokens/text that produced the "Tree Node Errors" somehow?

In the C targets antlr3commontreeadaptor.c around line 200 the following fragment indicates that the C target only creates dummy error nodes so far:

static  pANTLR3_BASE_TREE
errorNode                               (pANTLR3_BASE_TREE_ADAPTOR adaptor,   pANTLR3_TOKEN_STREAM ctnstream, pANTLR3_COMMON_TOKEN startToken, pANTLR3_COMMON_TOKEN stopToken, pANTLR3_EXCEPTION e)
{
    // Use the supplied common tree node stream to get another tree from the factory
    // TODO: Look at creating the erronode as in Java, but this is complicated by the
    // need to track and free the memory allocated to it, so for now, we just
    // want something in the tree that isn't a NULL pointer.
    //
    return adaptor->createTypeText(adaptor, ANTLR3_TOKEN_INVALID, (pANTLR3_UINT8)"Tree Error Node");
}

Am I out of luck here and only the error nodes the Java target produces would allow me to retrieve the text of the erroneous nodes?

I haven't used antlr much, but typically the way you handle this type of error is to add rules for matching wrong syntax, make them produce error nodes, and try to fix up after errors so that you can keep parsing. Fixing up afterwards is the problem because you don't want one error to trigger more and more errors for each new token until the end.

I solved the problem by adding new alternate rules to the grammer for all possible erroneous statements.

Each Java import statement gets translated to an AST subtree with the artificial symbol IMPORT as the root for example. To make sure that I can differentiate between ASTs from correct and erroneous code the rules for the erroneous statements rewrite them to an AST with a root symbol with the prefix ERR_, so in the example of the import statement the artifical root symbol would be ERR_IMPORT.

More different root symbols could be used to encode more detailed information about the parse error.

My parser is now as error tolerant as I need it to be and it's very easy to add rules for new kinds of erroneous input whenever I need to do so. You have to watch out to not introduce any ambiguities into your grammar, though.