maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/SemaCXX/ms_struct.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

45 lines
1.7 KiB
C++
Raw Normal View History

[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_WARNING -Wno-error=incompatible-ms-struct -verify -triple i686-apple-darwin9 -std=c++11 %s
// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_WARNING -Wno-error=incompatible-ms-struct -verify -triple armv7-apple-darwin9 -std=c++11 %s
Diagnose attempts to apply ms_struct to records with base classes or virtual functions, but permit that error to be downgraded to a warning (with -Wno-error=incompatible-ms-struct), and officially support this kind of dual, ABI-mixing layout. The basic problem here is that projects which use ms_struct are often not very circumspect about what types they annotate; for example, some projects enable the pragma in a prefix header and then only selectively disable it around system header inclusions. They may only care about binary compatibility with MSVC for a subset of those structs, but that doesn't mean they have no binary compatibility concerns at all for the rest; thus we are essentially forced into supporting this hybrid ABI. But it's reasonable for us to at least point out the places where we're not making any guarantees. The original diagnostic was for dynamic classes, i.e. those with virtual functions or virtual bases; I've extended it to include all classes with bases, because we are not actually making any attempt to duplicate MSVC's base subobject layout in ms_struct (and it is indeed quite different from Itanium, even for non-virtual bases). rdar://16178895 llvm-svn: 202427
2014-02-28 04:30:49 +08:00
// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_ERROR -verify -triple armv7-apple-darwin9 -std=c++11 %s
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
// RUN: %clang_cc1 -fsyntax-only -DNO_PRAGMA -mms-bitfields -verify -triple armv7-apple-darwin9 -std=c++11 %s
Rewrite record layout for ms_struct structs. The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
2013-06-27 04:50:34 +08:00
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
#ifndef NO_PRAGMA
Rewrite record layout for ms_struct structs. The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
2013-06-27 04:50:34 +08:00
#pragma ms_struct on
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
#endif
Rewrite record layout for ms_struct structs. The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
2013-06-27 04:50:34 +08:00
struct A {
unsigned long a:4;
unsigned char b;
};
struct B : public A {
Diagnose attempts to apply ms_struct to records with base classes or virtual functions, but permit that error to be downgraded to a warning (with -Wno-error=incompatible-ms-struct), and officially support this kind of dual, ABI-mixing layout. The basic problem here is that projects which use ms_struct are often not very circumspect about what types they annotate; for example, some projects enable the pragma in a prefix header and then only selectively disable it around system header inclusions. They may only care about binary compatibility with MSVC for a subset of those structs, but that doesn't mean they have no binary compatibility concerns at all for the rest; thus we are essentially forced into supporting this hybrid ABI. But it's reasonable for us to at least point out the places where we're not making any guarantees. The original diagnostic was for dynamic classes, i.e. those with virtual functions or virtual bases; I've extended it to include all classes with bases, because we are not actually making any attempt to duplicate MSVC's base subobject layout in ms_struct (and it is indeed quite different from Itanium, even for non-virtual bases). rdar://16178895 llvm-svn: 202427
2014-02-28 04:30:49 +08:00
#ifdef TEST_FOR_ERROR
Rename -Wmsvc-include to -Wmicrosoft-include, now that -Wmicrosoft is split up. (Keep -Wmsvc-include around as an alias.) While here, also replace the one other mention of "MSVC" in diagnostics with "Microsoft", for consistency. llvm-svn: 243444
2015-07-29 00:48:12 +08:00
// expected-error@-2 {{ms_struct may not produce Microsoft-compatible layouts for classes with base classes or virtual functions}}
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
#elif defined(TEST_FOR_WARNING)
Rename -Wmsvc-include to -Wmicrosoft-include, now that -Wmicrosoft is split up. (Keep -Wmsvc-include around as an alias.) While here, also replace the one other mention of "MSVC" in diagnostics with "Microsoft", for consistency. llvm-svn: 243444
2015-07-29 00:48:12 +08:00
// expected-warning@-4 {{ms_struct may not produce Microsoft-compatible layouts for classes with base classes or virtual functions}}
Diagnose attempts to apply ms_struct to records with base classes or virtual functions, but permit that error to be downgraded to a warning (with -Wno-error=incompatible-ms-struct), and officially support this kind of dual, ABI-mixing layout. The basic problem here is that projects which use ms_struct are often not very circumspect about what types they annotate; for example, some projects enable the pragma in a prefix header and then only selectively disable it around system header inclusions. They may only care about binary compatibility with MSVC for a subset of those structs, but that doesn't mean they have no binary compatibility concerns at all for the rest; thus we are essentially forced into supporting this hybrid ABI. But it's reasonable for us to at least point out the places where we're not making any guarantees. The original diagnostic was for dynamic classes, i.e. those with virtual functions or virtual bases; I've extended it to include all classes with bases, because we are not actually making any attempt to duplicate MSVC's base subobject layout in ms_struct (and it is indeed quite different from Itanium, even for non-virtual bases). rdar://16178895 llvm-svn: 202427
2014-02-28 04:30:49 +08:00
#endif
Rewrite record layout for ms_struct structs. The old implementation of ms_struct in RecordLayoutBuilder was a complete mess: it depended on complicated conditionals which didn't really reflect the underlying logic, and placed a burden on users of the resulting RecordLayout. This commit rips out almost all of the old code, and replaces it with simple checks in RecordLayoutBuilder::LayoutBitField. This commit also fixes <rdar://problem/14252115>, a bug where class inheritance would cause us to lay out bitfields incorrectly. llvm-svn: 185018
2013-06-27 04:50:34 +08:00
unsigned long c:16;
int d;
B();
};
static_assert(__builtin_offsetof(B, d) == 12,
Diagnose attempts to apply ms_struct to records with base classes or virtual functions, but permit that error to be downgraded to a warning (with -Wno-error=incompatible-ms-struct), and officially support this kind of dual, ABI-mixing layout. The basic problem here is that projects which use ms_struct are often not very circumspect about what types they annotate; for example, some projects enable the pragma in a prefix header and then only selectively disable it around system header inclusions. They may only care about binary compatibility with MSVC for a subset of those structs, but that doesn't mean they have no binary compatibility concerns at all for the rest; thus we are essentially forced into supporting this hybrid ABI. But it's reasonable for us to at least point out the places where we're not making any guarantees. The original diagnostic was for dynamic classes, i.e. those with virtual functions or virtual bases; I've extended it to include all classes with bases, because we are not actually making any attempt to duplicate MSVC's base subobject layout in ms_struct (and it is indeed quite different from Itanium, even for non-virtual bases). rdar://16178895 llvm-svn: 202427
2014-02-28 04:30:49 +08:00
"We can't allocate the bitfield into the padding under ms_struct");
// rdar://16178895
struct C {
#ifdef TEST_FOR_ERROR
Rename -Wmsvc-include to -Wmicrosoft-include, now that -Wmicrosoft is split up. (Keep -Wmsvc-include around as an alias.) While here, also replace the one other mention of "MSVC" in diagnostics with "Microsoft", for consistency. llvm-svn: 243444
2015-07-29 00:48:12 +08:00
// expected-error@-2 {{ms_struct may not produce Microsoft-compatible layouts for classes with base classes or virtual functions}}
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
#elif defined(TEST_FOR_WARNING)
Rename -Wmsvc-include to -Wmicrosoft-include, now that -Wmicrosoft is split up. (Keep -Wmsvc-include around as an alias.) While here, also replace the one other mention of "MSVC" in diagnostics with "Microsoft", for consistency. llvm-svn: 243444
2015-07-29 00:48:12 +08:00
// expected-warning@-4 {{ms_struct may not produce Microsoft-compatible layouts for classes with base classes or virtual functions}}
Diagnose attempts to apply ms_struct to records with base classes or virtual functions, but permit that error to be downgraded to a warning (with -Wno-error=incompatible-ms-struct), and officially support this kind of dual, ABI-mixing layout. The basic problem here is that projects which use ms_struct are often not very circumspect about what types they annotate; for example, some projects enable the pragma in a prefix header and then only selectively disable it around system header inclusions. They may only care about binary compatibility with MSVC for a subset of those structs, but that doesn't mean they have no binary compatibility concerns at all for the rest; thus we are essentially forced into supporting this hybrid ABI. But it's reasonable for us to at least point out the places where we're not making any guarantees. The original diagnostic was for dynamic classes, i.e. those with virtual functions or virtual bases; I've extended it to include all classes with bases, because we are not actually making any attempt to duplicate MSVC's base subobject layout in ms_struct (and it is indeed quite different from Itanium, even for non-virtual bases). rdar://16178895 llvm-svn: 202427
2014-02-28 04:30:49 +08:00
#endif
virtual void foo();
long long n;
};
static_assert(__builtin_offsetof(C, n) == 8,
"long long field in ms_struct should be 8-byte aligned");
[clang] Don't emit warn_cxx_ms_struct when MSBitfields is enabled globally This diagnostic (which defaults to an error, added in 95833f33bda6c92e746e0b0007b69c2c30bfc693) was intended to clearly point out cases where the C++ ABI won't match the Microsoft C++ ABI, for cases when this is enabled via a pragma over a region of code. The MSVC compatible struct layout feature can also be enabled via a compiler option (-mms-bitfields). If enabled that way, one essentially can't compile any C++ code unless also building with -Wno-incompatible-ms-struct (which GCC doesn't support, and projects developed with GCC aren't setting). For the MinGW target, it's expected that the C++ ABI won't match the MSVC one, if this option is used for getting the struct layout to match MSVC. Differential Revision: https://reviews.llvm.org/D81794
2020-06-14 03:29:52 +08:00
#if !defined(TEST_FOR_ERROR) && !defined(TEST_FOR_WARNING)
// expected-no-diagnostics
#endif