[PATCH] D44906: [clang-tidy] Define __clang_analyzer__ macro for clang-tidy for compatibility with clang static analyzer

Alexander Kornienko via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 28 11:01:50 PDT 2018


alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG



================
Comment at: clang-tidy/ClangTidy.cpp:490
+        CommandLineArguments AdjustedArgs = Args;
+        AdjustedArgs.emplace_back("-D__clang_analyzer__");
+        return AdjustedArgs;
----------------
zinovy.nis wrote:
> alexfh wrote:
> > I wonder whether we should instead reuse the logic in the frontend (tools/clang/lib/Frontend/InitPreprocessor.cpp:970). This could be done by overriding ActionFactory::runInvocation and setting FrontendOptions::ProgramAction to frontend::RunAnalysis there. WDYT?
> Thanks. I know about this code. But I'm not sure that we can reuse RunAnalysys action hre - we need to parse AST only, but RunAnalysys does a lot of other things we dont' need. Is it correct?
Clang tooling accepts the action from the client (in this case clang-tidy) and doesn't rely on frontend code that creates an action depending on the value of FrontendOptions::ProgramAction (clang::ExecuteCompilerInvocation). Thus, setting this frontend option will only trigger the logic in Frontend/InitPreprocessor.cpp that defines the macro.

On one hand, doing so will help clang-tidy to keep distance from whatever is done in the frontend to support static analyzer. On the other side, as your answer shows, this may not be a clear way to interact with that logic.

So I'm fine with either implementation.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44906





More information about the cfe-commits mailing list