[cfe-dev] anchoring explicit template instantiations
Douglas Gregor
dgregor at apple.com
Sat Dec 3 13:07:14 PST 2011
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 --------------
More information about the cfe-dev
mailing list