Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20211014132331.GA4811@kernel.org> <YWhGQLHnA9BIVBpr@hirez.programming.kicks-ass.net>
 <CAKwvOdnkDUfRKzmLThQGW02Ew6x=KM0MQyHge7=kc673NYxo2g@mail.gmail.com>
 <CANiq72nt+8bCGAm8yhvTZfS64ovOi9_U=Gym7biUhdEsc3Neaw@mail.gmail.com>
 <CANiq72=UVCmjr1tpSwcoOkid5tWZirKCnV17_Peqy-LBmEQHEg@mail.gmail.com> <CAKwvOdkSFhzSwo2hfFjXXHypC8eU+VBCnRVjvNima7qx85z65Q@mail.gmail.com>
In-Reply-To: <CAKwvOdkSFhzSwo2hfFjXXHypC8eU+VBCnRVjvNima7qx85z65Q@mail.gmail.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Thu, 14 Oct 2021 21:33:19 +0200
Message-ID: <CANiq72=vZ0gvJRuVcNaBi3CQfgB4edEUyLpL8DvZeLkDSvttOg@mail.gmail.com>
Subject: Re: [PATCH] compiler_types: mark __compiletime_assert failure as __noreturn
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Miguel Ojeda <ojeda@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        llvm@lists.linux.dev, Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Joe Perches <joe@perches.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Oct 14, 2021 at 8:55 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> $ grep -r BUILD_BUG_ON | wc -l
> 3405

Definitely -- I am assuming a significant part of the macro
invocations cannot be static asserts so that we would ended up with
churn anyway...

> Oh, that is a good idea.  There is one already for recommending the
> use of static_assert instead of assert.  That's actually very nice.

Happy to help!

> in the kernel, I wouldn't waste time with one off patches; rather I'd
> work on automation (since clang-tidy can be taught "fixits" to fix the
> code in place, not just warn) so that we can better enable treewide
> changes AND keep new instances from sneaking back in easier.

For automatic fixing we would need to be a bit smart due to the
negation w.r.t. "style", i.e. in most cases it should be easy to apply
it to the expression, e.g. from `!(x == 42)` to `x != 42`, but in
others it may require some "human touch".

There is also the possible mismatch of the usual style rules even if
we apply e.g. `clang-format` after it (one more reason to avoid human
formatting...).

But yeah, I think we should be able to cover the vast majority of them
easily. We can always send them as RFC patches and let folks adapt the
patch, then enable the warning/error by default after one release or
two.

> Let's see if I get an intern in 2022, maybe I can have them focus on
> clang-tidy+kernel.

It would be great to have someone adding more `linuxkernel-` checks!

Cheers,
Miguel