maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/tautological-constant-enum-...

407 lines
10 KiB
C
Raw Normal View History

[Sema] -Wtautological-constant-compare is too good. Cripple it. Summary: The diagnostic was mostly introduced in D38101 by me, as a reaction to wasting a lot of time, see [[ https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20171009/206427.html | mail ]]. However, the diagnostic is pretty dumb. While it works with no false-positives, there are some questionable cases that are diagnosed when one would argue that they should not be. The common complaint is that it diagnoses the comparisons between an `int` and `long` when compiling for a 32-bit target as tautological, but not when compiling for 64-bit targets. The underlying problem is obvious: data model. In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are 64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer are 32-bit). I.e. the common pattern is: (pseudocode) ``` #include <limits> #include <cstdint> int main() { using T1 = long; using T2 = int; T1 r; if (r < std::numeric_limits<T2>::min()) {} if (r > std::numeric_limits<T2>::max()) {} } ``` As an example, D39149 was trying to fix this diagnostic in libc++, and it was not well-received. This *could* be "fixed", by changing the diagnostics logic to something like `if the types of the values being compared are different, but are of the same size, then do diagnose`, and i even attempted to do so in D39462, but as @rjmccall rightfully commented, that implementation is incomplete to say the least. So to stop causing trouble, and avoid contaminating upcoming release, lets do this workaround: * move these three diags (`warn_unsigned_always_true_comparison`, `warn_unsigned_enum_always_true_comparison`, `warn_tautological_constant_compare`) into it's own `-Wtautological-constant-in-range-compare` * Disable them by default * Make them part of `-Wextra` * Additionally, give `warn_tautological_constant_compare` it's own flag `-Wtautological-type-limit-compare`. I'm not happy about that name, but i can't come up with anything better. This way all three of them can be enabled/disabled either altogether, or one-by-one. Reviewers: aaron.ballman, rsmith, smeenai, rjmccall, rnk, mclow.lists, dim Reviewed By: aaron.ballman, rsmith, dim Subscribers: thakis, compnerd, mehdi_amini, dim, hans, cfe-commits, rjmccall Tags: #clang Differential Revision: https://reviews.llvm.org/D41512 llvm-svn: 321691
2018-01-03 16:45:19 +08:00
// RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only -DUNSIGNED -Wtautological-constant-in-range-compare -verify %s
// RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only -DSIGNED -Wtautological-constant-in-range-compare -verify %s
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
// RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only -DUNSIGNED -DSILENCE -Wno-tautological-constant-compare -verify %s
// RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only -DSIGNED -DSILENCE -Wno-tautological-constant-compare -verify %s
int main() {
enum A { A_a = 2 };
enum A a;
#ifdef SILENCE
// expected-no-diagnostics
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#else
// If we promote to unsigned, it doesn't matter whether the enum's underlying
// type was signed.
if (a < 0U) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
return 0;
if (0U >= a)
return 0;
if (a > 0U)
return 0;
if (0U <= a) // expected-warning {{comparison of 0 <= unsigned enum expression is always true}}
return 0;
if (a <= 0U)
return 0;
if (0U > a) // expected-warning {{comparison of 0 > unsigned enum expression is always false}}
return 0;
if (a >= 0U) // expected-warning {{comparison of unsigned enum expression >= 0 is always true}}
return 0;
if (0U < a)
return 0;
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a < 4294967295U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295U >= a) // expected-warning {{comparison 4294967295 >= 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > 4294967295U) // expected-warning {{comparison 'enum A' > 4294967295 is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295U <= a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= 4294967295U) // expected-warning {{comparison 'enum A' <= 4294967295 is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295U > a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= 4294967295U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295U < a) // expected-warning {{comparison 4294967295 < 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a < 2147483647U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (2147483647U >= a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > 2147483647U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (2147483647U <= a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= 2147483647U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (2147483647U > a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= 2147483647U)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (2147483647U < a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#endif
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#if defined(UNSIGNED) && !defined(SILENCE)
if (a < 0) // expected-warning {{comparison of unsigned enum expression < 0 is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (0 >= a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > 0)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (0 <= a) // expected-warning {{comparison of 0 <= unsigned enum expression is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= 0)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (0 > a) // expected-warning {{comparison of 0 > unsigned enum expression is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= 0) // expected-warning {{comparison of unsigned enum expression >= 0 is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (0 < a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a < 4294967295)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 >= a) // expected-warning {{comparison 4294967295 >= 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > 4294967295) // expected-warning {{comparison 'enum A' > 4294967295 is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 <= a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= 4294967295) // expected-warning {{comparison 'enum A' <= 4294967295 is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 > a)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= 4294967295)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 < a) // expected-warning {{comparison 4294967295 < 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#else // SIGNED || SILENCE
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
if (a < 0)
return 0;
if (0 >= a)
return 0;
if (a > 0)
return 0;
if (0 <= a)
return 0;
if (a <= 0)
return 0;
if (0 > a)
return 0;
if (a >= 0)
return 0;
if (0 < a)
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#ifndef SILENCE
if (a < 4294967295) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 >= a) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > 4294967295) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 <= a) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= 4294967295) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 > a) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= 4294967295) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (4294967295 < a) // expected-warning {{comparison of constant 4294967295 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#else
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
if (a < 4294967295)
return 0;
if (4294967295 >= a)
return 0;
if (a > 4294967295)
return 0;
if (4294967295 <= a)
return 0;
if (a <= 4294967295)
return 0;
if (4294967295 > a)
return 0;
if (a >= 4294967295)
return 0;
if (4294967295 < a)
return 0;
Revert "Unify implementation of our two different flavours of -Wtautological-compare." > Unify implementation of our two different flavours of -Wtautological-compare. > > In so doing, fix a handful of remaining bugs where we would report false > positives or false negatives if we promote a signed value to an unsigned type > for the comparison. This caused a new warning in Chromium: ../../base/trace_event/trace_log.cc:1545:29: error: comparison of constant 64 with expression of type 'unsigned int' is always true [-Werror,-Wtautological-constant-out-of-range-compare] DCHECK(handle.event_index < TraceBufferChunk::kTraceBufferChunkSize); ~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'unsigned int' is really a 6-bit bitfield, which is why it's always less than 64. I thought we didn't use to warn (with out-of-range-compare) when comparing against the boundaries of a type? llvm-svn: 320162
2017-12-09 00:54:08 +08:00
#endif
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#endif
#if defined(SIGNED) && !defined(SILENCE)
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
if (a < -2147483648) // expected-warning {{comparison 'enum A' < -2147483648 is always false}}
return 0;
if (-2147483648 >= a)
return 0;
if (a > -2147483648)
return 0;
if (-2147483648 <= a) // expected-warning {{comparison -2147483648 <= 'enum A' is always true}}
return 0;
if (a <= -2147483648)
return 0;
if (-2147483648 > a) // expected-warning {{comparison -2147483648 > 'enum A' is always false}}
return 0;
if (a >= -2147483648) // expected-warning {{comparison 'enum A' >= -2147483648 is always true}}
return 0;
if (-2147483648 < a)
return 0;
if (a < 2147483647)
return 0;
if (2147483647 >= a) // expected-warning {{comparison 2147483647 >= 'enum A' is always true}}
return 0;
if (a > 2147483647) // expected-warning {{comparison 'enum A' > 2147483647 is always false}}
return 0;
if (2147483647 <= a)
return 0;
if (a <= 2147483647) // expected-warning {{comparison 'enum A' <= 2147483647 is always true}}
return 0;
if (2147483647 > a)
return 0;
if (a >= 2147483647)
return 0;
if (2147483647 < a) // expected-warning {{comparison 2147483647 < 'enum A' is always false}}
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#elif defined(UNSIGNED) && !defined(SILENCE)
#ifndef SILENCE
if (a < -2147483648) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (-2147483648 >= a) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a > -2147483648) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (-2147483648 <= a) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a <= -2147483648) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (-2147483648 > a) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always false}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (a >= -2147483648) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
if (-2147483648 < a) // expected-warning {{comparison of constant -2147483648 with expression of type 'enum A' is always true}}
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#else
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
if (a < -2147483648)
return 0;
if (-2147483648 >= a)
return 0;
if (a > -2147483648)
return 0;
if (-2147483648 <= a)
return 0;
if (a <= -2147483648)
return 0;
if (-2147483648 > a)
return 0;
if (a >= -2147483648)
return 0;
if (-2147483648 < a)
return 0;
Unify implementation of our two different flavours of -Wtautological-compare, and fold together into a single function. In so doing, fix a handful of remaining bugs where we would report false positives or false negatives if we promote a signed value to an unsigned type for the comparison. This re-commits r320122 and r320124, minus two changes: * Comparisons between a constant and a non-constant expression of enumeration type never warn, not even if the constant is out of range. We should be warning about the creation of such a constant, not about its use. * We do not use more precise bit-widths for comparisons against bit-fields. The more precise diagnostics probably are the right thing, but we should consider moving them under their own warning flag. Other than the refactoring, this patch should only change the behavior for the buggy cases (where the warnings didn't take into account that promotion from signed to unsigned can leave a range of inaccessible values in the middle of the promoted type). llvm-svn: 320211
2017-12-09 06:57:11 +08:00
#endif
[Sema] Fixes for enum handling for tautological comparison diagnostics 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
2017-10-22 00:44:03 +08:00
if (a < 2147483647)
return 0;
if (2147483647 >= a)
return 0;
if (a > 2147483647)
return 0;
if (2147483647 <= a)
return 0;
if (a <= 2147483647)
return 0;
if (2147483647 > a)
return 0;
if (a >= 2147483647)
return 0;
if (2147483647 < a)
return 0;
#endif
return 1;
}
// https://bugs.llvm.org/show_bug.cgi?id=35009
int PR35009() {
enum A { A_a = 2 };
enum A a;
// in C, this should not warn.
if (a < 1)
return 0;
if (1 >= a)
return 0;
if (a > 1)
return 0;
if (1 <= a)
return 0;
if (a <= 1)
return 0;
if (1 > a)
return 0;
if (a >= 1)
return 0;
if (1 < a)
return 0;
if (a == 1)
return 0;
if (1 != a)
return 0;
if (a != 1)
return 0;
if (1 == a)
return 0;
if (a < 1U)
return 0;
if (1U >= a)
return 0;
if (a > 1U)
return 0;
if (1U <= a)
return 0;
if (a <= 1U)
return 0;
if (1U > a)
return 0;
if (a >= 1U)
return 0;
if (1U < a)
return 0;
if (a == 1U)
return 0;
if (1U != a)
return 0;
if (a != 1U)
return 0;
if (1U == a)
return 0;
if (a < 2)
return 0;
if (2 >= a)
return 0;
if (a > 2)
return 0;
if (2 <= a)
return 0;
if (a <= 2)
return 0;
if (2 > a)
return 0;
if (a >= 2)
return 0;
if (2 < a)
return 0;
if (a == 2)
return 0;
if (2 != a)
return 0;
if (a != 2)
return 0;
if (2 == a)
return 0;
if (a < 2U)
return 0;
if (2U >= a)
return 0;
if (a > 2U)
return 0;
if (2U <= a)
return 0;
if (a <= 2U)
return 0;
if (2U > a)
return 0;
if (a >= 2U)
return 0;
if (2U < a)
return 0;
if (a == 2U)
return 0;
if (2U != a)
return 0;
if (a != 2U)
return 0;
if (2U == a)
return 0;
if (a < 3)
return 0;
if (3 >= a)
return 0;
if (a > 3)
return 0;
if (3 <= a)
return 0;
if (a <= 3)
return 0;
if (3 > a)
return 0;
if (a >= 3)
return 0;
if (3 < a)
return 0;
if (a == 3)
return 0;
if (3 != a)
return 0;
if (a != 3)
return 0;
if (3 == a)
return 0;
if (a < 3U)
return 0;
if (3U >= a)
return 0;
if (a > 3U)
return 0;
if (3U <= a)
return 0;
if (a <= 3U)
return 0;
if (3U > a)
return 0;
if (a >= 3U)
return 0;
if (3U < a)
return 0;
if (a == 3U)
return 0;
if (3U != a)
return 0;
if (a != 3U)
return 0;
if (3U == a)
return 0;
return 1;
}