[cfe-dev] anchoring explicit template instantiations

[Douglas Gregor]

On Dec 1, 2011, at 12:12 AM, David Blaikie wrote:

> [Forwarding to cfe-dev for the purpose of discussing what to do with
> weak-vtables in explicit template instantiations - when/how should the
> warning be emitted in this case, etc, details below]
> 
> For a bit of an experiment I've been trying to compile LLVM & Clang
> with -Weverything (disabling any errors that seem like more noise/less
> interesting). One warning I've recently hit a few instances of is
> -Wweak-vtable which is, in fact, an explicitly documented LLVM coding
> standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch
> ). Some instances of this have been easy to fix but a particular set of
> them have been a little more problematic.
> 
> If you take a look at CommandLine.h/CommandLine.cpp you'll see some
> code that basically amounts to this:
> 
> header:
> 
>    template<class DataType>
>    class basic_parser {
>      virtual ~basic_parser() {}
>    };
> 
>    __extension__ extern template class basic_parser<bool>;
> 
> implementation:
> 
>    template class basic_parser<bool>;
> 
> (both lines are wrapped in a macro (Compiler.h:77-88) & are no-ops in
> non-GNUC compilers (where the __extension__ extern is not available))
> 
> Adding in a virtual anchor function with an out-of-line (but still
> template) definition (either in the header or the cpp file) does not
> remove the warning.

Right. The emitted vtable still has to be weak.

> So the question is - is there any way to anchor these explicit
> instantiations? Should the warning (& possibly even the underlying
> implementation/codegen) be fixed to not flag this particular case of
> the GNUC extension - since these vtables should be able to be anchored
> (with the addition of such an out of line definition - either in the
> header or cpp file (though in this case I don't think it should be
> necessary in the header - since only these explicit instantiations of
> basic_parser are used))? Is there a portable way to address the
> warning?

I don't think there is a portable way to deal with this. I've attached a proposal I wrote a while back to introduce a new attribute allowing us to emit strong symbols for the cases where the user tells us we can. I never implemented it, though.

>  If not, should the warning just be silent, or have a separate
> group/warning for this case so the actionable warning can remain while
> this one can be disabled?


Yes, it makes sense for explicit instantiations to have a different warning group, so the non-actionable warnings can be silenced separately.

	- Doug

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