mehdi_amini added a comment. Trying to figure out: it seems you are trying to address what I reported here: https://llvm.org/bugs/show_bug.cgi?id=26498 ; right?
> Except for inline functions, declarations with types deduced > from their initializer or return value (7.1.6.4), const > variables of literal types, variables of reference types, > and class template specializations, explicit instantiation > declarations have the effect of suppressing the implicit > instantiation of the entity to which they refer. [ Note: > The intent is that an inline function that is the subject > of an explicit instantiation declaration will still be > implicitly instantiated when odr-used (3.2) so that the > body can be considered for inlining, but that no > out-of-line copy of the inline function would be generated > in the translation unit. — end note ] So the `_LIBCPP_EXTERN_TEMPLATE(class _LIBCPP_TYPE_VIS basic_string<char>)` block the instantiation of any non-inline template function. The effect of the "inline" keyword is actually allowing clang to actually instantiate and IRGen the function, so that it is available for inlining. This seems like a generally good problem to solve for every such function and not only the destructor (I mentioned __init() as well in PR26498). (The commit message is confusing, it mentions "Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string()", please add the quote of the standard and mention that it enables instantiation) https://reviews.llvm.org/D25624 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
