[PATCH] D36357: Added a better diagnostic when using the delete operator with lambdas

[Nicolas Lesser via Phabricator via cfe-commits]

Rakete1111 marked 2 inline comments as done.
Rakete1111 added a comment.

In D36357#1501961 <https://reviews.llvm.org/D36357#1501961>, @rsmith wrote:

> In D36357#1500949 <https://reviews.llvm.org/D36357#1500949>, @Rakete1111 wrote:
>
> > How should I do this? Do I just skip to the next `}`, or also take into account  any additional scopes? Also does this mean that I skip and then revert, because that seems pretty expensive?
>
>
> It would be a little expensive, yes, but we'd only be doing it on codepaths where we're producing an error -- for an ill-formed program, it's OK to take more time in order to produce a better diagnostic. Skipping to the next `}` won't work, because `SkipUntil` will skip over pairs of brace-balanced tokens (so you'll skip past the `}` you're looking for), but skipping until the next `{` and then skipping to the `}` after it should work.


Hmm wouldn't this interact badly with `{}` in initializers?

  []<int = {0}> {};
  [](int = {0}) = {};





================
Comment at: clang/lib/Parse/ParseExprCXX.cpp:2996
+           GetLookAheadToken(4).is(tok::identifier))))) {
+      SourceLocation RightBracketLock = NextToken().getLocation();
+      // Warn if the non-capturing lambda isn't surrounded by parenthesis
----------------
rsmith wrote:
> rsmith wrote:
> > `RightBracketLock` -> `RSquareLoc`
> > 
> > (Our convention is to use `Loc` for "location" and to avoid the word "bracket" because it means different things in different English dialects -- usually `[]` in US English and usually `()` in UK English.)
> `Lock` -> `Loc`. There's no `k` in "location" =)
No idea how that k managed to sneak in :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D36357/new/

https://reviews.llvm.org/D36357