takuto.ikuta added inline comments.
================ Comment at: clang/lib/Sema/SemaDecl.cpp:11976 + + while (FD && !getDLLAttr(FD) && + !FD->hasAttr<DLLExportStaticLocalAttr>() && ---------------- 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? ================ Comment at: clang/lib/Sema/SemaDecl.cpp:11995 + + // Function having static local variables should be exported. + auto *ExportAttr = cast<InheritableAttr>(NewAttr->clone(getASTContext())); ---------------- hans wrote: > takuto.ikuta wrote: > > hans wrote: > > > Isn't it enough that the static local is exported, does the function > > > itself need to be exported too? > > Adding dllexport only to variable does not export variable when the > > function is not used. > > But dllimport is not necessary for function, removed. > Hmm, I wonder if we could fix that instead? That is, export the variable in > that case even if the function is not used? I see. I'll investigate which code path emits static variables ================ Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5719 + TSK != TSK_ExplicitInstantiationDeclaration && + TSK != TSK_ExplicitInstantiationDefinition) { + if (ClassExported) { ---------------- 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. https://reviews.llvm.org/D51340 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits