[LLVMbugs] [Bug 14908] New: Optional diagnostic for template functions with unused template arguments?
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Jan 10 14:44:15 PST 2013
http://llvm.org/bugs/show_bug.cgi?id=14908
Bug #: 14908
Summary: Optional diagnostic for template functions with unused
template arguments?
Product: clang
Version: trunk
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
AssignedTo: unassignedclangbugs at nondot.org
ReportedBy: arthur.j.odwyer at gmail.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
Classification: Unclassified
I see how functions such as
template <template<int> class T, int n1, template<int> class U, int n2>
void foo(T<n1>, T<n2>);
could be useful in some cases... but for one particular application it would be
useful to me to have a compiler diagnostic that would statically diagnose
template functions with unused template arguments ("U" in the above example).
If I try to *call*
foo(myT, myU);
I'll get a verbose diagnostic that includes the note
test.cc:3:6: note: candidate template ignored: deduced conflicting
templates for parameter ''S1,3
void foo(T<n1> tn1, T<n2> un2);
^
or
test.cc:3:6: note: candidate template ignored: couldn't infer template
argument 'U'
void foo(T<n1> tn1, T<n2> un2);
^
but it would be useful to me to have a compiler diagnostic that would
statically diagnose this kind of undeducible-argument mistake right away,
regardless of whether the problematic template is actually used in the program.
Again, I understand that such templates can theoretically be useful, so this
wouldn't be a warning by default, and maybe the whole idea of "optional"
warnings doesn't fit with Clang's philosophy. But I figured I'd file the
feature request anyway.
(The way to use "foo" in the example above is to explicitly specify the
template arguments:
foo<T,42,U,27>(myT, myU);
)
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list