[cfe-dev] Adding a new attribute: no_extern_template

[Hubert Tong via cfe-dev]

>
> I don't necessarily want to redirect you from this course of action;
> pragmatically-speaking, the attribute you're proposing seems very
> reasonable to me, and is probably the right short-to-medium-term solution.
> However:
>
> It seems to me there are two different compilations that we need to care
> about:
>
>  1) the compilation of the DSO itself
>  2) the compilation of a user of the DSO
>
> For (1), we would need to use a compiler that can force-emit the vtable,
> ideally without emitting all inline functions in the class. (If it emits
> too much, we do have ways to prevent the extra symbols being part of the
> DSO's ABI, but it's not ideal.) Any version of GCC can do that (via "inline
> template"), and if we add a standard or vendor-specific feature to clang to
> emit the type info, then recent Clang can do that too. Older Clang and
> other compilers will be left emitting too many symbols, which is likely
> tolerable, because the result should still be correct and building a new
> libc++ DSO with an old Clang is likely something we can discourage.
>
It may be inadvisable anyway to link against a DSO build that is not widely
distributed; however, binaries linked against a DSO build that exports too
much will not load against "proper" DSO builds.


> For (2), it's my understanding that we do not /need/ to prevent users of
> libc++ from emitting their own copies of symbols that are also in the DSO.
> If we don't have a way of saying "the vtable is emitted in the DSO" for a
> particular compiler, the cost is that we may emit an unnecessary but mostly
> harmless copy of the vtable in the client program, not that we will
> miscompile or create an ABI problem.
>
> So I think it might still be viable to switch libc++ entirely to
> per-function explicit instantiations, even before we have ubiquitous
> compiler support to deal with the result. But it's probably worth delaying
> that until such compiler features are at least broadly available, since
> there will be some costs (notably, code size) to compilers for which we
> cannot declare that class type info is available externally.
>
> Unless there are serious concerns with the attribute, I’d like to solicit
>> feedback on the following points:
>>
>> - What entities does it make sense to apply this attribute to? Currently,
>> I'm thinking only static and non-static member functions of templates, for
>> lack of imagination and other use cases. Does it make sense to apply it to
>> static data members? To the vtable and RTTI somehow?
>>
>
> I would expect the attribute to be applicable to all members of templated
> classes that would be explicitly instantiated by an explicit instantiation
> of the enclosing class ([temp.explicit]p10),. That would be member
> functions (static or non-static), member classes (to suppress recursion
> into their members), and static data members.
>
> - What other attributes would be mutually exclusive with this one? Right
>> now I can only think of `internal_linkage`, but is there anything else?
>>
>
> I don't think internal linkage needs to be mutually-exclusive with this
> attribute. I would expect that an internal_linkage + no_extern_template
> function would simply be unaffected by 'extern template', so would still be
> implicitly instantiated if referenced in a context where a definition is
> needed.
>
>
>> Thanks,
>> Louis
>>
>>
>>
>> Also, it’s not a huge reason not to do it, but that would constitute a
>>> very large change in libc++, which does everything opt-out right now.
>>> Comparatively, everything is already in place for libc++ to start using an
>>> hypothetical no_extern_template attribute, and in fact the patch that does
>>> that is like 4 lines. Of course, my search for the right solution is not
>>> primarily motivated by that.
>>>
>>> I think I will start by exploring Reid’s idea of checking for
>>> incompatible visibilities using a visitor, and if that doesn’t take me
>>> anywhere, I’ll reconsider your suggestion. Independently, I’ll draft a C++
>>> proposal to control where RTTI/vtables are instantiated and see where that
>>> idea goes.
>>>
>>> Louis
>>>
>>>
>>>
>>> - What entities does it make sense to apply this attribute to?
>>>> Currently, I'm thinking only static and non-static member functions of
>>>> templates, for lack of imagination and other use cases. Does it make sense
>>>> to apply it to static data members? To the vtable and RTTI somehow?
>>>>
>>>> - What other attributes would be mutually exclusive with this one?
>>>> Right now I can only think of `internal_linkage`, but is there anything
>>>> else?
>>>>
>>>> Finally, I'd also welcome any guidance on how to best achieve this in
>>>> Clang. So far, I've achieved something that "works" by forcing declarations
>>>> with `GVA_AvailableExternally` linkage to have `GVA_DiscardableODR` linkage
>>>> (in `adjustGVALinkageForAttributes`). I think this is probably the wrong
>>>> approach but I’m a Clang beginner, so I’m looking for advice if somebody
>>>> has some. I'll soon publish an early code review on Phabricator to ease the
>>>> process of getting feedback on the code itself.
>>>>
>>>> Thanks,
>>>> Louis
>>>>
>>>> [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058460.html
>>>> [2]: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> 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/20180823/3346285f/attachment.html>