[LLVMdev] anchoring explicit template instantiations

[Chris Lattner]

On Nov 29, 2011, at 12:26 AM, David Blaikie wrote:
> 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 (see attached patch -
> if it looks good to anyone I'll check that in) but a particular set of
> them have been a little more problematic.

Nice, please commit your patch.  I don't know about explicit instantiations though, maybe a C++ guru on the clang list knows.

-Chris

> 
> 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.
> 
> 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? 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?
> 
> Thanks,
> - David
> <anchors.diff>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev