[PATCH] D25624: Added 'inline' attribute to basic_string's destructor

Mehdi AMINI via cfe-commits cfe-commits at lists.llvm.org
Fri Oct 28 18:19:36 PDT 2016


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





More information about the cfe-commits mailing list