[cdt-patch] 1.0.1 Parser "Big Hammer" Fix

[Chris Songer <songer@xxxxxxxxxxxxx>]

Hi!

The 1.0.1 parser has lots of constructs that look like this:

catch( ParseException ) { synchronize( MY_FAVORITE_TOKEN ); }

The intent appears to be that if the parser cannot correctly parse a given 
construct, it can at least try to get to the end of that construct so that 
it can gracefully recover. It seems simple, but it's not because it gets it 
wrong sometimes. Doing this recovery requires correctly repositioning the 
current token so that the parser can move forward and sometimes the parser 
doesn't do this right and just keeps erroring on the same token again and 
again.

If it were clear that the catch( ParseException ) { synchronize } always 
caused lockups, we could just remove them all. I ran a few tests, turns out 
that once in a while catch/synchronize makes the parser work right. Welcome 
to hell, here's your accordion.

So, please find a patch attached that fixes all of this class of lockup 
while leaving the recovery potential in place. Basically, I added a new 
RuntimeException called ParserFatalException. 
CPPParser::generateParseException throws ParserFatalException when called 
twice in a row with the same token position. It's kind of a big hammer to 
use, but it works and I didn't have to type throw 
NewFatalNonRuntimeException in the 1000 machine generated functions in 
CPPParser.java. The 1.0.1 parser is not long for this world anyway.

Thanks!
-Chris

Attachment: diffs
Description: Binary data