ANTLR extraneous input at first position doesn't build tree - parsing

Question

I have a problem with a extranous input in my sample file. I got the following lexer:
lexer grammar CtoLexer;
ENUM: 'enum';
NAMESPACE: 'namespace';
LBRACE: '{';
RBRACE: '}';
DOT: '.';
VAR: 'o ';
IDENTIFIER: LetterOrDigit+;
fragment LetterOrDigit
: [a-zA-Z$_] | [0-9];
WS: [ \t\r\n\u000C]+ -> skip;
... and parser:
parser grammar CtoParser;
options { tokenVocab=CtoLexer; }
modelUnit
: namespaceDeclaration enumDeclaration* EOF;
namespaceDeclaration
: NAMESPACE IDENTIFIER ('.' IDENTIFIER)*;
enumDeclaration
: ENUM IDENTIFIER '{' enumConstant* '}';
enumConstant
: VAR IDENTIFIER;
This is my sample cto file:
namespace org.basic.sample
enum FooType {
o FOO
}
enum BarType {
o BAR
}
enum BazType {
o BAZ
}
The tree for this sample file looks like this:
(modelUnit
(namespaceDeclaration namespace org . basic . sample)
(enumDeclaration enum FooType { (enumConstant o FOO) })
(enumDeclaration enum BarType { (enumConstant o BAR) })
(enumDeclaration enum BazType { (enumConstant o BAZ) })
<EOF>)
When I change the first enum in the sample to something other, let's say 'enum' to 'enumi', almost the whole tree is messed up. The parser recognizes only the namespace the rest seems to be an IDENTIFIER.
(modelUnit
(namespaceDeclaration namespace org . basic . sample)
enumi FooType { o FOO }
enum BarType { o BAR }
enum BazType { o BAZ })
However when I do the same with the second enum, the somehow only that invalid enum is not recognized and the rest is fine.
(modelUnit
(namespaceDeclaration namespace org . basic . sample)
(enumDeclaration enum FooType { (enumConstant o FOO) })
enumi BarType { o BAR }
(enumDeclaration enum BazType { (enumConstant o BAZ) }) <EOF>)
What can I do that also the first erroneous input is skipped and the rest is recognized? I tried with new line tokens, but that causes problems when I want to introduce a new declaration after the namespace.

Answer 1

This is a limitation of the prediction engine, from what I know. I also have seen that in cases like this MySQL query:
select * from sakila.actor where
which marks the select keyword as errorneous instead of the missing where expression. What happens here is that the ALL(*) prediction looks too far down the rule chain. If there's an error it doesn't allow to parse the correct input up to that error, but sometimes fails the entire input. I have not found a good solution for this problem. It all seems to depend on the grammar structure.