AaronBallman wrote: > > > Wouldn't it be better to go the other way around? i.e. have a > > > `[[clang::compressed_bitfield]]` (or whatever) which influences the ABI, > > > so it's possible to do stuff like > > > ``` > > > [[clang::compressed_bitfield]] bool IsSomething : 1; > > > [[clang::compressed_bitfield]] MyEnum Whatever : 3; > > > [[clang::compressed_bitfield]] int MoreStuff : 4; > > > ``` > > > > > > > > > which the current approach doesn't allow. > > > > > > The issue is that MSVC wouldn't know/recognize/implement this attribute - > > so clang couldn't do that without breaking ABI compatibility with MSVC. > > That's not important for everybody, and you could still `#if` around that > code like > > ```c++ > #if __has_cpp_attribute(clang::compressed_bitfield) > #define BITFILED_T(ActualType, ABIType) > static_assert(check_abi_compat<ActualType, ABIType>()); > [[clang::compressed_bitfield]] ActualType > #else > #define BITFIELD_T(ActualType, ABIType) ABIType > ... > ``` > > Sure, it's not super pretty, but it gets you there and allows you to do more > stuff. We could also ask the MSVC folks whether there would be interest to > add such an attribute, since there is clearly interest in having a good ABI > and stronger typing (CC @StephanTLavavej @CaseyCarter).
I think that's a somewhat orthogonal feature to the one @Endilll is proposing. While it might make sense to ask the MSVC and GCC folks if they'd be willing to entertain a similar attribute, the implementation landscape is much wider in C and those implementations may have similar ABI issues. If an implementation ignores the `compressed_bitfield` attribute, you get potential ABI issues; if an implementation ignores the `debug_info_type` attribute, you get the default debugging experience but no change to codegen behavior. So I think there may be room for both features. We have a `preferred_name` attribute already for specifying "please display this name instead of that name" in diagnostics; this seems somewhat similar in nature in that it's "please display this type instead of that bit-field type" in the debugger, so mayyybe we want to name this `preferred_type` instead? If this could also be useful for diagnostics which mention types and can be triggered with a bit-field, that might also be a reason to use a different name (I'm not certain we have many/any such diagnostics today though.) I'm not opposed to the current name, but more thinking that it might be too specific and we may want a path to more generalization in the future. https://github.com/llvm/llvm-project/pull/69104 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
