[PATCH] Step 1: Simple Generic lambda (no captures or nested lambdas)

[Richard Smith]

On Tue, Jun 18, 2013 at 2:27 PM, Faisal Vali <faisalv at gmail.com> wrote:
> hi Richard, in regards to:
>
>>>>>>    - also added ser/deser support for PendingLocalImplicitInstantiations
>>>>>>      (else the uninstantiated generic lambdas create inconsistencies with
>>>>>>       pch)
>>>>>
>>>>> This implies there is still a bug somewhere. Pending local
>>>>> instantiations must be instantiated in some local context; if any are
>>>>> left when we get to the end of a PCH, we've done something wrong. I
>>>>> think you just need to swap the instantiations back earlier
>>>>> (immediately after the call to PerformPendingInstantiations).
>>>>
>
> Currently in clang, the following code leaves an instantiation
> in the PendingLocalInstantiation queue, which gets instantiated
> at the endof the translation unit (if not in a pch context).
>
> int foo(double y) {
>   struct Lambda {
>     template<class T> T operator()(T t) const { return t; };
>   } lambda;
>   return lambda(y);
> }
>
> In a pch context, this does not get instantiated at the end of the
> translation unit
> (see ActOnEndOfTU) - regardless of where i swap the pending instantiations.
>
> If you're saying that this is a bug, then I wonder if ActOnFinishFunctionBody
> should call PerformPendingInstantiations(/*LocalOnly*/true) to ensure that
> all local instantiations should be instantiated while that function's context
> is still on the stack?

We shouldn't be pushing a local instantiation for the call to the
templated operator() above. (We should only ever push a local
instantiation if we're already instantiating something; otherwise
there is no local instantiation context to preserve and we can just
push a normal pending instantiation.) It should be straightforward to
teach MarkFunctionReferenced this rule.

> If that is the case, do i need to maintain a
> stack of local pending
> instantiations from which i swap in and out of, so that deeply nested member
> functions only instantiate those instantiations that they added to the
> pending list?

The swap in/out mechanism already implicitly creates a stack of
pending instantiations.