deb1dba5449d15c6b697a02f688d4b19339161c6: Bug 1256482 - Disable C4312 to unblock compilation on VS2015; r?jesup draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 16:05:06 -0700 - rev 340050
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1256482 - Disable C4312 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, of course. Given that the warning is in WebRTC which is third party code, there isn't much we can do about the warning. However, Google is building Chrome with Visual Studio 2015, so I wouldn't be surprised if this were fixed upstream or will be fixed upstream. Then again, we allow warnings when building WebRTC. So perhaps not. MozReview-Commit-ID: G6JP9fkCzfn
a2af8be864806b229ff329ab560a76bc553ef009: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340049
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +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
256e86799fc0e845105c4b5d8acff2c610582a24: 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 340048
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +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
17435b0aedc10c2b6f4846aaeb558b1a38280b20: 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 340047
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +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
7b5ad0d12e3408e6a925676bdd318c9212f40d0b: Bug 1256473 - Disable C4838 to unblock compilation on VS2015; r?honza draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:49:00 -0700 - rev 340046
Push 12893 by gszorc@mozilla.com at Mon, 14 Mar 2016 23:05:32 +0000
Bug 1256473 - Disable C4838 to unblock compilation on VS2015; r?honza 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: DXCShwn4hHf
98f3db8adf27c15dbcd9f5f2ccf6ed62b7bae0ae: Bug 1256473 - Disable C4838 to unblock compilation on VS2015; r?honza draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:49:00 -0700 - rev 340045
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +0000
Bug 1256473 - Disable C4838 to unblock compilation on VS2015; r?honza 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: DXCShwn4hHf
85deef52c2358d308e816b5cf448256d4fabcbbb: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340044
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +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
1acb918bcb588113550a7de82c2a318730b45123: 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 340043
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +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
32cf390de19b0e500edb0f0e06d01865c07e49ac: 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 340042
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +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
7aa1ae5098c608c628bdbb7abe87ab8074cd98ce: Bug 1256024 - Disable C4838 to unblock compilation on VS2015; r?aklotz draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:21:09 -0700 - rev 340041
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +0000
Bug 1256024 - Disable C4838 to unblock compilation on VS2015; r?aklotz 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: Gcq3Qna02iB
dabd4a9ee62c09e73ada5f06ae20c81d357eeae5: Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:14:57 -0700 - rev 340040
Push 12892 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:49:15 +0000
Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 9Dc5eeXw52R
6087bbcea58d0a0090b3e6d375969d67a6f1ecf5: Bug 1256373 - Simplify mMaybeHitRegion. r?tn draft
Benoit Girard <b56girard@gmail.com> - Mon, 14 Mar 2016 18:45:58 -0400 - rev 340039
Push 12891 by b56girard@gmail.com at Mon, 14 Mar 2016 22:46:16 +0000
Bug 1256373 - Simplify mMaybeHitRegion. r?tn MozReview-Commit-ID: D34S5iEczPp
618928f007775e90cb0ba5e96d023214d36900c9: Bug 1248044 - Add nsRegionBuilder. draft
Benoit Girard <b56girard@gmail.com> - Mon, 14 Mar 2016 18:44:49 -0400 - rev 340038
Push 12891 by b56girard@gmail.com at Mon, 14 Mar 2016 22:46:16 +0000
Bug 1248044 - Add nsRegionBuilder. MozReview-Commit-ID: 8MZzA4Zx6tV
f3126bf6c31e39f7e7f65e18f76e396b9b4a8399: Bug 1250244 - (WIP, Don't commit) Implement WebVR 1.0 API draft
Kearwood (Kip) Gilbert <kgilbert@mozilla.com> - Wed, 24 Feb 2016 15:54:50 -0800 - rev 340037
Push 12890 by kgilbert@mozilla.com at Mon, 14 Mar 2016 22:39:46 +0000
Bug 1250244 - (WIP, Don't commit) Implement WebVR 1.0 API MozReview-Commit-ID: JTOmaWePlJq
3bf765ad6bc6d21e36aff2f5bcfc7968d62825c2: Bug 1256024 - Disable C4838 to unblock compilation on VS2015; r?aklotz draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:21:09 -0700 - rev 340036
Push 12889 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:21:24 +0000
Bug 1256024 - Disable C4838 to unblock compilation on VS2015; r?aklotz 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: Gcq3Qna02iB
038c2fe02074d03a6c34d44f68cb5f078a2472cc: Bug 1092004 - Use getdtablesize for non-gonk builds as well. r=glandium draft
Nathan Toone <nathan@toonetown.com> - Mon, 14 Mar 2016 16:19:12 -0600 - rev 340035
Push 12888 by nathan@toonetown.com at Mon, 14 Mar 2016 22:20:15 +0000
Bug 1092004 - Use getdtablesize for non-gonk builds as well. r=glandium When building non-gonk builds, ANDROID_VERSION is not set. Beginning with NDK 11, getdtablesize is no longer included. This means that we should use the stub version of the function that is defined in android_stub.h for all android platforms. This patch moves the function out of the "#if ANDROID_VERSION >=21" block so that all android code can use it. Adding glandium as the reviewer, because he reviewed the original patch at bug 1103816. MozReview-Commit-ID: 2NmUl5XuvDS
62d93df1226482ed0a284ad22359dc48d8b47600: Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj draft
Gregory Szorc <gps@mozilla.com> - Mon, 14 Mar 2016 15:14:57 -0700 - rev 340034
Push 12887 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:15:17 +0000
Bug 1256464 - Disable C4477 to unblock compilation on VS2015; r?froydnj 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 of fixing the underlying problem instead. But if it does land, hopefully the workaround is only temporary. MozReview-Commit-ID: 9Dc5eeXw52R
01fa28d57f53278f8af1a24150ab11daf21440f6: Bug 1186060 - Build with Visual Studio 2015 Update 1; r?ted, ehsan draft
Gregory Szorc <gps@mozilla.com> - Thu, 10 Mar 2016 21:13:20 -0800 - rev 340033
Push 12887 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:15:17 +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
74585a90d492bba3fbdef725bf7c7d57707cd5c5: 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 340032
Push 12887 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:15:17 +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
3375c2b043a0b3313e5976eda11db69b3f79a4cb: 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 340031
Push 12887 by gszorc@mozilla.com at Mon, 14 Mar 2016 22:15:17 +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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 +300000 tip