[cfe-dev] [llvm-dev] Is it really valid to discard externally instantiated functions from a TU when marked inline?

[John McCall via cfe-dev]

> On Jul 18, 2018, at 4:11 PM, Louis Dionne <ldionne at apple.com> wrote:
>> On Jul 18, 2018, at 13:53, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>>> On Jul 18, 2018, at 5:40 AM, Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca>> wrote:
>>> That's a very good point, somehow I hadn't thought of it before.
>>> 
>>> 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.
>>> Though I'm not sure if that restriction is artificial, at least in  this particular case.
>> 
>> 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.
>> 
>> The visibility attributes, for better or worse, are more flexible about some of these things already.
> 
> 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?

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.

Does this matter, though?  What explicitly-instantiated class templates in the stdlib actually have virtual me...

>     extern template basic_istream<char>::typeinfo; // obviously not valid, but you get the point
>     extern template basic_istream<char>::vtable; // ditto

...oh, right, the stream classes.  Ugh.

>     extern template basic_istream<char>& basic_istream<char>::operator>>(bool&);
>     extern template basic_istream<char>& basic_istream<char>::operator>>(short&);
> 
>     // in the dylib
>     template VISIBLE basic_istream<char>::typeinfo; 
>     template VISIBLE basic_istream<char>::vtable; 
>     template VISIBLE basic_istream<char>& basic_istream<char>::operator>>(bool&);
>     template VISIBLE basic_istream<char>& basic_istream<char>::operator>>(short&);
> 
> 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.
> 
> John, is this roughly what you had in mind?

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.

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.

(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.)

John.

> 
> Louis
> 
>> John.
>> 
>>> 
>>> 
>>>  
>>> 
>>> John.
>>> 
>>>> 
>>>> 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).
>>>> 
>>>> Louis
>>>> 
>>>>> 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?
>>>>> 
>>>>> Thank you,
>>>>> Louis Dionne
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>> 
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180718/c160a0a8/attachment.html>