Endilll wrote: Taking the example above, I think it would have to look the following way to fully complement a check for bit-field width in `preferred_type`: ```cpp enum StoredNameKind : unsigned _BitInt(3) { StoredIdentifier = 0, StoredObjCZeroArgSelector = Selector::ZeroArg, StoredObjCOneArgSelector = Selector::OneArg, StoredCXXConstructorName = 3, StoredCXXDestructorName = 4, StoredCXXConversionFunctionName = 5, StoredCXXOperatorName = 6, StoredDeclarationNameExtra = Selector::MultiArg, PtrMask = 7, [[clang::non_storable]] UncommonNameKindOffset = 8 }; class DeclarationName { [[clang::preferred_type(StoredNameKind)]] unsigned Kind : 3; }; ``` Breaking it down: 1) `3` in `unsigned _BitInt(3)` is checked against enumerator values to ensure it's sufficient 2) `UncommonNameKindOffset` does not trigger diagnostic above, because it's marked as (newly-invented) `non_storable` 3) `unsigned` and `3` in `unsigned Kind : 3` are checked against `unsigned _BitInt(3)` because of `preferred_type` 4) (in other code) `Kind = UncommonNameKindOffset` will be catched, because of `non_storable`.
I think we can robustly diagnose new enumerators if the code is written this way. Implementation seem trivial to me. Today `_BitInt(3)` in underlying type of an enum has poor support across compilers we support. It doesn't block implementation of this idea, but make it a bit less trivial to implement in performant manner, and makes enum declaration a bit less declarative. 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