[cxx-abi-dev] Lambda conversion

[Gabriel Dos Reis]

On Mon, Mar 22, 2010 at 3:57 PM, Jason Merrill <jason at redhat.com> wrote:
> On 03/09/2010 12:36 PM, Gabriel Dos Reis wrote:
>>
>> On Tue, Mar 9, 2010 at 7:07 AM, Jason Merrill<jason at redhat.com>  wrote:
>
>>> Implementation seems pretty straightforward: the conversion returns the
>>> address of a static member function (call it __fn), and either the op()
>>> calls __fn or __fn calls op() with a null object argument.
>>>
>>> Anyone object to "__fn" as the name of the static member function?
>>
>> I would probably suggest making the string 1 longer: "__fun".
>
> I'm currently using _FUN to avoid a potential name clash with data members
> (which I rename by adding __ at the beginning so that the debugger can show
> something useful).

that sounds good to me.

>
>>> Any preference as to which way the call goes?  I suppose we need to take
>>> the
>>> address of __fn in either case, which would argue for making op() the
>>> wrapper.  OTOH, it might be a bit easier to implement leaving op() alone
>>> and
>>> adding a function that calls it later.
>>
>> Is there any middle-end issue with a 'null object argument'?
>> (the middle-end seems to be getting clever every day.)
>
> I can't imagine why; the op() doesn't touch *this.

I was thinking of optimizers/transformations that would (that would one way
or the other) take advantage of the fact 'this' is never null.  But
you are correct
that the ABI could just mandate that does not matter.

>
> It occurred to me while implementing this that the obvious thunk-like
> implementation breaks down for variadic op() just like it does for covariant
> thunks.  I think I'd rather have that be a problem for the conversion rather
> than for direct calls to op().
>
> Next issue: should _FUN share a comdat group with op() to allow it to be an
> alternate entry point?  I suppose so.

I agree.

-- Gaby