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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
