[clang] [clang] Add clang::debug_info_type attribute for bitfields (PR #69104)

[Aaron Ballman via cfe-commits]

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