[Patch] Disable -Wtaulological-compare for substituted template types

[David Blaikie]

On Fri, Nov 1, 2013 at 12:15 PM, Arthur O'Dwyer
<arthur.j.odwyer at gmail.com>wrote:

> On Thu, Oct 31, 2013 at 5:52 PM, Richard Trieu <rtrieu at google.com> wrote:
> > On Thu, Oct 31, 2013 at 4:25 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >> Could we just restrict these warnings to only be done on template
> >> patterns, not template specializations? (I know Ted's had some concern
> about
> >> doing work on template patterns in the past because he believed that
> might
> >> create too much work analyzing templates that are never instantiated,
> >> though)
> >
> > I think that would be possible and a cleaner way of approaching this.
> > Currently, Clang warns in both template patters and specializations.
>  That
> > means if you have :
> >
> > template<int Num>
> > bool greater(unsigned Val) {
> >   return Val >= 0;
> > }
> >
> > ... greater<0>(42); ...
> > ... greater<1>(42); ...
> > ... greater<2>(42); ...
> >
> > There would be four warnings on the return line.  Ignoring the three
> > warnings in the specializations and only showing the one from the
> template
> > pattern would be best on cutting down the noise.
>
> Only for -Wtautological-compare, though, right?
>
> I imagine that there are plenty of warnings that would be useful to
> produce during template instantiation, but impossible to detect by
> just looking at the pattern (without checking dependent
> types/expressions). A trivial example would be
> -Wuninitialized for this code:
>
>     template<typename T> T newval() { T t; return t; }
>
> Here, newval<int>() has undefined behavior, but newval<std::string>()
> is perfectly correct.
>
> So whereas -Wtautological-compare empirically gives almost 100% false
> positives on dependent expressions, -Wuninitialized probably gives
> 100% *true* positives.


Certainly. There are many warnings in each of these buckets, but generally
a given warning falls into only one - either it should be done on
instantiations or patterns. (there are some similar issues with macros and
other things (sizeof/decltype of implementation-provided types, etc))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131101/cf6b8bea/attachment.html>