================ Comment at: clang-tidy/tool/ClangTidyMain.cpp:149 @@ -148,1 +148,3 @@ +static cl::opt<std::string> PluginPath( + "plugin-path", ---------------- 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. 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
