================
@@ -6519,6 +6519,13 @@ def warn_signed_bitfield_enum_conversion : Warning<
InGroup<BitFieldEnumConversion>, DefaultIgnore;
def note_change_bitfield_sign : Note<
"consider making the bit-field type %select{unsigned|signed}0">;
+def warn_ms_bitfield_mismatched_storage_packing : Warning<
+ "bit-field %0 of type %1 has a different storage size than the "
+ "preceding bit-field (%2 vs %3 bytes) and will not be packed under "
+ "the MS Windows platform ABI">,
----------------
rnk wrote:
In the codebase, we tend to use "Windows" to cover behaviors that need to be
shared with GCC and MinGW, and "Microsoft" to cover behaviors that are unique
to MSVC. This tends to boil down to C vs. C++. If it's part of the C ABI, it's
a Windows behavior, under the rationale that any C compiler for the platform
would need to match this behavior, like [enums always using a fixed type of
`int`](https://godbolt.org/z/P41YYGEah) rather than expanding to `long long` if
the members require it. C++ behaviors are high cost and "optional".
This mostly reflects the actual coding logic required, which is to check
whether the OS is Windows, or whether the "environment" is Microsoft, so
perhaps this is not the best language to communicate with users
https://github.com/llvm/llvm-project/pull/117428
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
