[llvm-bugs] [Bug 28815] New: Incorrect/inconsistent warning on use of static member of class template

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Aug 2 05:40:06 PDT 2016


https://llvm.org/bugs/show_bug.cgi?id=28815

            Bug ID: 28815
           Summary: Incorrect/inconsistent warning on use of static member
                    of class template
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: john.brawn.123 at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider the following example:

  template<typename T> class Example {
  public:
    static T member_fn();
    static T member_var;
  };
  template<typename T> T fn();
  template<int n> int var;

  int test1() {
    return Example<int>::member_fn();
  }

  int test2() {
    return Example<int>::member_var;
  }

  int test3() {
    return fn<int>();
  }

  int test4() {
    return var<0>;
  }

Here we have a definition of a template class Example, which declares (but does
not define) static member function member_fn and static data member member_var.
We also have the declaration (but not definition) of function template fn and
variable template var. We then have four functions which implicitly instantiate
each of these things that we have declared but not defined.

Current behaviour of clang is to warn only on the instantiation of member_var:

  tmp.cpp:15:24: warning: instantiation of variable 'Example<int>::member_var'
required here, but no definition is available
        [-Wundefined-var-template]
    return Example<int>::member_var;
                         ^

I believe that the warning is incorrect, or if it is correct then all four
instantiations should be giving a warning.


The relevant part of C++14 (though the C++11 wording is effectively the same,
as far as I can tell, other than not mentioning variable templates) is Section
14 paragraph 6:

  A function template, member function of a class template, variable template,
or static data member of a
  class template shall be defined in every translation unit in which it is
implicitly instantiated (14.7.1) unless
  the corresponding specialization is explicitly instantiated (14.7.2) in some
translation unit; no diagnostic is
  required.

It looks like clang is warning a potential violation of the above, except that
if these things that are declared but not defined are explicitly instantiated
in some translation unit then there's no problem. Clang does give the warning
(in C++11 and C++14 mode)

  tmp.cpp:15:24: note: add an explicit instantiation declaration to suppress
this warning if 'Example<int>::member_var' is explicitly instantiated in
        another translation unit
    return Example<int>::member_var;

however I can find nothing in the standard that says that an explicit
instantiation declaration is _required_ when there is no template definition.
Indeed my reading of the section on explicit instantiation is that the point of
an explicit instantiation declaration is that it's used when there _is_ a
template definition, in order to suppress the implicit instantiation of the
definition. Adding an explicit instantiation declaration is also a hassle as it
has to be done for every static data member of every specialization of the
template class, whereas having no template definition just needs to be done
once in the definition of the template class.

Also if I'm wrong and a template definition of member_var is required here,
then surely a template definition / explicit instantiation declaration of
everything else is required. I can find nothing in the standard which treats
static data members differently than everything else with regards to this,
though I do see that template classes are required to be defined when
implicitly instantiated (section 14.7.1 paragraph 8).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160802/a3574a64/attachment.html>


More information about the llvm-bugs mailing list