On Tue, Jan 31, 2017 at 8:31 AM, Nathan Sidwell <nat...@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
