[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-patch] 1.0.1 Parser "Big Hammer" Fix
|
>
> --=====================_277667000==_
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
>
> 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.
>
Patch applied in the 1_0_1 branch.
Thanks.
