<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 3, 2017, at 2:35 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I think this instance is just a bug.<div class=""><br class=""></div><div class="">As it was explained to me, libc++ attempts to make it possible to statically link together two libraries that use different versions of libc++ headers. These two libraries may reference inline template functions from libc++ with different definitions, but as long as all of the out-of-line symbols remain the same and implement the same functionality and use the same struct layouts, things are supposed to "work".</div><div class=""><br class=""></div><div class="">With that in mind, any inline function in libc++ that isn't always_inline or internal_linkage is probably a bug.</div></div></div></blockquote><div><br class=""></div><div>We should be able to have “ABI stable” function as well right? </div><div><br class=""></div><div>The way I see it (with some help from Duncan) right now is that we have 5 conceptual categories for symbols. So instead of having macros like “INLINE_VISIBILITY” etc. I rather have macros that represent more accurately the category a function belongs to:</div><div><br class=""></div><div>1) Symbols present and exported in the dylib, these are ABI stable. Should be marked with _LIBCPP_DLL_VIS right now.</div><div>2) Symbols that are public APIs (not starting with __), and ABI stable. These don’t have to be hidden or always_inline. I’d add a macro that would reflect this, like _LIBCPP_PUBLIC_ABISTABLE</div><div>3) Symbols that are public APIs, and not ABI stable (do these exist?). These may need to stay hidden and always_inline, or possible made internal instead? The annotation could be _LIBCPP_PUBLIC_UNSTABLE</div><div>4) Symbols that are private APIs, but ABI stable (likely rare?). We could mark them _LIBCPP_PRIVATE_ABISTABLE</div><div>5) Symbols that are private APIs, and not ABI stable. Currently always_inline/hidden, but we’d like to change these to “internal_linkage”. We could mark them _LIBCPP_PRIVATE_UNSTABLE</div><div><br class=""></div><div>This way we can expect *every* function to be decorated, and it should be fairly easy to spot a missing annotation.</div><div><br class=""></div><div>And that’s just for the symbols, there is also the consideration about the type infos, vtables, etc. that I’m not totally sure about.</div><div><br class=""></div><div>— </div><div>Mehdi</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Mar 31, 2017 at 10:46 PM, Mehdi Amini via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
I’m wondering about libc++ visibility for the internals of the library. For example why do we define:<br class="">
<br class="">
_LIBCPP_INLINE_VISIBILITY<br class="">
void __construct_at_end(size_type __n, const_reference __x);<br class="">
<br class="">
with inline/hidden visibility, but not this one:<br class="">
<br class="">
template <class _ForwardIterator><br class="">
typename enable_if <__is_forward_iterator<_<wbr class="">ForwardIterator>::value, void>::type<br class="">
__construct_at_end(_<wbr class="">ForwardIterator __first, _ForwardIterator __last, size_type __n);<br class="">
<br class="">
<br class="">
Thanks,<br class="">
<br class="">
—<br class="">
Mehdi<br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/cfe-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>