r244488 - [dllimport] A non-imported class with an imported key can't have a key

[Reid Kleckner via cfe-commits]

On Mon, Aug 10, 2015 at 6:40 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Mon, Aug 10, 2015 at 5:43 PM, Reid Kleckner <rnk at google.com> wrote:
>
>> On Mon, Aug 10, 2015 at 5:00 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>>> On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits <
>>> cfe-commits at lists.llvm.org> wrote:
>>>>
>>>> +    // If the key function is dllimport but the class isn't, then the
>>>> class has
>>>> +    // no key function. The DLL that exports the key function won't
>>>> export the
>>>> +    // vtable in this case.
>>>> +    if (MD->hasAttr<DLLImportAttr>() && !RD->hasAttr<DLLImportAttr>())
>>>> +      return nullptr;
>>>>
>>>
>>> Does the same apply if the key function is DLLExport and the class is
>>> not? (Presumably this would just lead us to export a vtable that we don't
>>> need to, which is presumably harmless?)
>>>
>>
>> No, there's no issue with dllexport. If the key function is dllexport,
>> then it must be part of the same DLL as the current TU, and we can rely on
>> it to provide (potentially non-exported) vtable and RTTI symbols.
>>
>
> Even if a different compiler is used to compile the other TUs in this DLL?
> It seems to me that if the rule really is "the vtable takes its DLL storage
> class from the class, not the key function", then the TU with the key
> function need not actually provide a vtable symbol if the class is not
> dllexport but the key function is.
>

GCC (and presumably other Itanium compilers that support dllexport) still
emit the vtable with the key function when the key is exported. It's just
not necessarily exported. All the TUs that are statically linked into the
DLL containing an exported key function can rely on the vtable to be there,
so I don't see any reason to add logic around dllexport here. Make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150811/edae6066/attachment.html>