[PATCH] [clang-tidy] Support for Static Analyzer plugins

[Alexander Kornienko]

After thinking a bit more, I prefer to leave -plugin-path command-line option at least for now, because it doesn't make sense for other clang-tidy frontends.


================
Comment at: clang-tidy/tool/ClangTidyMain.cpp:149
@@ -148,1 +148,3 @@
 
+static cl::opt<std::string> PluginPath(
+    "plugin-path",
----------------
xazax.hun wrote:
> alexfh wrote:
> > xazax.hun wrote:
> > > alexfh wrote:
> > > > Does static analyzer support only one plugin at a time?
> > > > 
> > > > Also, it _may_ be better to put this into ClangTidyOptions, but I'm not sure yet. Upsides are that then we'd avoid modification of most other interfaces. Obvious downsides are that this option only makes sense for the command-line front-end.
> > > > 
> > > > Can you explain your use case in more detail?
> > > I never tried to use multiple plugins, however you are right, the static analyzer supports to load multiple ones at the same time. I see your point to put this into ClangTidyOptions, so one can configure it using yaml files.
> > > 
> > > My usecase is the following:
> > > We have a script, that uses LD_PRELOAD to load a shared object that hijacks the exec function call family and filters and logs compiler calls. After this log file is created a script invokes clang tidy with slightly modified compilation arguments. This way we can support any build system on posix systems including incremental build support.We just got the permission to open source this tool set, so it is possible that we will try to upstream this tool soon. 
> > I'm still not sure about moving the "-plugin-path" option to `ClangTidyOptions`.
> > 
> > > My usecase is the following:
> > > We have a script, that uses LD_PRELOAD to load a shared object that 
> > > hijacks the exec function call family and filters and logs compiler calls. 
> > 
> > Similar to this one? https://github.com/rizsotto/Bear
> > 
> > > After this log file is created a script invokes clang tidy with slightly 
> > > modified compilation arguments. This way we can support any build 
> > > system on posix systems including incremental build support.
> > 
> > You mean you run analyses on each build? Sounds interesting, though there's a (possibly more effective) alternative: to run analyses as a part of submitting the code for review.
> > 
> > But anyway, that doesn't answer why do you need plugins and how you use them.
> Oh, our solution is very similar to Bear indeed thanks for pointing this out.
> We do not run the analysis on each build. We have a script, that can run the analysis as the part of a build, and the user can decide when to run it ( or it can be automated by commit hooks etc).  So one can only recheck the translation units that he modified.
> 
> About the plugins, we use them for two reasons:
> 1. It is faster to link a plugin shared object than linking clang, so we can iterate faster with changes.
> 2. We find it cleaner that most of the code we write is out of the clang source tree. This way we don't end up using an internal clang fork, and our repository is smaller. 
> ... So one can only recheck the translation units that he modified.

Unrelated to this patch: did you think about using clang-tidy-diff.py or a similar VCS-based approach to define what "modified files" are?

> About the plugins, we use them for two reasons:
> 1. It is faster to link a plugin shared object than linking clang, so we can 
> iterate faster with changes.
> 2. We find it cleaner that most of the code we write is out of the clang 
> source tree. This way we don't end up using an internal clang fork, and 
> our repository is smaller.

Thanks for explanation. Hopefully, clang-tidy with its compile-time extensibility improves #2 by allowing to keep checks in a separate tree more conveniently. Is #1 a big concern for you?

http://reviews.llvm.org/D9555

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/