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

[Oliver Hunt via cfe-commits]

ojhunt wrote:

> > and I thought making just preferred_type warnings early would be especially insane :D
> 
> I don't necessarily agree. `preferred_type` is a relatively new thing, so we can try doing something new here.
> 

Yeah, but the implementation is essentially identical, so I would literally just be implementing it for preferred type and explicitly ignoring *actual* enums :D

> > [edit: I just realized even that might need to be an option because I can imagine someone, somewhere, depending on -Werror and not hitting this by luck]
> 
> I don't believe we need to be concerned about forward compatibility for `-Werror` users. They should know they signed themselves up for pain, and we're not going to compromise our QoI because of that.

Yeah, I was also trying to think of cases where this might not trigger a warning/error currently, because there's an explicit warning path for assigning a constant and (while too lazy to godbolt right now) imagine it being possible to have

```cpp
enum class Enum {
  A, B, C, D
};

struct S {
  Enum e: 1; // I'm a rockstar developer and "know" that I'll only ever assign A or B here
}
...
  S s;
  if (x)
    s.e = Enum::A;
  else
    s.e = Enum::B;
```

and not trip an error/warning?
 
> In any case, this PR is step in the right direction, so I don't want to block its progress.

Cheers, I can file a follow on "warn on declaration" bug/PR

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