================
@@ -6404,20 +6404,23 @@ def warn_bitfield_width_exceeds_type_width: Warning<
def err_bitfield_too_wide : Error<
"%select{bit-field %1|anonymous bit-field}0 is too wide (%2 bits)">;
def warn_bitfield_too_small_for_enum : Warning<
- "bit-field %0 is not wide enough to store all enumerators of %1">,
+ "bit-field %0 is not wide enough to store all enumerators of
%select{|preferred type }1%2">,
InGroup<BitFieldEnumConversion>, DefaultIgnore;
def note_widen_bitfield : Note<
"widen this field to %0 bits to store all values of %1">;
def warn_unsigned_bitfield_assigned_signed_enum : Warning<
- "assigning value of signed enum type %1 to unsigned bit-field %0; "
+ "assigning value of %select{|preferred }1signed enum type %2 to unsigned
bit-field %0; "
"negative enumerators of enum %1 will be converted to positive values">,
InGroup<BitFieldEnumConversion>, DefaultIgnore;
def warn_signed_bitfield_enum_conversion : Warning<
"signed bit-field %0 needs an extra bit to represent the largest positive "
- "enumerators of %1">,
+ "enumerators of %select{|preferred type }1%2">,
InGroup<BitFieldEnumConversion>, DefaultIgnore;
----------------
AaronBallman wrote:
The downside to this approach is that I think we want the `preferred_type`
diagnostics to be on by default rather than off by default. e.g., if the user
specified `preferred_type`, they're telling the compiler "this bit-field should
only be used to store things of that type" and so details like "not all the
enumerators fit" is actually crucial to tell the developer about.
Based on that, I kind of wonder whether we want separate diagnostics under the
same diagnostic group, but without the `DefaultIgnore`. WDYT?
https://github.com/llvm/llvm-project/pull/116785
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
