[cfe-dev] More plans on Static Analyzer + Clang-Tidy interoperation.
Christian Gagneraud via cfe-dev
cfe-dev at lists.llvm.org
Tue Oct 13 20:57:33 PDT 2020
On Tue, 13 Oct 2020 at 10:26, Artem Dergachev via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> After a bit of hiatus i'm reviving this work. The previous discussion is
> at http://lists.llvm.org/pipermail/cfe-dev/2019-August/063092.html, also
> http://lists.llvm.org/pipermail/cfe-dev/2019-September/063229.html. The
> plan is not to turn the two Clang bug-finding tools into a single tool
> entirely but rather to make them more interchangeable, so that users who
> have existing integration of, say, static analyzer, could also have
> clang-tidy integration for as-free-as-possible. In particular,
> checks/checkers could be shared, which would resolve the constant
> struggle of "where to put the checker?".
Please can you keep in mind 'third-party' initiatives too?
This bug is related to clazy, i'm not speaking for the project here,
but AFAIK, having checks out of tree means that you need to maintain
your own 'front-end' (tooling front-end, not compiler's one)
I use both clang-tidy and clazy in CI, i do not use the static
analyser as AFAIU, it is run by clang-tidy already.
> One thing i realized since the last discussion is that the more tools we
> integrate, the more redundant compilation work do we perform. If we are
> to compile the code + run static analyzer + clang-tidy separately over
> it, that's 3 rebuilds of the AST from scratch. Whatever solution we
> provide to run both tools, I'd much rather keep it at 2 (compilation +
> *all* analysis) because static analysis is already expensive in terms of
> build-time, no need to make it worse.
Agree, but IMHO there is a use case to separate builds from analysis.
Eg. you're CI pipeline might want a dedicated up-front analysis stage,
which gate any later builds.
The rational being that there is no point wasting resources (build for
a bunch of arch/os), if you don't pass sanity checks.
IMHO 1 federated analysis followed by M compile is still better than
N analysis followed by M compile.
As well, sorry if it doesn't make much sense or it has been discussed
in the past, but what about storing the AST on disk, and used these as
My 2 cents.
More information about the cfe-dev