[PATCH] D51789: [clang] Add the exclude_from_explicit_instantiation attribute

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D51789#1238410, @ldionne wrote:

> In https://reviews.llvm.org/D51789#1238396, @rjmccall wrote:
>
> > That may work for libc++'s purposes, but it's clearly inappropriate as a compiler rule.  There are good reasons why something with hidden visibility would need to be explicitly instantiated.
>
>
> I take your word for it, but I can't think of any example. For my education, do you have a specific example in mind?


I mean, most code doesn't use explicit instantiations to begin with, but — the general idea would be someone using an explicit instantiation, either for compile-time or seperate-compilation reasons, for some type that's entirely private to their library.

Here's an example of it from Swift that happened to be easy to find:

  https://github.com/apple/swift/blob/master/lib/SILOptimizer/ARC/RCStateTransitionVisitors.h

The entire template being instantiated there is private to the SILOptimizer library.  Swift doesn't use explicit visibility attributes much, preferring to globally assume `-fvisibility=hidden`, but if we used them, there would definitely be an attribute on that template.

>> For many programmers, hidden visibility means "this is private to my library", not "this is actually public to my library, but I'm walking an ABI tightrope".
> 
> In libc++'s case, the functions we will annotate with `exclude_from_explicit_instantiation` are private to libc++ too (in the sense that we don't want them part of the ABI and they are not exported from the dylib). Those functions were previously marked with `__always_inline__` to make sure they were not part of the ABI.

Yeah, I understand the use case.  That's what I was calling an ABI tightrope.  The functions you're annotating are still part of libc++'s *logical* interface, they're just not exported by the dylib.

> Note that I'm quite happy with `exclude_from_explicit_instantiation` as it solves libc++'s problem -- I'm trying to see whether another solution would serve people better while still solving libc++'s problem. (Appart from explicitly exporting functions, typeinfos and vtables like we've talked about on cfe-dev, which is a superior solution to everything else but is left as a future improvement for the time being).

Understood.

John.


Repository:
  rC Clang

https://reviews.llvm.org/D51789