[cxx-abi-dev] Mangling C++0x Lambdas

[Doug Gregor]

On Mon, Dec 15, 2008 at 12:02 PM, Lawrence Crowl <crowl at google.com> wrote:
> On 12/15/08, Doug Gregor <doug.gregor at gmail.com> wrote:
>> On Mon, Dec 15, 2008 at 7:50 AM, David Vandevoorde <daveed at edg.com> wrote:
>> > Has anyone on this list already implemented C++0x lambdas and chosen a
>> > mangling scheme for them?
>>
>> The prototype GCC implementation had a mangling scheme, but it won't
>> work in the general case.
>
> Why?

The scheme it used was to mangle the lambda name as "__lambda_#",
where # is just a counter of the number of lambdas seen in the
translation unit. This will cause problems if, for example, the
following inline function "foo" occurs in several translation units
(with varying numbers of lambdas before it):

  template<typename T> void bar(T);

  void foo() { bar([](int x) -> int { return x; }); } // the type of
this lambda must always be the same

We need something that encodes the context of the lambda (function
"::foo" with no parameters) followed by, perhaps, a numbering scheme
within that context. The context encoding needs to account for (at
least) inline functions, classes, and namespaces.

>> > (We think a mangling convention is needed because they can appear in
>> > inline function bodies or determine template argument types.)
>>
>> Agreed. They can also appear in the initialization of variables at
>> namespace scope, e.g.,
>>
>>   struct X {
>>     template<typename T> X(T);
>>   };
>>   X x = [](int x) -> int { return x; }
>
> The semantics here might vary because of the empty capture list.
>
> Let's assume for the moment that we have an "interesting" capture
> list, which implies a full-scale constructed type.  Does the mangling
> of this type need to be part of the ABI?

Yes.

> Why isn't a per-compiler
> scheme sufficient?

Because we're going to be instantiating templates based on this type,
and everyone needs to instantiate the same templates.

I don't think that the formulation of the capture list will have
anything to do with the mangling of the lambda's type name. If the
capture list only has & captures, the resulting type will derive from
std::reference_closure (and may have different members, depending on
how we choose to layout the lambda class), but that doesn't change the
name of the type itself.

  - Doug