Re: [lmi] clang-tidy checks (was: xanadu/remove-ISOC99_SOURCE-def)

[Vadim Zeitlin]

On Mon, 23 May 2022 16:01:37 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 5/23/22 14:31, Vadim Zeitlin wrote:
GC> > On Sun, 22 May 2022 22:58:53 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...]
GC> > GC> I'd be glad to apply a patch that uses "NOLINT" wherever
GC> > GC> it's needed, as long as it's needed only in a reasonable
GC> > GC> number of cases, of course.
GC> > 
GC> >  This depends on the checks that we want to enable. If it's just
GC> > bugprone-reserved-identifier, it's definitely not going to be a problem.
GC> > But other potentially useful checks could require adding more exceptions. 
I
GC> > don't know which checks are going to be useful, there are a lot of them
GC> 
GC> I tried looking at the list, but couldn't guess what most of them mean.

 Sorry for asking the obvious, but was this the case even after clicking on
the check name to follow the link to its detailed description? I find most
of the descriptions quite clear, or, at least, clear enough to see that the
checks are not useful to us.

 FWIW I think the most potentially interesting checks are those starting
with bugprone-, cppcoreguidelines-, performance- and readability- suffixes.
Some modernize- ones should probably be enabled too to avoid reintroducing
the constructs we had already modernized (e.g. NULL), but most of them are
not really useful, e.g. we don't want to be getting a warning for
modernize-use-trailing-return-type for each and every function.

GC> You're in a better position to decide what makes sense. Maybe we should
GC> work with the most promising handful first, and then use the experience
GC> gained thereby to decide what to do with the rest.

 I thought I'd start with everything and then disable the ones that I
didn't want to keep. It's, of course, much more ambitious, but the reason I
wanted to do it like this is that new checks are being constantly added to
the new clang-tidy versions and like this we'd know about them and could
profit from any helpful additions when they happen -- at the price of
having to disable the unhelpful ones, of course.

 Anyhow, I'll keep looking at this, but will try not to spend too much time
on it and set up something actually working because even though I think
I've already answered the initial question (whether we can use clang-tidy
to ensure that no reserved identifiers are used) positively, it's not going
to be really useful until it is checked automatically.

 In any case, I'll try not to annoy with the questions about this any more,
the possibility to add NOLINT comments is already great, thanks again,
VZ

pgpqKtPWNdEjq.pgp
Description: PGP signature