ae866f8780dfd9943814444fad603b41dec9c7cb: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 19:14:18 -0800 - rev 339376
Push 12713 by gszorc@mozilla.com at Fri, 11 Mar 2016 03:22:28 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
9e5f9917fe1a7bef9585966959d516636d7ee6ac: HACK Allow compiler warnings in gfx/vr draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 10:42:32 -0800 - rev 339375
Push 12713 by gszorc@mozilla.com at Fri, 11 Mar 2016 03:22:28 +0000
HACK Allow compiler warnings in gfx/vr MozReview-Commit-ID: 14cZCGPkx0V
331573efe549d925234a03d8ab077864b12ea3a3: Bug 1254963 - Fix build error C2664 on MSVC 2015. r=aklotz draft
Masatoshi Kimura <VYV03354@nifty.ne.jp> - Fri, 11 Mar 2016 07:25:33 +0900 - rev 339374
Push 12713 by gszorc@mozilla.com at Fri, 11 Mar 2016 03:22:28 +0000
Bug 1254963 - Fix build error C2664 on MSVC 2015. r=aklotz MozReview-Commit-ID: 4jD5JsC4F5l
c0910ebe98fe3f5eb5ef02faddb3a7c7c72aad0e: Bug 1252995 - Add method anmes and uncovered lines to per-test coverage. draft
Greg Mierzwinski <gmierz2@outlook.com> - Tue, 08 Mar 2016 20:43:52 -0500 - rev 339373
Push 12712 by bmo:gmierz2@outlook.com at Fri, 11 Mar 2016 02:49:41 +0000
Bug 1252995 - Add method anmes and uncovered lines to per-test coverage. MozReview-Commit-ID: 62tSQZwwLPW * * * Bug 1252995 - recordTestCoverage revision. This is a modification to recordTestCoverage. It now get methods and all lines they cover, has a version control block, and gets uncovered lines also.
f7228ca9819d86f8ab3e6371d75c278c876006d9: Bug 1252995 - Add method names and uncovered lines to per-test coverage output. draft
Gregory Mierzwinski <gmierz1@live.ca> - Wed, 02 Mar 2016 18:51:53 -0500 - rev 339372
Push 12712 by bmo:gmierz2@outlook.com at Fri, 11 Mar 2016 02:49:41 +0000
Bug 1252995 - Add method names and uncovered lines to per-test coverage output. This function is used to get the method names contained in the scripts. It returns an array containing keys in the form "lineNumber#methodName" that has each line number associated to a method. If the method is found to have an undefined name, we give it a name "undefined_integer" and every time we find a new undefined method, we increment the integer. There is the possibility that multiple functions can be caught on the same line. If a method has not been covered at all, we use lineNumber == '-1' to designate that it will not have any lines covered. This is needed to be able to have an empty covered array for the uncovered method. MozReview-Commit-ID: HnB7Zowy1OU * * * Bug 1252995 - Method names revision. This is the revision for getMethodNames. It now uses getAllOffsets to get the lines each method covers.
c34d362a121929ee8a7a7943a20e0a70b80a9ec3: Bug 1255659 part 2 - Add 'fullscreen' tag to tests which ever put window into fullscreen. draft
Xidorn Quan <quanxunzhen@gmail.com> - Fri, 11 Mar 2016 10:45:00 +0800 - rev 339371
Push 12711 by xquan@mozilla.com at Fri, 11 Mar 2016 02:45:15 +0000
Bug 1255659 part 2 - Add 'fullscreen' tag to tests which ever put window into fullscreen. MozReview-Commit-ID: EBynEGbpYQU
6ee075878e17c469081259cda8b57e0bc4c22264: Bug 1255659 part 1 - Remove test_contextmenu.html which is no longer used. draft
Xidorn Quan <quanxunzhen@gmail.com> - Fri, 11 Mar 2016 10:43:20 +0800 - rev 339370
Push 12711 by xquan@mozilla.com at Fri, 11 Mar 2016 02:45:15 +0000
Bug 1255659 part 1 - Remove test_contextmenu.html which is no longer used. MozReview-Commit-ID: IHK9x9FhfOS
9e5b83752e5b70ef4fd637f78eac5aa204011377: Bug 1255667 - Don't read the mozconfig for the js configure draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 11 Mar 2016 11:30:54 +0900 - rev 339369
Push 12710 by bmo:mh+mozilla@glandium.org at Fri, 11 Mar 2016 02:36:50 +0000
Bug 1255667 - Don't read the mozconfig for the js configure While the long term goal is that js and top-level use the same configure and the same overall setup, including the possibility to use mozconfigs, figuring out what we want to do wrt mozconfig vs. command line and environment variable is not a clear-cut case, and it's more important to fix the immediate problem mozconfig causes to js developers by "temporarily" returning to the previous behavior of not loading the mozconfig for the js configure. This was already done in the case of running it as a subconfigure, this extends the exception. Unfortunately, there is no direct way to tell whether the running configure is the js configure. The indirect way is to look at the OLD_CONFIGURE path, which points to js/src/old-configure. I expect we'll have figured things out for mozconfigs well before old-configure dies.
bbfa5b7750d7f73554674161498517776a1e700a: Bug 1255540 - Properly run the clang-plugin tests draft
Mike Hommey <mh+mozilla@glandium.org> - Fri, 11 Mar 2016 11:01:55 +0900 - rev 339368
Push 12709 by bmo:mh+mozilla@glandium.org at Fri, 11 Mar 2016 02:02:45 +0000
Bug 1255540 - Properly run the clang-plugin tests
2b5ac0c8f1dc7fee1b497780d583bdff461e9fa0: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 17:54:48 -0800 - rev 339367
Push 12708 by gszorc@mozilla.com at Fri, 11 Mar 2016 01:55:27 +0000
Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan This commit switches Windows builds from Visual Studio 2013 to Visual Studio 2015 Update 1. Previously, Visual Studio was installed on the builers as part of the base system image. Starting with this commit, we obtain Visual Studio from a pre-generated, self-contained archive containing the executables, Windows SDK, and other support files. This means that new Windows toolchains can be installed without having to modify configuration of machines in automation! The mozconfigs for Visual Studio 2015 are a bit different from existing mozconfigs. Because it appears to be completely redundant and not necessary, the LIBPATH variable has been dropped. The order of paths in PATH, LIB, and INCLUDE has changed. The new order more accurately reflects what would be defined by vcvarsall.bat. As part of switching to Visual Studio 2015, the Universal CRT is now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR to define the location to those files. The switch to Visual Studio 2015 also involves the switch from the Windows 8.1 SDK to the Windows 10 SDK. However, we still target an old version of Windows, so this hopefully shouldn't have any significant fallout. It's worth noting that switching to Visual Studio 2015 makes builds - especially PGO builds - significantly faster. Our PGO build times in automation are ~1 hour faster. Our regular builds appear to be a few minutes faster. MozReview-Commit-ID: Pa5GW8V87Q
04b14a2b51eff20259ff93a2e524d81f5f1b0d27: Bug 1249288 - review: Correct concurrency issues with searchEngineManager. r=rnewman draft
Michael Comella <michael.l.comella@gmail.com> - Thu, 10 Mar 2016 17:37:56 -0800 - rev 339366
Push 12707 by michael.l.comella@gmail.com at Fri, 11 Mar 2016 01:38:06 +0000
Bug 1249288 - review: Correct concurrency issues with searchEngineManager. r=rnewman MozReview-Commit-ID: KaWlw14uOoN
cc56a0537e219f0b63df5a35cfc8baac6f16add8: Bug 1249288 - Update telemetry docs to include defaultSearch. r=gfritzsche,rnewman draft
Michael Comella <michael.l.comella@gmail.com> - Thu, 10 Mar 2016 16:23:13 -0800 - rev 339365
Push 12707 by michael.l.comella@gmail.com at Fri, 11 Mar 2016 01:38:06 +0000
Bug 1249288 - Update telemetry docs to include defaultSearch. r=gfritzsche,rnewman MozReview-Commit-ID: 4pihITjabns
5bbf5fd6d0e96197d78b67641a99489582c90de4: Bug 1249288 - Don't call SearchEngineManager change callback if it's null. r=margaret draft
Michael Comella <michael.l.comella@gmail.com> - Tue, 23 Feb 2016 18:11:57 -0800 - rev 339364
Push 12707 by michael.l.comella@gmail.com at Fri, 11 Mar 2016 01:38:06 +0000
Bug 1249288 - Don't call SearchEngineManager change callback if it's null. r=margaret The callback may be null if setChangeCallback is never called and would cause a crash. MozReview-Commit-ID: BNd16Db1A8Q
aa945142f79ff22b83ea2933f26dc0fe5401a1d0: Bug 1249288 - Add default search engine to core ping. r=rnewman draft
Michael Comella <michael.l.comella@gmail.com> - Thu, 10 Mar 2016 16:00:15 -0800 - rev 339363
Push 12707 by michael.l.comella@gmail.com at Fri, 11 Mar 2016 01:38:06 +0000
Bug 1249288 - Add default search engine to core ping. r=rnewman The default search engine attribute may be null in the core ping if we haven't been able to retrieve the value yet. It's unclear when this might be, but the possibility is in the javadoc of `SearchEngineManager.getEngine`. MozReview-Commit-ID: IrJB6GyjyTO
d88304ed15aa0d5a0c1a9d41459ebcf9436913b2: Bug 1249288 - Move om.search.providers.SearchEngine\* to omg.search. r=nalexander draft
Michael Comella <michael.l.comella@gmail.com> - Tue, 23 Feb 2016 17:27:24 -0800 - rev 339362
Push 12707 by michael.l.comella@gmail.com at Fri, 11 Mar 2016 01:38:06 +0000
Bug 1249288 - Move om.search.providers.SearchEngine\* to omg.search. r=nalexander We want to reuse this code for the main Activity. MozReview-Commit-ID: BZxIrgmJI2r
669af37d3ce1d56480f7f6c5e6aa7d6382811d58: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 16:08:33 -0800 - rev 339361
Push 12706 by gszorc@mozilla.com at Fri, 11 Mar 2016 01:30:39 +0000
Bug 1253707 - Script to generate visual studio toolchain archive; r?ted Previously, Windows toolchains and related dependencies (SDKs, etc) were installed on Windows builders by people responsible for maintaining those machines. This commit takes a step in a new direction. We introduce a script (complete with documentation) that can produce a zip archive (or any archive format if people want to implement support) of the toolchain files. Basically, you install Visual Studio 2015 Community, run the script, and produce a self-contained zip file containing everything from Microsoft you need to build Firefox. With a copy of this archive and an installation of MozillaBuild, it is possible to build Firefox on a fresh Windows installation. No time-consuming Visual Studio installation needed. The goal is to upload these archives to tooltool and have our Windows builders download and extract them at run-time. At which time, we can remove all the other Visual Studio and SDK files from builders because they don't need to be baked into the image. We may find tooltool's caching isn't good enough and we have to more aggressively caching the standalone toolchain files. But that is a problem for another day. Whatever happens, we'll need the functionality in this script to produce a self-contained archive of the toolchain. There are certainly files in the produced archive that aren't needed. I think perfect is the enemy of done and we can prune the archive over time, if wanted. MozReview-Commit-ID: EckEK1a6vA3
c27444067cf26d8c31b1ae95703cd12df91c69be: HACK Allow compiler warnings in gfx/vr draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 10:42:32 -0800 - rev 339360
Push 12706 by gszorc@mozilla.com at Fri, 11 Mar 2016 01:30:39 +0000
HACK Allow compiler warnings in gfx/vr MozReview-Commit-ID: 14cZCGPkx0V
efd1a7fe8a9e149155d50e95b4afde9ea2f9e550: Bug 1252995 - Add method names and uncovered lines to per-test coverage output. draft
Gregory Mierzwinski <gmierz1@live.ca> - Wed, 02 Mar 2016 18:51:53 -0500 - rev 339359
Push 12705 by bmo:gmierz2@outlook.com at Fri, 11 Mar 2016 01:28:35 +0000
Bug 1252995 - Add method names and uncovered lines to per-test coverage output. This function is used to get the method names contained in the scripts. It returns an array containing keys in the form "lineNumber#methodName" that has each line number associated to a method. If the method is found to have an undefined name, we give it a name "undefined_integer" and every time we find a new undefined method, we increment the integer. There is the possibility that multiple functions can be caught on the same line. If a method has not been covered at all, we use lineNumber == '-1' to designate that it will not have any lines covered. This is needed to be able to have an empty covered array for the uncovered method. MozReview-Commit-ID: HnB7Zowy1OU * * * Bug 1252995 - Method names revision. This revision is for getMethodNames. It now uses getAllOffsets to get all the lines that are contained within a method.
364d4dda412363dbbd41460870ac7a8460a11de5: Bug 1175546 - Update GCC to 4.8.5 and bump minimum GCC version required to build draft
Mike Hommey <mh+mozilla@glandium.org> - Tue, 08 Mar 2016 16:21:49 +0900 - rev 339358
Push 12704 by bmo:mh+mozilla@glandium.org at Fri, 11 Mar 2016 01:24:42 +0000
Bug 1175546 - Update GCC to 4.8.5 and bump minimum GCC version required to build
95fbfa8bfabde32542ff0228bcd95e1f36d1fd41: Bug 1245076 - Don't include mozalloc.h from the cstdlib wrapper draft
Mike Hommey <mh+mozilla@glandium.org> - Thu, 10 Mar 2016 16:54:05 +0900 - rev 339357
Push 12703 by bmo:mh+mozilla@glandium.org at Fri, 11 Mar 2016 01:22:08 +0000
Bug 1245076 - Don't include mozalloc.h from the cstdlib wrapper Our STL wrappers do various different things, one of which is including mozalloc.h for infallible operator new. mozalloc.h includes stdlib.h, which, in libstdc++ >= 6 is now itself a wrapper around cstdlib, which circles back to our STL wrapper. But of the things our STL wrappers do, including mozalloc.h is not one that is necessary for cstdlib. So skip including mozalloc.h in our cstdlib wrapper. Additionally, some C++ sources (in media/mtransport) are including headers in an extern "C" block, which end up including stdlib.h, which ends up including cstdlib because really, this is all C++, and our wrapper pre-includes <new> for mozalloc.h, which fails because templates don't work inside extern "C". So, don't pre-include <new> when we're not including mozalloc.h.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip