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