Page MenuHomePhabricator

[Analyzer] getRegisteredCheckers(): handle debug checkers too.
AbandonedPublic

Authored by lebedev.ri on Apr 27 2018, 6:47 AM.

Details

Summary

I would like to be able to trigger these debug checkers from clang-tidy, as a follow-up patch for D46159

Diff Detail

Repository
rC Clang

Event Timeline

lebedev.ri created this revision.Apr 27 2018, 6:47 AM
alexfh added a comment.May 3 2018, 9:52 AM

What's the use case for debug CSA checkers in clang-tidy?

alexfh requested changes to this revision.May 3 2018, 9:53 AM
This revision now requires changes to proceed.May 3 2018, 9:53 AM
NoQ added a comment.May 4 2018, 4:28 PM

It seems that you're using debug checkers of the analyzer to gain some free tools for exploring the source code (such as displaying a call graph) for free, right?

I believe we could also benefit from a method of extracting the analyzer's clang -cc1 run-line from clang-tidy. This would allow arbitrary debugging over a single analyzer invocation.

In D46187#1088722, @NoQ wrote:

It seems that you're using debug checkers of the analyzer to gain some free tools for exploring the source code (such as displaying a call graph) for free, right?

Yes.
I was interested to dump the callgraph of DAGCombiner.cpp, and try to analyze if there is any sane way to split it up.
I think it would require a bit of changes to that callgraph dumper (writing LOC count for the functions that actually exist-as-written (or something) in the source code, grouping the functions in the main TU into a one group), but i did not get to that.

I believe we could also benefit from a method of extracting the analyzer's clang -cc1 run-line from clang-tidy. This would allow arbitrary debugging over a single analyzer invocation.

I'm not really following, sorry.

alexfh added a comment.May 8 2018, 6:58 AM
In D46187#1088722, @NoQ wrote:

It seems that you're using debug checkers of the analyzer to gain some free tools for exploring the source code (such as displaying a call graph) for free, right?

I believe we could also benefit from a method of extracting the analyzer's clang -cc1 run-line from clang-tidy.

It should be possible now using clang-tidy -extra-arg=-v some/file.cpp (or clang-check -extra-arg=-v ...).

NoQ added a comment.May 14 2018, 2:58 PM

I believe we could also benefit from a method of extracting the analyzer's clang -cc1 run-line from clang-tidy. This would allow arbitrary debugging over a single analyzer invocation.

I'm not really following, sorry.

In D46187#1088722, @NoQ wrote:

I believe we could also benefit from a method of extracting the analyzer's clang -cc1 run-line from clang-tidy.

It should be possible now using clang-tidy -extra-arg=-v some/file.cpp (or clang-check -extra-arg=-v ...).

Nice!

So essentially @lebedev.ri could do clang-check -analyze -extra-arg=-v ../llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp, then copy the printed clang Invocation: and append -analyzer-checker debug.ViewCallGraph to it.

Or maybe even something as horrible as

clang-check -analyze -extra-arg=-Xclang -extra-arg=-analyzer-checker -extra-arg=-Xclang -extra-arg=debug.ViewCallGraph ../llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

And it sounds like the roughly right level of verbosity for discriminating between a user-facing feature and a definitely-not-user-facing feature.

I don't mind having a separate flag specifically for enabling debug checkers, but when it comes to actual debugging of the analyzer, debug checkers are usually not sufficient. Playing with other flags and -analyzer-config options is very often necessary, so if i was to debug the analyzer from clang-tidy, most of the time i'd have preferred to do the -v trick.

lebedev.ri abandoned this revision.May 23 2018, 10:54 AM

Sad, but ok.