<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 7:07 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Jun 3, 2016, at 7:05 PM, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> On Jun 3, 2016, at 8:43 AM, David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> I assume there's a good reason we don't do this - but I can't quite figure it out off the top of my head.<br>
>><br>
>> Any thoughts?<br>
><br>
> The translation unit that emits the key function is required to emit the v-table symbol with as a strong definition with the type's visibility.  It is not required to emit visible symbols for any of the inline virtual functions.  It is, of course, required to emit those functions as part of emitting the v-table; but it doesn't have to provide symbols for them at all, because even if it were possible to take the address of a virtual member function in a comparable way, there is no way to take that address *via the v-table* and so the v-table's reference may be to its own implementation.  This is good because it allows virtual methods to be given hidden visibility by default; it also permits v-tables to contain specialized method implementations, e.g. methods that use a known most-derived class.<br>
<br>
</span>To be clear, your idea would be a reasonable guarantee to make in a revised C++ ABI; it's just that it's not guaranteed to work under the current one.<br></blockquote><div><br></div><div>Ah, right. Thanks for the context, John!<br><br>(in throwing this around with Chandler & Richard, we're also considering about an even bigger (& user facing, not just ABI breaking) possibility: (we discussed a few variants, but this was one of them) require that all inline member functions originally declared inline be defined in any translation unit that defines a non-inline member function (or perhaps just virtual ones?) - and use that to emit weak_odr+available_externally definitions of those inline functions (mostly because we have protobufs with lots and lots of inline functions). I may try prototyping this to see how valuable it is to us, then figure out the finer points if it is worth pursuing.<br><br>This starts to look a lot like modules codegen would look like (where we would build an object file from a module definition with weak_odr definitions of any inline functions, with debug info as well as debug info for any types defined there (like the current modules debug info), etc))</div></div></div></div>