[clang] [Sema] Add check for bitfield assignments to integral types (PR #69049)

[Reid Kleckner via cfe-commits]

================
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -Wconversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -Wbitfield-conversion -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple armebv7-unknown-linux -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple arm64-unknown-linux  -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple arm-unknown-linux -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-unknown-linux -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple mipsel-unknown-linux -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple mips64el-unknown-linux -Wbitfield-conversion \
+// RUN:     -fsyntax-only -verify %s
+
+typedef struct _xx {
+     int bf:9; // expected-note 3{{declared here}}
+ } xx, *pxx; 
+
+ xx vxx;
+
+ void foo1(int x) {     
+     vxx.bf = x; // expected-warning{{conversion from 'int' (32 bits) to bit-field 'bf' (9 bits) may change value}}
----------------
rnk wrote:

This will fire on the code pattern that I have been recommending in Clang to detect bitfield truncation:
```
  int value : 6;
  void setBitfield(int v) {
    value = v;
    assert(value == v && "truncation");
  }
```

Example: https://github.com/llvm/llvm-project/blob/c35939b22eba9440dff0509b1c2608de39478f14/clang/include/clang/AST/Decl.h#L1901-L1902

This isn't appropriate for all projects because not everyone uses assertions, but what's nice about it is that you don't have to do the truncation twice: the compiler figures out the bitwidth and truncates appropriately, so the developer doesn't have to duplicate information or create an extra enum to track the bitwidth to compute a mask. The assert can't really inform the warning because they are pre-processed away in release builds, but I wonder if we could detect equality comparisons between the assigned bitfield and the RHS of the assignment to suppress the warning. On second thought, that seems infeasible.

Without a better code pattern to recommend for developers, I'm worried that most of our users are going to turn this warning off. Can anyone more creative than me come up with a better recommended code pattern to suppress the warning?

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