ldionne added a comment. 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? > 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. 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). 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
