<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jul 18, 2018, at 4:11 PM, Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 18, 2018, at 13:53, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" class=""><div class="">On Jul 18, 2018, at 5:40 AM, Eric Fiselier <<a href="mailto:eric@efcs.ca" class="">eric@efcs.ca</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">That's a very good point, somehow I hadn't thought of it before.</div><div class=""><br class=""></div><div class="">One problem is that attributes like `internal_linkage` need to appear on the first declaration, and can't be added later when declaring an instantiation.</div><div class="">Though I'm not sure if that restriction is artificial, at least in this particular case.</div></div></div></div></blockquote><div class=""><br class=""></div>Well, I can't imagine why you would declare an internal-linkage explicit instantiation, but if you have a need to, I don't see any reason we couldn't allow that.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">The visibility attributes, for better or worse, are more flexible about some of these things already.</div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">Is there a way to explicitly instantiate the vtable and the typeinfo of a type (and give them default visibility), other than to explicitly instantiate the type itself?</div></div></div></div></div></blockquote><div><br class=""></div>For the v-table, unfortunately not. For RTTI, it's the same except that explicitly instantiating a non-dynamic class doesn't eagerly emit RTTI for it.</div><div><br class=""></div><div>Does this matter, though? What explicitly-instantiated class templates in the stdlib actually have virtual me...</div><div><br class=""></div><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""> extern template basic_istream<char>::typeinfo; // obviously not valid, but you get the point</div><div class=""> extern template basic_istream<char>::vtable; // ditto</div></div></div></div></blockquote><div><br class=""></div><div>...oh, right, the stream classes. Ugh.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""> extern template basic_istream<char>& basic_istream<char>::operator>>(bool&);</div><div class=""> extern template basic_istream<char>& basic_istream<char>::operator>>(short&);</div><div class=""><br class=""></div><div class=""> // in the dylib</div><div class=""> template VISIBLE basic_istream<char>::typeinfo; </div><div class=""> template VISIBLE basic_istream<char>::vtable; </div><div class=""> template VISIBLE basic_istream<char>& basic_istream<char>::operator>>(bool&);</div><div class=""> template VISIBLE basic_istream<char>& basic_istream<char>::operator>>(short&);</div><div class=""><br class=""></div><div class="">This would be more straightforward than what we do today, and it would allow us to see what's in the dylib and what's not very easily.</div><div class=""><br class=""></div><div class="">John, is this roughly what you had in mind?</div></div></div></div></div></blockquote><div><br class=""></div>Yeah, this is what I had in mind. Unfortunately, the standard provides no mechanism for instantiating just the v-table/VTT/RTTI without also instantiating all the members.</div><div><br class=""></div><div>From my perspective, it would be reasonable to (1) ask the committee for a standard way of doing this and (2) in the meantime add a vendor-specific attribute for it. I don't know if you'd be willing to consider that; libc++ presumably tries to be more compiler-agnostic. But yeah, I think this would be a much simpler and clearer approach for libc++ to take if we can solve this v-table issue.</div><div><br class=""></div><div>(A reasonable spelling for the standard way of doing this would be something like "template virtual class basic_istream<char>;" or "template typeid class basic_istream<char>;". But we shouldn't use that in a vendor extension without the committee's blessing.)</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Louis</div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">John.</div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word; line-break: after-white-space;"><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class="">In the meantime, this is blocking our ability to use neither `__attribute__((Internal_linkage))` nor `__attribute__((__always_inline__))` on any declaration that may have an extern template declaration (which is basically all declarations, because users can write extern template declarations for std:: components in their own code).</div><div class=""><br class=""></div><div class="">Louis</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">2. If it is legal, then libc++ needs a way to express that a function should either be inlined in the caller, or emitted in the TU and de-duplicated later (I think that’s linkonce_odr), despite there being an extern template declaration promising a definition elsewhere. I think the current situation is that the function gets available_externally linkage instead. Is there a way to express this at the C++ source code level?<br class=""><br class="">Thank you,<br class="">Louis Dionne<br class=""><br class=""><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""><br class=""></blockquote></div></div></div>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""></blockquote></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>