On Mar 19, 2013, at 4:22 PM, Douglas Gregor <[email protected]> wrote:
> > On Mar 19, 2013, at 2:58 PM, jahanian <[email protected]> wrote: > >> >> On Mar 19, 2013, at 2:29 PM, Jordan Rose <[email protected]> wrote: >> >>> >>> On Mar 19, 2013, at 14:21 , jahanian <[email protected]> wrote: >>> >>>> >>>> On Mar 19, 2013, at 1:42 PM, Jordan Rose <[email protected]> wrote: >>>> >>>>> >>>>> Would it make sense to not just continue but to pretend instead that the >>>>> '}' is there? I feel like that will give us better recovery. (You'd >>>>> eliminate those last two errors: "expected '}'" and "missing '@end'".) >>>> >>>> I think by 'pretending' you mean insert a '}' before @end and continue. I >>>> thought about this but I did not want to introduce the bookkeeping >>>> overhead for the correct case. Do you have a suggestion how to pretend >>>> without adding this overhead? >>> >>> Hm, I see what you mean—right now we unilaterally consume a closing brace >>> when we exit the loop. The easiest way to solve this is to extract the >>> parsing loop and the T.consumeClose() into a helper function, with an early >>> return for the @end case...but that's not exactly pretty. I guess I'll let >>> you make the call (or stand by the call you already made). >> >> Problem is not avoiding calling of T.consumeClose() in the incorrect case. >> Problem is that '@' and 'end" are two tokens and we have consumed >> '@' already (this will cause parse error later). I see two solutions: >> 1. When seeing '@', lookahead for 'end' and exit the loop while skipping >> T.consumeClose() . I think this is what you are suggesting. But it involves >> unnecessary overhead for the common case. >> 2. If it is possible, I can insert a '}' two tokens before current token >> and reset the lexer to the inserted '}' for the incorrect case, then >> problem is solved without introducing any undue overhead for >> the common case. > > > You don't need to insert the '}' token. If you've consumed the '@' and see > something that doesn't belong in a list of instance variables (e.g., > 'property', 'end'), break out of the loop without calling consumeClose() and > then PP.EnterToken() the '@' to recover. Yes, this API was what I was wishing for. It was more involved than I bargained for because I did not want to introduce any overhead in the loop for the common case. In r177549. -Thanks to both - Fariborz > > - Doug
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
