Re: [C++ PATCH] pr 67273 & 79253 lambdas, warnings & ICEs

[Jason Merrill <jason at redhat dot com>]

On Tue, Jan 31, 2017 at 8:31 AM, Nathan Sidwell <nathan@acm.org> wrote:
> On 01/30/2017 03:48 PM, Jason Merrill wrote:
>> Why can't it figure that out for itself?  We should be able to tell
>> whether its containing function is currently open.
>
> It doesn't have sufficient information (but that may not matter, see below).
>
> template <class T> void Foo (T lam)
> {
>   lam (1u); // #1
> }
>
> template <class T>
> void f(T x)
> {
>   auto lam = [](auto x) { return  (x); };
>
>   lam (1); // #2
>   Foo (lam);
> }
>
> void Bar ()
> {
>   f<int>(1);
> }
>
> at #1 and #2 we end up via maybe_instantiate in instantiate_decl (to
> determine the return type when building the CALL_EXPR).  At #1
> current_function_decl is the template Foo, which is not the context of the
> closure type.
>
> At #2 we go via the same path, but current_function_decl is 'f', which is
> the context of the closure type.
>
> It seems wrong to me to push to top in one of those cases but not in the
> other.  Again, absent of generic lambdas, we'd always push to top in these
> circumstances.

Agreed.  As I was suggesting in response to one of Adam's patches, I
think we need to defer creating the closure until f is instantiated;
at that point we can resolve all names from f and so we should be able
to always push to top when instantiating the lambda.

> That said, using the predicate:
>    current_function_decl
>     == DECL_CONTEXT (TYPE_NAME (CP_DECL_CONTEXT (d)))
> to determine whether a lambda instantiate should push to top or not doesn't
> cause any test failures. (and does resolve the shadowing bug).

Perhaps

if (!fn_context || fn_context != current_function_decl)

?

Jason