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

39 lines
1.4 KiB
C++
Raw Normal View History

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 -Wno-error=incompatible-ms-struct -verify -triple i686-apple-darwin9 -std=c++11 %s
// RUN: %clang_cc1 -fsyntax-only -Wno-error=incompatible-ms-struct -verify -triple armv7-apple-darwin9 -std=c++11 %s
// RUN: %clang_cc1 -fsyntax-only -DTEST_FOR_ERROR -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
#pragma ms_struct on
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}}
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
#else
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}}
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
#else
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");