[cfe-dev] [libc++] A proposal for getting rid of __always_inline__ in _LIBCPP_INLINE_VISIBILITY

[Eric Fiselier via cfe-dev]

I like the idea of `_LIBCPP_HIDE_FROM_ABI`, and I think the first step you
proposed sounds reasonable.

On Mon, Jul 9, 2018 at 10:33 AM, Louis Dionne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 1. Everything that is ABI stable is marked with a visibility macro like
> today (no change here).
> 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__("hidden")))` or to
> `__attribute__((__visibility__("hidden"),internal_linkage))` depending on
> whether we want to support only use case (1), or both use cases (1) and
> (2), respectively.


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.
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.

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.



> This would look something like:
>
>     #ifdef _LIBCPP_NO_INTERNAL_LINKAGE_FOR_ABI_UNSTABLE_SYMBOLS
>     #   define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(
> "hidden")))
>     #else
>     #   define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(
> "hidden"),internal_linkage))
>     #endif
>
> 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.
>
>
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?).

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180710/5660b5ab/attachment.html>