<div dir="ltr">I like the idea of `_LIBCPP_HIDE_FROM_ABI`, and I think the first step you proposed sounds reasonable.<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 9, 2018 at 10:33 AM, Louis Dionne via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Everything that is ABI stable is marked with a visibility macro like today (no change here).<br>
2. Everything that is marked with `_LIBCPP_INLINE_VISIBILITY` today is marked with a new `_LIBCPP_HIDE_FROM_ABI` macro instead. This macro can be defined to `__attribute__((__visibility__<wbr>("hidden")))` or to `__attribute__((__visibility__<wbr>("hidden"),internal_linkage))` depending on whether we want to support only use case (1), or both use cases (1) and (2), respectively.</blockquote><div><br></div><div>By ABI stable do you mean exported from the libc++ dylib, or all non-reserved names provided by the library? (2) suggests the former, since entities like std::sort are marked with _LIBCPP_INLINE_VISIBILITY.</div><div>Any entity which a user can reasonably expect to externally instantiate cannot be part of the "hidden ABI", since marking it with internal linkage will cause linkage failures.</div><div><br></div><div>I think we'll be limited to applying `_LIBCPP_HIDE_FROM_ABI` to names which are (A) reserved and (B) cannot be externally instantiated as a member of a class.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This would look something like:<br>
<br>
    #ifdef _LIBCPP_NO_INTERNAL_LINKAGE_<wbr>FOR_ABI_UNSTABLE_SYMBOLS<br>
    #   define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr>"hidden")))<br>
    #else<br>
    #   define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr>"hidden"),internal_linkage))<br>
    #endif<br>
<br>
In the future, we can decide which default behavior we want, but for now, I suggest we stick to what we have right now, which is support for both (1) and (2). It would be fine to change this in the future if we make that decision.<br>
<br></blockquote><div><br></div><div>When we don't have internal linkage, I suspect we'll want to keep `__always_inline__` as to prevent static libraries from providing each other with incompatible function definitions (I think this could occur?).</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div><br></div></div>