On 2015-10-14 9:32 PM, Gregory Szorc wrote:
On Wed, Oct 14, 2015 at 6:07 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> wrote:Last weekend, I finished upgrading our Linux and OS X debug and opt static analysis builds ("S" jobs on TreeHerder) to the latest revision of clang 3.7. Now, if you use the latest version of clang (3.7, which is available from < http://llvm.org/releases/download.html#3.7.0> in binary form), you can turn on static analysis checks locally by adding the following line to your mozconfig: ac_add_options --enable-clang-plugin Doing this helps you in detecting errors specific to the "S" jobs early during development, which simplifies the process of landing patches by letting you see the errors at the same time as other compiler errors. On Linux, most other recent versions of clang should work too, such as the one you usually get from your distro, provided that the dev package for LLVM/Clang has been installed. On OSX, the default clang that ships with recent versions of XCode lacks the dev headers and tools so it can't be used, but the llvm.org <http://llvm.org> clang binaries should work well. I have been running this plugin locally in all of my builds for several months now and once you migrate to this setup, everything should proceed hassle free. If you find issues getting your particular clang setup to work with the plugin, please let me know, and I will help fix them. I'd like to eventually get us to a point where these checks are turned on by default during local builds. As you stated, this helps detect errors earlier during development, which is a huge win. Is there a good reason configure doesn't enable the clang plugin by default?
Like I said, that is what I would like to do eventually. The problem is that right now I have no idea how many different clang setups work with the plugin, I just know that some of them (such as the Apple clang that ships with Xcode) doesn't work. Right now I am trying to get feedback from early testers to get a better idea of how well this would work out of the box. If possible, I would like to avoid turning this on opportunistically since then it would be hard for developers to say whether their build succeeded because it didn't trigger any static check errors or because their build has the clang plugin disabled...
(The situation would be a lot better if we had some kind of support for downloading the toolchain on Linux and OS X from tooltool similar to what we do on the infrastructure.)
If the plugin adds too much overhead, could we potentially factor out the expensive checks so developers aren't burdened by them by default?
The plugin doesn't add much overhead right now. The exact overhead really depends on the system in surprising ways. Here are some measurements that I have performed:
On Linux builders, enabling the plugin doesn't have any measurable impact on the speed of the build.
On my Mac laptop, I did two measurements of a full debug build without and with the plugin enabled with clang 3.7. The wall clock build times were 13m21.861s and 15m8.498s, respectively.
On my blazing fast Linux desktop machine, the same measurement yields 8m26.966s and 8m39.880s respectively.
So the plugin overhead seems to be effectively negligible on Linux. On Mac, the overhead is quite noticeable.
But back to your point, I agree that once we can turn it on by default reliably it would make sense to provide a --disable-clang-plugin option instead.
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
