On Wed, Oct 16, 2024 at 06:31:27PM +0000, Arnd Bergmann wrote:
On Wed, Oct 16, 2024, at 18:01, Nathan Chancellor wrote:
-Wenum-enum-conversion and -Wenum-compare-conditional were strengthened in clang-19 to warn in C mode, which caused the kernel to move them to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances of each that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of these warnings.
Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of these warnings will not be real issues. The only alternatives for silencing these warnings are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code).
Disable the warnings altogether so that W=1 users do not see them.
I don't think we have to go all the way of completely disabling the warnings here, they are still potentially useful. I can see three ways of being less aggressive with them:
keep -Wno-enum-compare-conditional in W=1 and fix up the remaining warnings for that, iirc the Wno-enum-enum-conversion is the one that causes the problems.
Move them to W=2 instead of always disabled
Leave the warnings enabled for clang-18 and older.
Arnd and I talked about this offline in the ClangBuiltLinux meeting today. I am going to run my usual test matrix against a tree with -Wenum-compare-conditional turned on to see how many instances of these warnings are in the tree and how difficult it would be to silence them to address the first point above. I will move -Wenum-enum-conversion to W=2 and send that as v2 soon to satisfy point two, which should clear up the blockage for the Android folks.
While disabling the warnings for clang-19 and newer and leaving them on for clang-18 and older would technically address the issue at hand, it won't result in increased coverage because the whole point of the change that caused this in clang-19 is enabling the warning for C code, so clang-18 and older won't ever emit these warnings.
Cheers, Nathan