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/ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
