[PATCH] Refactored Clang-tidy for better reusability.

Alexander Kornienko alexfh at google.com
Thu Jan 2 07:53:23 PST 2014

Comment at: clang-tidy/ClangTidy.h:107-109
@@ +106,5 @@
+/// FIXME: Ideally we'd want to build a more generic way to use
+/// \c FrontendAction based checkers in clang-tidy, but that needs some
+/// preparation work first.
+class ClangTidyAction : public ASTFrontendAction {
Manuel Klimek wrote:
> Why?
I'm not sure what exactly did you mean when writing this, and I was thinking already about asking you, if this comment is still applicable.

Comment at: clang-tidy/ClangTidy.cpp:156-163
@@ +155,10 @@
+    if (AnalyzerChecksEnabled) {
+      // Run our regex against all possible static analyzer checkers.
+      // Note that debug checkers print values / run programs to visualize the
+      // CFG
+      // and are thus not applicable to clang-tidy in general.
+      // Always add all core checkers if any other static analyzer checks are
+      // enabled. This is currently necessary, as other path sensitive checks
+      // rely
+      // on the core checkers.
+      for (unsigned i = 0; i < Checkers.size(); ++i) {
Manuel Klimek wrote:
> :gq

Comment at: clang-tidy/ClangTidy.h:110
@@ +109,3 @@
+/// preparation work first.
+class ClangTidyAction : public ASTFrontendAction {
Manuel Klimek wrote:
> Description says this was moved to make it easier to create the AST consumer, but it doesn't seem to be used outside of the .cpp. What am I missing?
(Moving the comment here from an e-mail.)
It is supposed to make writing different frontends easier. I've got a patch for an out-of-tree project, that makes use of this.

The use case is, when we need clang-tidy's ASTConsumer, and we want to reuse all module registration/filtering logic and all the harness for the static analyzer integration. We cannot simply create a function to return an ASTConsumer, as there's a state in the ClangTidyAction and ClangTidyActionFactory.


More information about the cfe-commits mailing list