[cfe-commits] [Review] First step towards PR13231 - vftable generation with -cxx-abi microsoft

[Timur Iskhodzhanov]

On Tue, Dec 4, 2012 at 8:09 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote:
>>> d) The complete/deleting dtor logic will change when we support MSVC
>>> dtor types, but not now
>>>    [shouldn't matter now that we still don't support virtual inheritance]
>>
>> You're thinking about complete vs. base destructors.  Complete vs. deleting
>> destructors isn't about virtual inheritance;  it's about whether the destructor
>> calls operator delete.
> Yeah, now I see it... [see below]
>
>> (This is important because the 'delete' operator uses
>> the operator delete from the most-derived class.)
>>
>> How does MSVC handle the difference between
>>   foo->~Foo(); // virtually dispatched but doesn't call operator delete
>> and
>>   delete foo; // virtually dispatched and calls operator delete
>> ?
> Clang with my patch behaves badly on such code.
> It seems to work fine at least on simple code where you don't use
> virtual destructors.
>
> Actually, the whole idea of base vs complete dtors doesn't apply to
> -cxx-abi microsoft.
> Anyways, had plans to work on ctor and dtor compatibility as a
> separate patch - is that OK?
> I've put a couple of more FIXME into the code for that. (in
> ::AddMethod and ::ComputeMethodVTableIndices).

Attached is the patch which is similar to bug_13231_2 but puts the
complete dtor rather than deleting.
Both are basically broken anyways but at least you can choose what you
think fits better :)
Investigating compatible dtor behavior is definitely on my TODO-soon
list now [as a separate change if this works]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_13231_3.patch
Type: application/octet-stream
Size: 11450 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121205/ea53cf00/attachment.obj>