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

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > While I think that warning is accurate, I somewhat question the value of the 'bool' as working on this type
> 
> I'm not sure what you mean by "working" here, but I'd like to highlight that we have hundreds of single-bit bit-fields across Clang that would benefit from `[[clang::preferred_type(bool)]]`.

I wonder if we should treat one-bit bit-fields as if they were bool automatically (e.g., create this attribute implicitly in that case). How often do we expect to see one-bit bit-fields that are arithmetic? I'm sure it happens (to multiply against -1, 0, or 1 depending on the sign of the bit-field, for example), but I expect it to be quite rare compared to bool-like use.

(We could advance this patch as-is where it's explicit and add it implicitly in a follow-up.)

> > as, I'm not sure what it really means to put a non-enum here?
> 
> When it was `clang::debug_info_type`, the meaning was as simple as "I want the value of this bit-field to be interpreted as T by debuggers". Now that we moved to `preferred_type`, there might be more interpretations.
> 
> > What types ARE we allowing in this now?
> 
> As I mentioned in [#69104 (comment)](https://github.com/llvm/llvm-project/pull/69104#discussion_r1365269451), I'm not putting any restrictions on type parameter of the attribute, which makes even more sense for more generic `preferred_type`.

Hmmm, so I was thinking that the initial version of this attribute would be restricted to just integer types because we're only allowing the attribute to be applied to a bit-field and those require integer types. However, I think arbitrary types does make some sense (unless we want to get very specific). Consider: https://godbolt.org/z/esGhKoeW1

However, will this actually work in practice in the debugger? If not, perhaps we should limit to just integer and enumeration types for now, leaving the extension for the future.



https://github.com/llvm/llvm-project/pull/69104