Summary:
As requested by Sam McCall:
> Enums (not new I guess). Typical case: if (enum < 0 || enum > MAX)
> The warning strongly suggests that the enum < 0 check has no effect
> (for enums with nonnegative ranges).
> Clang doesn't seem to optimize such checks out though, and they seem
> likely to catch bugs in some cases. Yes, only if there's UB elsewhere,
> but I assume not optimizing out these checks indicates a deliberate
> decision to stay somewhat compatible with a technically-incorrect
> mental model.
> If this is the case, should we move these to a
> -Wtautological-compare-enum subcategory?
Reviewers: rjmccall, rsmith, aaron.ballman, sammccall, bkramer, djasper
Reviewed By: aaron.ballman
Subscribers: jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37629
llvm-svn: 313677
Summary:
This is a first half(?) of a fix for the following bug:
https://bugs.llvm.org/show_bug.cgi?id=34147 (gcc -Wtype-limits)
GCC's -Wtype-limits does warn on comparison of unsigned value
with signed zero (as in, with 0), but clang only warns if the
zero is unsigned (i.e. 0U).
Also, be careful not to double-warn, or falsely warn on
comparison of signed/fp variable and signed 0.
Yes, all these testcases are needed.
Testing: $ ninja check-clang-sema check-clang-semacxx
Also, no new warnings for clang stage-2 build.
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37565
llvm-svn: 312750
"bottom-up" when implicit casts and comparisons are inserted, compute them
"top-down" when the full expression is finished. Makes it easier to
coordinate warnings and thus implement -Wconversion for signedness
conversions without double-warning with -Wsign-compare. Also makes it possible
to realize that a signedness conversion is okay because the context is
performing the inverse conversion. Also simplifies some logic that was
trying to calculate the ultimate comparison/result type and getting it wrong.
Also fixes a problem with the C++ explicit casts which are often "implemented"
in the AST with a series of implicit cast expressions.
llvm-svn: 103174
for -Wsign-compare and -Wconversion, and use that coordinated logic to drive
both diagnostics. The new logic works more transparently with implicit
conversions, conditional operators, etc., as well as bringing -Wconversion's
ability to deal with pseudo-closed operations (e.g. arithmetic on shorts) to
-Wsign-compare.
Fixes PRs 5887, 5937, 5938, and 5939.
llvm-svn: 92823
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
* If the unsigned type is smaller than the signed type, never warn, because
its value will not change when zero-extended to the larger type.
* If we're testing for (in)equality, and the unsigned value is an integer
constant whose sign bit is not set, never warn, because even though the
signed value might change, it can't affect the result of the equality.
Also make the comparison test cases much more rigorous, and have them expose
the subtle differences between C and C++ here.
llvm-svn: 86242
DiagnoseSignCompare into Sema::CheckSignCompare and call it from more places.
Add some enumerator tests. These seem to expose some oddities in the
types we're converting C++ enumerators to; in particular, they're converting
to unsigned before int, which seems to contradict 4.5 [conv.prom] p2.
Note to self: stop baiting Doug in my commit messages.
llvm-svn: 86128
avoid emitting a warning on "someptr > 0". This is obviously questionable (they
could use != instead) but is reasonable, and the warning "ordered comparison
between pointer and integer" didn't make a ton of sense because 0 is a valid
null pointer constant.
Just silence the warning in this case, it is unlikely to indicate a bug.
llvm-svn: 79743
using "-parse-ast -verify".
Updated all test cases (using a sed script) that invoked -parse-ast-check to
now use -parse-ast -verify.
Fixed a bug where using "-verify" instead of "-parse-ast-check" would not
correctly create the DiagClient needed to accumulate diagnostics.
llvm-svn: 42365
Modified Type::typesAreCompatible() to use the above.
This fixes the following bug submitted by Keith Bauer (thanks!).
int equal(char *a, const char *b)
{
return a == b;
}
Also tweaked Sema::CheckCompareOperands() to ignore the qualifiers when
comparing two pointer types (though it doesn't relate directly to this bug).
llvm-svn: 41476
char *C;
C != ((void*)0);
Should not warn about incompatible pointer types. Also, make sure to
insert an implicit conversion even if the operand is null.
llvm-svn: 41408
Roman Lebedev