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/sign-compare-enum.c

78 lines
1.9 KiB
C
Raw Normal View History

[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
// RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only -verify -Wsign-compare %s
// RUN: %clang_cc1 -triple=x86_64-pc-win32 -fsyntax-only -verify -Wsign-compare %s
// RUN: %clang_cc1 -x c++ -triple=x86_64-pc-linux-gnu -fsyntax-only -verify -Wsign-compare %s
// RUN: %clang_cc1 -x c++ -triple=x86_64-pc-win32 -fsyntax-only -verify -Wsign-compare %s
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
// Check that -Wsign-compare is off by default.
// RUN: %clang_cc1 -triple=x86_64-pc-linux-gnu -fsyntax-only -verify -DSILENCE %s
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
#ifdef SILENCE
// expected-no-diagnostics
#endif
enum PosEnum {
A_a = 0,
A_b = 1,
A_c = 10
};
static const int message[] = {0, 1};
int test_pos(enum PosEnum a) {
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
if (a < 2)
return 0;
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
// No warning, except in Windows C mode, where PosEnum is 'int' and it can
// take on any value according to the C standard.
#if !defined(SILENCE) && defined(_WIN32) && !defined(__cplusplus)
// expected-warning@+2 {{comparison of integers of different signs}}
#endif
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
if (a < 2U)
return 0;
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
unsigned uv = 2;
#if !defined(SILENCE) && defined(_WIN32) && !defined(__cplusplus)
// expected-warning@+2 {{comparison of integers of different signs}}
#endif
if (a < uv)
return 1;
#if !defined(SILENCE) && defined(_WIN32) && !defined(__cplusplus)
// expected-warning@+2 {{comparison of integers of different signs}}
#endif
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
if (a < sizeof(message)/sizeof(message[0]))
return 0;
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
return 4;
}
enum NegEnum {
NE_a = -1,
NE_b = 0,
NE_c = 10
};
int test_neg(enum NegEnum a) {
if (a < 2)
return 0;
#ifndef SILENCE
// expected-warning@+2 {{comparison of integers of different signs}}
#endif
if (a < 2U)
return 0;
unsigned uv = 2;
#ifndef SILENCE
// expected-warning@+2 {{comparison of integers of different signs}}
#endif
if (a < uv)
return 1;
#ifndef SILENCE
// expected-warning@+2 {{comparison of integers of different signs}}
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
#endif
[Sema] Don't mark plain MS enums as fixed Summary: This fixes a flaw in our AST: PR27098 MSVC always gives plain enums the underlying type 'int'. Clang does this as well, but we claim the enum is "fixed", as if the user actually wrote ': int'. It means we end up emitting spurious -Wsign-compare warnings on code like this: enum Vals { E1, E2, E3 }; bool f(unsigned v1, Vals v2) { return v1 == v2; } We think 'v2' can take on negative values because we think 'Vals' is fixed. This fixes that. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43110 llvm-svn: 324913
2018-02-13 01:37:06 +08:00
if (a < sizeof(message)/sizeof(message[0]))
return 0;
return 4;
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC] rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
2017-10-25 05:05:43 +08:00
}