erichkeane wrote:
> I'm ignoring signed/unsigned mismatch as @erichkeane and @AaronBallman
> suggested. The only outstanding aspect is the following diagnostic I added
> today and haven't received feedback on:
>
> ```c++
> [[clang::preferred_type(bool)]] unsigned b4 : 1;
> [[clang::preferred_type(bool)]] unsigned b5 : 2;
> // expected-warning@-1 {{bit-field that holds a boolean value should have
> width of 1 instead of 2}}
> ```
Yeah, I haven't had a good chance to do a huge deep dive on this today, and
probably won't until later this week. While I think that warning is accurate,
I somewhat question the value of the 'bool' as working on this type (as, I'm
not sure what it really means to put a non-enum here? What types ARE we
allowing in this now?).
I think the wording of the diagnostic is perhaps awkward, so we should bikeshed
that as well, though I'm on the fence about the diagnostic existing at all. On
one hand, this would be such a special case, as typically 'too large' for the
type isn't an issue for any reason. On the other, the 'bool' case is perhaps
uniquely an issue.
What about if the person prefers the type be 'char', but has it be a size of 9?
THIS is a case where it is reasonable (consider cases where you need to store
the result of one of those calls to the C library that returns 'an int that is
either a char or -1').
So I guess I'm really questioning how accurate/error-free we could make that
diagnostic. I'm leaning towards "too big of a bitfield should be ok".
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
