[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