On Sat, Sep 17, 2022 at 10:00 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I actually noticed that clang-tidy missed this one myself, shortly
> after commit. I still haven't figured out why, but it seems like it
> might be a bug in the readability-named-parameter check. Could also
> have something to do with my clang tooling config, even though it
> works well overall.
I see what happened here: while the
"readability-inconsistent-declaration-parameter-name" check works
equally well with extern functions and functions with local linkage,
the same cannot be said for the "readability-named-parameter" check.
The latter only seems to work with functions that have local linkage.
I suppose that this limitation might have something to do with how
clang-tidy reasons about function declarations, a process that is
bound to be constrained by how extern declarations work in general. A
C compiler never compiles a .h file; it compiles translation units. In
short, it is probably a bad idea for the tool to attribute problems to
a symbol from an included .h file because that interpretation would
have to be predicated on how the file was included -- an
interpretation which might have it backwards.
In general clang-tidy is only willing to complain about function
declarations for static functions. My fixes for inconsistencies that
were reported as function definition inconsistencies usually addressed
the problem by adjusting the .h side. Strictly speaking, that approach
relies on an understanding that affected extern declarations from .h
files are canonical. This is an understanding that clang-tidy cannot
rely on.
--
Peter Geoghegan
