================ 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: > > > > 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? > > 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? > > For fast iterative check (when all flow sensitive checkers are disabled), VCS > based solution is a very good choice. > > However in our opinion, right before commit, it is not good enough to run > checks only on changes files. For example after changing a header file the > tool might find new issues in any translation unit that includes that header > file. > Another problem is with generated files. At Ericsson there are several > interface definition languages that defines the interfaces of services. C/C++ > code is generated from those IDL files during build. In case the user runs a > build before running the VCS based solution it should work well, but to be > less error prone we used another approach. Using the build system to invoke > clang-tidy (using something like bear) ensures that these generated files are > up to date. > > > 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? > > Unfortunately some of the products is still developed in very out to date > environments. We had to support those outdated OS-es, and the way we do it, > we build our packages and run the tests for those projects in a virtualized > environment. The performance penalty from this makes #1 a big concern for us > right now. Fair enough. Thanks for the explanation!
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
