cor3ntin added inline comments.
================
Comment at: clang/lib/Parse/ParseExprCXX.cpp:700
+
+ if (Tok.is(tok::identifier) && NextToken().is(tok::r_paren)) {
+ SourceLocation TemplateKWLoc;
----------------
aaron.ballman wrote:
> cor3ntin wrote:
> > aaron.ballman wrote:
> > > This feels surprisingly restrictive to me, but it's sufficient for
> > > getting libstdc++ working again.
> > I've can't think of another kind of unqualified-id that could refer to a
> > capturable entity here.
> > Do you know what would be missing?
> > Also, without being very restrictive, I'm not sure how this is implementable
> What I find restrictive is that it requires an unqualified-id *only* to kick
> in as being maybe mutable agnostic. e.g., `decltype(id)` and `decltype(+id)`
> (where the unary + may be an overloaded operator that depends on the
> mutability of the `this` object).
>
> (I'm not seeing the principle that guides this restriction proposed in the
> core issue yet, but those can be hashed out later.)
I do not think there is a general answer to "given these captures and this
arbitrarily complex expression", would the mutability of the lambda affect the
declaration of the parameters.
In this case we know it doesn't and that happen to fix existing code, which
make the solution tractable.
If core was keen to add any more complexity here, I think they should consider
mandating a look-ahead of the `mutable` keyword even if that sounds rather
complex. I don't think it will come to that, the proposed resolution will be
good enough to reduce the blast radius of the paper, and I don't see a strong
motivation to add even more complexity here.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D123909/new/
https://reviews.llvm.org/D123909
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
