838579df9665d5317d7314c20d1092270a690fa0: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340331
Push 12944 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:30:07 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
edbebcb1712c2a7f6b1d51c8f0f5112e10c23e1e: Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 22:20:38 -0700 - rev 340330
Push 12944 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:30:07 +0000
Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. That being said, the underlying problem in the warning this fixes appears to be in a header from 3rd party WebRTC code, so our hands might be tied. MozReview-Commit-ID: E8JqPkYqxls
b493f86e49b99fafae8cb227f1f0becd4014e086: Bug 1250829 - add customized assertions for completion promises to facilitate promise chaining. r=bholley draft
JW Wang <jwwang@mozilla.com> - Tue, 15 Mar 2016 13:12:21 +0800 - rev 340329
Push 12943 by jwwang@mozilla.com at Tue, 15 Mar 2016 05:21:42 +0000
Bug 1250829 - add customized assertions for completion promises to facilitate promise chaining. r=bholley MozReview-Commit-ID: L1TMiqQYexw
c35823109b5a4f9bcee2d7527c56f7b1638b543b: Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 22:20:38 -0700 - rev 340328
Push 12942 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:20:47 +0000
Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. That being said, the underlying problem in the warning this fixes appears to be in a header from 3rd party WebRTC code, so our hands might be tied. MozReview-Commit-ID: E8JqPkYqxls
9581afeabec49736fa1aed5556466404f0782a9d: Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 22:18:24 -0700 - rev 340327
Push 12941 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:35 +0000
Bug 1256548 - Disable C4312 to unblock compilation on VS2015; r?billm As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. That being said, the underlying problem in the warning this fixes appears to be in a header from 3rd party WebRTC code, so our hands might be tied. MozReview-Commit-ID: E8JqPkYqxls
9836b2e7ac24b27acd879f4def4cf42c570854b1: Bug 1256548 - Disable C4311 to unblock compilation on VS2015; r?billm draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 22:17:51 -0700 - rev 340326
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
Bug 1256548 - Disable C4311 to unblock compilation on VS2015; r?billm As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. That being said, the underlying problem in the warning this fixes appears to be in a header from 3rd party WebRTC code, so our hands might be tied. MozReview-Commit-ID: E8JqPkYqxls
bf26a81deb712f589ef7c63d3619eff1777d4fbc: enable PGO draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 14:48:22 -0800 - rev 340325
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
enable PGO MozReview-Commit-ID: EdiNUx21iPr
349c095dbea2663b990bbd9de68ae3e6517f0313: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 18:50:10 -0700 - rev 340324
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +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
3a2d468e0e440a8d166785cfb49f00ad47f7635e: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340323
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +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
c117a7f9a4ca1fc1d6e2882dbba2527383a6aecd: Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 14:38:12 -0700 - rev 340322
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
Bug 1124033 - Replace blanket disabling of VS2015 warnings with C5026 and C5027; r?ehsan Wv:18 was added in bug 1119072 as a quick way to get the tree building with VS2015. Now that we're closer to rolling out VS2015 support, we want to expose its new warnings. This patch replaces the blanket disabling of new warnings in VS2015 with just disabling C5026 and C5027, which relate to symbols being implicitly defined as deleted. MozReview-Commit-ID: 8uniydfNJns
81f31230bbc3470dcfa502b91ef9cbfe6020f71b: Bug 1256535 - Disable C4577 to unblock compilation on VS2015; r?poiru draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:44:22 -0700 - rev 340321
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
Bug 1256535 - Disable C4577 to unblock compilation on VS2015; r?poiru The previous disabling of this warning on just Key.cpp was not sufficient because another file from the unified sources list appears to include the header exhibiting the warning. MozReview-Commit-ID: rR2XXigTJU
19f22d7da6c1a8ec963fddc30632969e7e7ff55c: Bug 1256545 - Disable C4311 to unblock compilation on VS2015; r?jesup draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:41:24 -0700 - rev 340320
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
Bug 1256545 - Disable C4311 to unblock compilation on VS2015; r?jesup As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: LOiUCH7qfyW
0e8d1b30f3ef2c3b3df56cba1a72fa5352750e19: Bug 1256530 - Disable C4312 to unblock compilation on VS2015; r?smaug draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:09:32 -0700 - rev 340319
Push 12940 by gszorc@mozilla.com at Tue, 15 Mar 2016 05:18:01 +0000
Bug 1256530 - Disable C4312 to unblock compilation on VS2015; r?smaug As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: BXytOjiy0uX
7bbb54a4b9127b3058aab49d861ccc5ce683746a: Bug 1256535 - Disable C4577 to unblock compilation on VS2015; r?poiru draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:44:22 -0700 - rev 340318
Push 12939 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:44:47 +0000
Bug 1256535 - Disable C4577 to unblock compilation on VS2015; r?poiru The previous disabling of this warning on just Key.cpp was not sufficient because another file from the unified sources list appears to include the header exhibiting the warning. MozReview-Commit-ID: rR2XXigTJU
c711355adcdfefcc44706ca71a5e227985315fdc: Bug 1256545 - Disable C4311 to unblock compilation on VS2015; r?jesup draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:41:24 -0700 - rev 340317
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +0000
Bug 1256545 - Disable C4311 to unblock compilation on VS2015; r?jesup As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: LOiUCH7qfyW
74df24a2a9ec64d35744fb89c0d0c8ba9690c661: enable PGO draft
Gregory Szorc <gps@mozilla.com> - Tue, 08 Mar 2016 14:48:22 -0800 - rev 340316
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +0000
enable PGO MozReview-Commit-ID: EdiNUx21iPr
cc286902146123c92386827f3d321be8ab90ab77: Bug 1256530 - Disable C4312 to unblock compilation on VS2015; r?smaug draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:09:32 -0700 - rev 340315
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +0000
Bug 1256530 - Disable C4312 to unblock compilation on VS2015; r?smaug As part of unblocking building with VS2015u1 in automation, I'm mass disabling compiler warnings that are turned into errors. This is not the preferred mechanism to fix compilation warnings. So hopefully this patch never lands because someone insists on fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: BXytOjiy0uX
53e30d2c41bbcbb7f4a8a5d00607d949eac59f92: Bug 1256530 - Test reinterpret_cast fix draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 21:34:32 -0700 - rev 340314
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +0000
Bug 1256530 - Test reinterpret_cast fix MozReview-Commit-ID: BYMnxNwVCoa
6f11ec74972f89126accf02960acb27878517f2e: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 18:50:10 -0700 - rev 340313
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +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
c596d07a280b1384b849eac486b710ffa490d503: Bug 1253707 - Script to generate visual studio toolchain archive; r?ted draft
Gregory Szorc <gps@mozilla.com> - Fri, 11 Mar 2016 15:00:02 -0800 - rev 340312
Push 12938 by gszorc@mozilla.com at Tue, 15 Mar 2016 04:41:37 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip