| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As Mattias Eriksson has reported in PR35009, in C, for enums, the underlying type should
be used when checking for the tautological comparison, unlike C++, where the enumerator
values define the value range. So if not in CPlusPlus mode, use the enum underlying type.
Also, i have discovered a problem (a crash) when evaluating tautological-ness of the following comparison:
```
enum A { A_a = 0 };
if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
return 0;
```
This affects both the C and C++, but after the first fix, only C++ code was affected.
That was also fixed, while preserving (i think?) the proper diagnostic output.
And while there, attempt to enhance the test coverage.
Yes, some tests got moved around, sorry about that :)
Fixes PR35009
Reviewers: aaron.ballman, rsmith, rjmccall
Reviewed By: aaron.ballman
Subscribers: Rakete1111, efriedma, materi, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D39122
llvm-svn: 316268
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As Aaron Ballman has pointed out, that is not really correct.
So the key problem there is the invalidity of the testcase.
Revert r313747, and rework testcase in such a way, so these
details (platform-specific default enum sigdness) are
accounted for.
Also, add a C++-specific testcase.
llvm-svn: 313756
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommit. Original commit was reverted because buildbots broke.
The error was only reproducible in the build with assertions.
The problem was that the diagnostic expected true/false as
bool, while it was provided as string "true"/"false".
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: 313745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r313677.
Buildbots fail with assertion failure
Failing Tests (7):
Clang :: Analysis/null-deref-ps.c
Clang :: CodeGen/enum.c
Clang :: Sema/compare.c
Clang :: Sema/outof-range-constant-compare.c
Clang :: Sema/tautological-unsigned-enum-zero-compare.c
Clang :: Sema/tautological-unsigned-zero-compare.c
Clang :: SemaCXX/compare.cpp
llvm-svn: 313683
|
|
|
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
|
