[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

[Faisal Vali via Phabricator via cfe-commits]

faisalv added a comment.

In https://reviews.llvm.org/D28510#653794, @rsmith wrote:

> I don't think it's possible to check this in the way you're doing so here. In general, there's no way to know whether a constant expression will be part of a `typedef` declaration or function declaration until you've finished parsing it (when you're parsing the decl-specifiers in a declaration you don't know whether you're declaring a function or a variable, and the `typedef` keyword might appear later).


I see.  The issue is that the current approach would forbid valid variable declarations such as:

void (*f)(int [([]{return 5;}())]) = 0;

... where lambdas can appear within the array declarators (I believe that's the only syntactic neighborhood that can cause this problem, right?).

> So I think you need a different approach here. How about tracking the set of contained lambdas on the `Declarator` and `DeclSpec` objects, and diagnose from `ActOnFunctionDeclarator` / `ActOnTypedefDeclarator` if the current expression evaluation context contains any lambdas? (Maybe when entering an expression evaluation context, pass an optional `SmallVectorImpl<Expr*>*` to `Sema` to collect the lambdas contained within the expression.)

Yes - I can see something along these lines working well...

> There are some particularly "fun" cases to watch out for here:
> 
>   decltype([]{})
>     a, // ok
>     f(); // ill-formed
> 
> 
> ... that require us to track the lambdas in the `DeclSpec` separately from the lambdas in the `Declarator`.

Well lambda's can't appear in unevaluated operands yet, so your example would be ill-formed?  If so, we don't have to worry about them showing up in decl-specifiers?
The only Declarator where they could be well formed is within an array declarator of a variable or a parameter of a function pointer variable (but no where else, i.e typedefs and function declarations), right?

Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D28510