On Thu, Oct 10, 2024, at 10:40, Aleksei Vetrov wrote:
> On Mon, Oct 07, 2024 at 05:51:36PM -0700, Nathan Chancellor wrote:
>> For what it's worth, I never really saw Matthew's comment around what
>> value does this warning provide addressed. I was the one who originally
>> moved it into W=1 at the request of Arnd because he felt that instances
>> of this warning could be bugs and they should be audited. However, I
>> have not seen many instances of this warning pop up in new code through
>> 0day build reports and the ones that I have seen seem to be intentional,
>> as they are using enums like integral values, such as here. If that is
>> just going to result in a bunch of patches like this adding unnecessary
>> casts, I think it would just be better to consider disabling this
>> warning altogether or at the very least, moving it to W=2 (which is for
>> warnings that are noisy but might contain bugs), since more people are
>> using W=1 as their normal build configuration nowadays.
>
> If time has proven that this warning has never found an unintended enum
> conversion, then it is worth to disable it for everyone. As you said in
> the original thread ([PATCH] kbuild: Disable two Clang specific
> enumeration warnings), W=2 is not run by any CI, so I would prefer to
> disable it completely.
>
> Alternatives considered:
>
> * Enable -Wenum-enum-conversion only for 0day build reports through
> KCFLAGS. It will eliminate noise for regular users while keeping
> developers informed about new instances of this warning.
> * -Wno-error=enum-enum-conversion to keep warning but don't block
> compilation for CONFIG_WERROR users.
>
> Arnd Bergmann, what do you think? Have you found it useful after all?
I'm fairly sure I saw users mix up 'dma_data_direction' with
'dma_transfer_direction' and unrelated enum-enum mixups in
amdgpu. There were probably more.
I think what happened is that in clang-18 and earlier, the
warning option caught mistakes of passing the wrong enum
to a function and a few others, but it did not catch arithmetic
operations between enums, so clang-19 now produces a lot more
output than older versions, and I don't think we can
control those independently.
Arnd
