[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