[cfe-commits] [PATCH] Parsing C++0x lambda expressions

[John Freeman]

This is an updated patch addressing comments.

Doug pointed out a nasty case where a lambda introducer cannot be 
disambiguated with fixed lookahead from a message expression where the 
receiver is a comma expression. In fact, if it is a lambda introducer, 
then it cannot be disambiguated until its end because every capture form 
(identifier, &identifier, 'this') is a valid expression.

ParseCXX0XLambdaIntroducer returns a DiagnosticID if it hits something 
unexpected. For tentative parsing, we can ignore the diagnostic and 
revert. This is encapsulated in TryParseCXX0XLambdaIntroducer. For 
normal parsing, we can issue the diagnostic and continue.

ParseCXX0XLambdaExpressionAfterIntroducer handles the rest of the 
expression.

The calls to these functions are wrapped in two entry functions:
- ParseCXX0XLambdaExpression, for normal parsing where we know we are 
looking at a lambda expression, and
- TryParseCXX0XLambdaExpression, that first uses lookahead and possibly 
tentative parsing (it calls the other entry function when lookahead is 
enough)

TryParseCXX0XLambdaExpression returns an ExprResult in one of three states:
- invalid, to indicate that we are not looking at a lambda expression 
(and that we should try parsing a message expression)
- valid but unusable, when we parsed a lambda expression with 
unrecoverable errors (like incomplete support)
- valid and usable, when we successfully parsed a lambda expression 
(possibly with recoverable errors)

I fear it could be considered overkill for what may be a rare or even 
non-existent case in real code. Let me know.

Feedback is appreciated!

Thank you,
John
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lambda-parse.patch
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110713/47ea4ece/attachment.ksh>