Thanks for passing on the wiki link. It's definitely smarter than the crude approach I took, which requires additional tree assembly as well as error recovery adjustment to eat up unexpected tokens.
J On 10/4/2010 4:26 PM, Edson Tirelli wrote: > Thanks for the suggestion. I just found this: > > http://www.antlr.org/wiki/display/ANTLR3/Custom+Syntax+Error+Recovery > > I am trying to check if it works for my case. Otherwise I will try > your approach. > > Edson > > 2010/10/4 Junkman <[email protected]>: >> Greetings, >> >> I ran into the same issue, and you probably noticed that, when the >> lookahead doesn't match a statement, it breaks out of * loop and tries >> to match EOF. >> >> I resorted to calling statement() in a loop to force continuation of >> parsing regardless of error, instead of calling compilationUnit(). >> Seems to work well enough. >> >> It would be good to know if there is a better to handle this, though. >> >> Best, >> >> J >> >> >> On 10/4/2010 3:27 PM, Edson Tirelli wrote: >>> Hi all, >>> >>> Look at this simple grammar: >>> >>> grammar testGrammar; >>> options { >>> output=AST; >>> } >>> >>> compilationUnit >>> : statement* EOF >>> ; >>> >>> statement >>> : A^ >>> | B^ C >>> ; >>> >>> A : 'a'; >>> >>> B : 'b'; >>> >>> C : 'c'; >>> >>> WS : ( ' ' >>> | '\t' >>> | '\r' >>> | '\n' >>> ) {$channel=HIDDEN;} >>> ; >>> >>> >>> Using the above grammar, it will successfully parse an input like: >>> >>> a b c a >>> >>> Now, if the input is: >>> >>> a c a >>> >>> The generated parser will parse "a", and will fail at "c", as it >>> is not a valid statement. Reading the error recovery chapter on the >>> ANTLR book, I would imagine ANTLR would delete/skip the "c" token and >>> try to recover, successfully parsing the second "a", as that is a >>> valid statement again. But it is not working like this. It is aborting >>> the parsing with an error at "c". >>> >>> Question: how do I force it to recover from the error and continue >>> parsing? >>> >>> The actual scenario is that the parser I am working on is used by >>> an IDE environment (eclipse), so we need it to continue parsing and >>> presenting the users with all the errors found in the file, not just >>> the first one. The error recovery seems to work on some rules, but not >>> on the top rule (compilationUnit). >>> >>> Thanks, >>> Edson >>> >> >> > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en.
