[clang] [Clang] Consider preferred_type in bitfield warnings (#116760) (PR #116785)

[Oliver Hunt via cfe-commits]

ojhunt wrote:

> > This does mean that if the preferred and explicit types have different storage requirements we may not warn in all possible cases, but that's a scenario for which the warnings are much more complex and confusing
> 
> If I understand the patch correctly, we always warn, but about the wrong thing.
> 
> Should we pick the minimum of both sizes? Should we make it an error for a bit-field to be _larger_ than the prefered type?

Hmmmmm, we could warn about both, though it might make the code grosser.

However I just realized that the current diagnostics do have a gap, take:

e.g
```cpp
enum class Foo : unsigned {
  twoTo10 = 1 << 9
};
enum class Bar : unsigned  {
  twoTo11 = 1 << 10
};
struct S {
  Foo f1: 10; // no warn today
  Bar f2: 11; // no warn today
  __attribute__((preferred_type(Bar)))
  Foo f3: 10;
  __attribute__((preferred_type(Bar)))
  Foo f4: 9;
};

void f(S* s, Foo f, Bar b) {
    s->f1 = f;
    s->f2 = b;
    s->f3 = f;

    // ** REAL ISSUE **
    // Because of our deferred warnings I don't think we warn on this scenario
    s->f3 = (Foo)b;
    s->f4 = f; // Warns about f being too wide
    s->f4 = (Foo)b; // Warns about f being too wide, but is oblivious to the b conversion
}

```

I wrote this code based on the actual usage - unsigned/int field wrapping an enum, but for enum vs enum, which is something that preferred type permits, then I think we don't see the `(Foo)b` conversion and truncation. I'm going to add some tests that, and then maybe accept need to refactor out the diagnostic. Ugh. 


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