smeenai added a comment.
I posted to cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-December/056450.html
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi
bcain added a comment.
In https://reviews.llvm.org/D39462#959822, @phosek wrote:
> FWIW we've already rolled Clang that contains
> `-Wtautological-constant-compare` to our codebase and we had to set
> `-Wno-tautological-constant-compare` globally because we were getting bogus
> warnings in man
phosek added a comment.
FWIW we've already rolled Clang that contains `-Wtautological-constant-compare`
to our codebase and we had to set `-Wno-tautological-constant-compare` globally
because we were getting bogus warnings in many places, similarly to
https://reviews.llvm.org/D41368. If that wa
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#936566, @bcain wrote:
> I'd like to understand/resurrect this change, so I'll try to summarize.
> Please correct this as appropriate:
>
> 1. We got here because libc++ has code that triggers a warning for some
> targets (those whos
bcain added a comment.
I'd like to understand/resurrect this change, so I'll try to summarize. Please
correct this as appropriate:
1. We got here because libc++ has code that triggers a warning for some targets
(those whose `int` and `long` have the same size).
2. This change would "move" the
rjmccall added a comment.
That's the template type-propagation problem: the template was invoked with a
size_t, but that's erased down to the canonical type by the template machinery.
That can't be fixed within the template, but at use sites, we could
theoretically recognize that e.g. the resu
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#922847, @rjmccall wrote:
> In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> >
> > > I don't speak for the entire project, but I'm not sure I'm interested
rjmccall added a comment.
I see. The problem now, though, is that things involving, say, a size_t and a
numeric_limits will never warn.
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> I don't speak for the entire project, but I'm not sure I'm interested in the
> diagnostic you're actually offering to contribute here. It may produce a
> warning on your specific test case, but I think it
smeenai added a comment.
In https://reviews.llvm.org/D39462#922847, @rjmccall wrote:
> In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
> >
> > > I don't speak for the entire project, but I'm not sure I'm interested in
rjmccall added a comment.
I don't speak for the entire project, but I'm not sure I'm interested in the
diagnostic you're actually offering to contribute here. It may produce a
warning on your specific test case, but I think it's really much too rigid and
will lead to massive false positives.
rjmccall added a comment.
In https://reviews.llvm.org/D39462#922844, @lebedev.ri wrote:
> In https://reviews.llvm.org/D39462#922826, @rjmccall wrote:
>
> > I don't speak for the entire project, but I'm not sure I'm interested in
> > the diagnostic you're actually offering to contribute here. It
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#917421, @rjmccall wrote:
> So, that change makes this very interesting, because I think the right way of
> looking at it is as the first in a larger family of warnings that attempt to
> treat typedefs as if they were a much stronger
rjmccall added a comment.
So, that change makes this very interesting, because I think the right way of
looking at it is as the first in a larger family of warnings that attempt to
treat typedefs as if they were a much stronger type-system feature, i.e. that
warn about all sorts of conversions
lebedev.ri updated this revision to Diff 121743.
lebedev.ri edited the summary of this revision.
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#912011, @rjmccall wrote:
> The actual choice of integer type is not stable across targets any more than
> the size is. In practice, peo
efriedma added a comment.
> The internal canonical types are compared, so all this typedef sugar will be
> silently ignored.
Yes, and that's precisely the problem. On many 32-bit platforms, both "size_t"
and "uint32_t" are typedefs for "unsigned int"; on some 32-bit platforms,
"size_t" is an
smeenai added a comment.
This solves the issue in https://reviews.llvm.org/D39149, at least.
Repository:
rL LLVM
https://reviews.llvm.org/D39462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinf
lebedev.ri updated this revision to Diff 121044.
lebedev.ri added a comment.
In https://reviews.llvm.org/D39462#912011, @rjmccall wrote:
> The actual choice of integer type is not stable across targets any more than
> the size is. In practice, people often don't use int and long, they use
> st
rjmccall added a comment.
The actual choice of integer type is not stable across targets any more than
the size is. In practice, people often don't use int and long, they use
standard typedefs like size_t and uint64_t, but the actual type chosen for
size_t is arbitrary when there are multiple
: [Sema] Implement
-Wmaybe-tautological-constant-compare for when the tautologicalness is
data model dependent
To: lebedev...@gmail.com, rich...@metafoo.co.uk, rjmcc...@gmail.com,
dblai...@gmail.com
Cc: mclow.li...@gmail.com, aaron.ball...@gmail.com,
bc...@codeaurora.org, smee...@fb.com, jkor...@apple.com
20 matches
Mail list logo
