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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
