dblaikie added a comment. In https://reviews.llvm.org/D48426#1139823, @rnk wrote:
> `LangOpts.ModulesCodegen` is very related in spirit to this, but I think we > need a distinct option because that was designed to handle all inline > functions (too much), not just dllexport inline functions. + @dblaikie Does it have to be only the dllexported inline functions - or could this be used to home all inline functions? (I guess not - presumably it's not acceptable for the compiler to implicitly promote something to dllexport (& if it doesn't do that promotion, then the function wouldn't be visible from the use)) Is it valid to provide a definition for optimization purposes (LLVM's available_externally linkage) for these inline functions? Or is it required that, after a change to the header (modifying the implementation of one of these dllexported inline functions), the DLL they're exported could be rebuilt without rebuilding the clients & the change in behavior would be correctly applied? ================ Comment at: test/CodeGen/pch-dllexport.cpp:22 +// PCH: define weak_odr dso_local dllexport x86_thiscallcc void @"?bar@S@@QAEXXZ" +// PCHWITHOBJ-NOT: define weak_odr dso_local dllexport x86_thiscallcc void @"?bar@S@@QAEXXZ" +}; ---------------- This is a pretty specific "NOT" - maybe: define {{.*}}@"?bar@... would be better to ensure no definition is provided? (similarly above) Also, should this file have some non-exported inline functions to check those do the right thing? https://reviews.llvm.org/D48426 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits