[cfe-dev] More plans on Static Analyzer + Clang-Tidy interoperation.

[Christian Gagneraud via cfe-dev]

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?
eg. https://bugs.llvm.org/show_bug.cgi?id=32739
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
tooling input?

My 2 cents.