Rakete1111 added inline comments.
================
Comment at: lib/Parse/ParseExprCXX.cpp:2906-2912
+ // Basic lookahead to check if we have a lambda expression. If we
+ // encounter two braces with a semicolon, we can be pretty sure
+ // that this is a lambda, not say a compound literal.
+ if (!SkipUntil(tok::l_brace, SkipUntilFlags::StopAtSemi) ||
+ (NextToken().isNot(tok::r_brace) && !SkipUntil(tok::semi)) ||
+ !SkipUntil(tok::r_brace, SkipUntilFlags::StopAtSemi)) {
+ TPA.Revert();
----------------
rsmith wrote:
> This seems error-prone. Given:
>
> ```
> for (item *p = first, *oldp = p; p; p = p->next, delete [] oldp, oldp = p) {
> /*...*/;
> }
> ```
>
> ... we'll decide the //delete-expression// is followed by a lambda. Likewise
> for cases like:
>
> ```
> delete [] f->getPtr([] {
> return blah;
> });
> ```
>
> Our goal here should be a fast heuristic (don't use lookahead except when
> you're already confident you have a lambda) and zero false positives. How
> about these heuristics instead:
>
> Assume that the `delete []` is actually `delete` followed by a lambda if
> either:
>
> * The next token is `{` or `<`, or
> * The next token is `(` and either
> * the following token is `)` or
> * the following tokens are a type specifier followed by an identifier
>
> This should have no false positives, and only has false negatives if a lambda
> has an unnamed parameter or a parameter with a non-trivial parameter type.
> (For the last condition, we could try to tentatively parse an entire
> parameter and see if it has a name, which would handle all cases except an
> expression/declaration ambiguity in the parameter declaration, but that seems
> like overkill to me. This is already performing more lookahead than I'd like,
> but `delete []` expressions are rare enough that using two lookahead tokens
> for an improved error message seems OK.)
Ah, I see. I had no idea that lookaheads were that expensive. Thanks for
finding a better algorithm than me :)
https://reviews.llvm.org/D36357
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
