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 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:
>
>> Author: rnk
>> Date: Mon Aug 10 14:39:01 2015
>> New Revision: 244488
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev
>> Log:
>> [dllimport] A non-imported class with an imported key can't have a key
>>
>> Summary:
>> The vtable takes its DLL storage class from the class, not the key
>> function. When they disagree, the vtable won't be exported by the DLL
>> that defines the key function. The easiest way to ensure that importers
>> of the class emit their own vtable is to say that the class has no key
>> function.
>>
>> Reviewers: hans, majnemer
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: http://reviews.llvm.org/D11913
>>
>> Modified:
>>     cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>>     cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp
>>
>> Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff
>>
>> ==============================================================================
>> --- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
>> +++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015
>> @@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu
>>          continue;
>>      }
>>
>> +    // 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150810/a20d697a/attachment.html>