[cfe-dev] Clang emits unreachable `internal linkage` constructor

[Mehdi Amini via cfe-dev]

> On Oct 19, 2016, at 9:14 AM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Thu, Oct 13, 2016 at 10:46 PM, Mehdi Amini via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> The problem is that the linkage “available_externally" is a “lie”: there is an external template instantiation in the header, but it is marked “visibility hidden”. So the function cannot be linked to in the libc++ dylib. (I think it’d work with a static libc++).
> 
> IMO this is the real problem. If basic_string isn't actually available externally, why have explicit template instaniation declarations in <string>? IIRC John put these back for some reason, but if all of basic_string is always_inline, what is the point? 

It seems a general issue though: how do you mix visibility hidden and external template? This is fine if you link statically, but can’t be exported outside of a DSO.
Should we design a warning for when we mix external template with visibility hidden?

Also the intent for libc++ seems that we’d like most of the class to be external template but for some method. Maybe it could be achieved with a base class that would be external template, and the derived wouldn’t? (The derived would contain the current “hidden” method).


> I also think libc++ should stop abusing always_inline for linkage purposes. We should use __attribute__((internal_linkage)) instead, and allow the optimizer to make informed inlining decisions.

We have another thread for this: http://lists.llvm.org/pipermail/cfe-dev/2016-October/051151.html <http://lists.llvm.org/pipermail/cfe-dev/2016-October/051151.html> ; feel free to chime in there!

— 
Mehdi

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