[PATCH] D51340: Add /Zc:DllexportInlines option to clang-cl

Hans Wennborg via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 11 08:26:56 PDT 2018


hans added inline comments.


================
Comment at: clang/lib/Sema/SemaDecl.cpp:11976
+
+    while (FD && !getDLLAttr(FD) &&
+           !FD->hasAttr<DLLExportStaticLocalAttr>() &&
----------------
takuto.ikuta wrote:
> hans wrote:
> > takuto.ikuta wrote:
> > > hans wrote:
> > > > Why does this need to be a loop? I don't think FunctionDecl's can be nested?
> > > This is for static local var in lambda function.
> > > static_x's ParentFunction does not become f().
> > > ```
> > > class __declspec(dllexport) C {
> > >   int f() {
> > >     return ([]() { static int static_x; return ++static_x; })();
> > >   }
> > > };
> > > ```
> > I don't think the lambda (or its static local) should be exported in this case.
> If we don't export static_x, dllimport library cannot find static_x when linking?
> 
> 
I believe even if C is marked dllimport, the lambda will not be dllimport. The inline definition will be used.


================
Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5719
+          TSK != TSK_ExplicitInstantiationDeclaration &&
+          TSK != TSK_ExplicitInstantiationDefinition) {
+        if (ClassExported) {
----------------
takuto.ikuta wrote:
> hans wrote:
> > I still don't understand why we need these checks for template instantiations. Why does it matter whether the functions get inlined or not?
> When function of dllimported class is not inlined, such funtion needs to be dllexported from implementation library.
> 
> c.h
> ```
> template<typename T>
> class EXPORT C {
>  public:
>   void f() {}
> };
> ```
> 
> cuser.cc
> ```
> #include "c.h"
> 
> void cuser() {
>   C<int> c;
>   c.f();  // This function may not be inlined when EXPORT is __declspec(dllimport), so link may fail.
> }
> ```
> 
> When cuser.cc and c.h are built to different library, cuser.cc needs to be able to see dllexported C::f() when C::f() is not inlined.
> This is my understanding.
Your example doesn't use explicit instantiation definition or declaration, so doesn't apply here I think.

As long as the dllexport and dllimport attributes matches it's fine. It doesn't matter whether the function gets inlined or not, the only thing that matters is that if it's marked dllimport on the "consumer side", it must be dllexport when building the dll.


https://reviews.llvm.org/D51340





More information about the cfe-commits mailing list