<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 10, 2015 at 5:43 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Mon, Aug 10, 2015 at 5:00 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: rnk<br>
Date: Mon Aug 10 14:39:01 2015<br>
New Revision: 244488<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=244488&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=244488&view=rev</a><br>
Log:<br>
[dllimport] A non-imported class with an imported key can't have a key<br>
<br>
Summary:<br>
The vtable takes its DLL storage class from the class, not the key<br>
function. When they disagree, the vtable won't be exported by the DLL<br>
that defines the key function. The easiest way to ensure that importers<br>
of the class emit their own vtable is to say that the class has no key<br>
function.<br>
<br>
Reviewers: hans, majnemer<br>
<br>
Subscribers: cfe-commits<br>
<br>
Differential Revision: <a href="http://reviews.llvm.org/D11913" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11913</a><br>
<br>
Modified:<br>
cfe/trunk/lib/AST/RecordLayoutBuilder.cpp<br>
cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp<br>
<br>
Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff</a><br>
==============================================================================<br>
--- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)<br>
+++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015<br>
@@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu<br>
continue;<br>
}<br>
<br>
+ // If the key function is dllimport but the class isn't, then the class has<br>
+ // no key function. The DLL that exports the key function won't export the<br>
+ // vtable in this case.<br>
+ if (MD->hasAttr<DLLImportAttr>() && !RD->hasAttr<DLLImportAttr>())<br>
+ return nullptr;<br></blockquote><div><br></div></div></div><div>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?)</div></div></div></div></blockquote><div><br></div></div></div><div>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.</div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">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.</div></div>