<div dir="ltr"><div>This all sounds good to me, as long as it is possible to continue to disable all the analyzers to produce a smaller clang binary. In Chromium, we decided it was worth doing this for a 7% size improvement: <a href="https://crrev.com/c/1437255">https://crrev.com/c/1437255</a> We ship clang-tidy, and pay the runtime cost of a second compilation for static analysis.</div><div><br></div><div>Now we are no longer in the strange situation of, "small" checks are in the analyzer, "big" checks (using ASTMatchers? except the static analyzer uses those now...) are in clang-tidy, everything is the same.</div><div><br></div><div>Reid</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 12, 2020 at 2:26 PM Artem Dergachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">After a bit of hiatus i'm reviving this work. The previous discussion is <br>
at <a href="http://lists.llvm.org/pipermail/cfe-dev/2019-August/063092.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2019-August/063092.html</a>, also <br>
<a href="http://lists.llvm.org/pipermail/cfe-dev/2019-September/063229.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2019-September/063229.html</a>. The <br>
plan is not to turn the two Clang bug-finding tools into a single tool <br>
entirely but rather to make them more interchangeable, so that users who <br>
have existing integration of, say, static analyzer, could also have <br>
clang-tidy integration for as-free-as-possible. In particular, <br>
checks/checkers could be shared, which would resolve the constant <br>
struggle of "where to put the checker?".<br>
<br>
One thing i realized since the last discussion is that the more tools we <br>
integrate, the more redundant compilation work do we perform. If we are <br>
to compile the code + run static analyzer + clang-tidy separately over <br>
it, that's 3 rebuilds of the AST from scratch. Whatever solution we <br>
provide to run both tools, I'd much rather keep it at 2 (compilation + <br>
*all* analysis) because static analysis is already expensive in terms of <br>
build-time, no need to make it worse.<br>
<br>
One core component of this plan is to teach clang-tidy how to emit <br>
reports in various human-readable and machine-readable formats that the <br>
static analyzer already supports. At this point i'm pretty much ready to <br>
publish a clang::DiagnosticConsumer that'd produce all kinds of static <br>
analyzer-style reports. In particular, such consumer would enable <br>
clang-tidy to be used from inside scan-build instead of clang --analyze; <br>
both clang-tidy checks and static analyzer checkers would be ran from <br>
inside clang-tidy binary but produce html reports consumable by <br>
scan-build; a common index.html report would be generated for all <br>
checkers. I'm very much in favor of teaching scan-build how to run <br>
arbitrary clang tools, not just clang-tidy (i.e., "scan-build <br>
--tool=/path/to/my-clang-tool" or something like that) which would allow <br>
users who don't have CMake compilation databases to take advantage of <br>
clang tools more easily (and we have a few users who are interested in <br>
that).<br>
<br>
On the other hand, we've also made up our mind that for ourselves we do <br>
in fact want produce a clang binary with clang-tidy checkers integrated. <br>
Apart from free integration into a number of our CI systems, that'll <br>
allow us to avoid shipping and supporting the clang-tidy command line <br>
interface as a separate feature. That's about 7MB increase in clang <br>
binary size which we're fine with. I plan to make it an off-by-default <br>
cmake flag unless there are strong opinions to do the opposite. The <br>
alternative approach to move ourselves into a separate binary that's <br>
integrated at the Driver level would also technically work but that's <br>
too disruptive to commit to for us at the moment - even just the Driver <br>
work alone would require a lot of testing, let alone making sure that <br>
static analyzer works exactly as before from within the tool (it already <br>
works from inside clang-tidy but we don't really know if it actually <br>
works *the same* in all the potential cornercases).<br>
<br>
So, like, we want to support multiple workflows.<br>
<br>
Also i'll be making occasional commits to some clang-tidy checks that <br>
we're interested in - mostly to address a few false positives (say, some <br>
checkers aren't aware of some Objective-C constructs), but also <br>
sometimes tweak the warning text a little bit (for example, <br>
bugprone-assert-side-effect is an awesome check but the warning text <br>
"found assert() with side effect" sounds fairly un-compiler-ish - we're <br>
not playing hide-and-seek!). Hope i'm welcome with these changes ^.^<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>