erichkeane wrote: > > which brings up an additional concern/thing to deal with for the > > non_storable attribute (that is, do we apply it to assignments? how about > > exact-assignments like you've done there?). > > Conservative approach would be to issue diagnostics based on `non_storable` > only when LHS of assignment was checked taking it into account. In other > words, LHS is a bit-field with `preferred_type`, so `non_storable` enumerator > was excluded when computing how many bits are required to store the enum.
In that case, yes, we'd exclude it. It is the storing issue we have today that gets funny. So: `my_bitfield = VarOfTypeEnumThatWontFitExceptForNonStorable // Don't diagnose, as we don't consider it` `my_bitfield = EnumThatWontFitExceptForNonStorable::NonStorableItem; // Do we diagnose this?` I'd lean towards "No" in the 2nd case, the person is clear in what they are doing there. They should probably get the existing `Wbitfield-constant-conversion` still though. 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
