Get Chrome compiling on VS2017 |
|||||||||||||||||||
Issue descriptionGetting Chrome compiling with VS 2017 is worthwhile because of: - Improved C++11/14/17 conformance - Tons of constexpr improvements - Might as well see if it's worth switching - Keep the clang-cl team honest Whether we switch or not is TBD. Note that current tests are being done with a release candidate that was published in early January 2017.
Showing comments 83 - 182
of 182
Older ›
,
Apr 18 2017
I think it's fine to just do this for everyone (I think it no longer requires a landmine). If you land late Friday and revert early Monday, it probably wouldn't affect that many people.
,
Apr 18 2017
,
Apr 18 2017
You are correct that a landmine is no longer needed, which makes the rebuilds that changing the compiler causes somewhat less destructive.
,
Apr 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9191144caf319a8992012d8b5260b0c65cd987ed commit 9191144caf319a8992012d8b5260b0c65cd987ed Author: brucedawson <brucedawson@chromium.org> Date: Tue Apr 18 23:22:10 2017 Disable tests on VS 2017 RTM, code-gen bug VS 2017 RTM has what appears to be a code-gen bug. This bug is discussed and reported here: https://developercommunity.visualstudio.com/content/problem/40904/bad-code-gen-in-chromes-mojo-public-bindings-unitt.html In order to allow us to make forward progress, such as trying a canary build of Chrome with VS 2017, this CL disables the four affected tests for the VS 2017 RTM compiler only. BUG= 683729 Review-Url: https://codereview.chromium.org/2826713003 Cr-Commit-Position: refs/heads/master@{#465420} [modify] https://crrev.com/9191144caf319a8992012d8b5260b0c65cd987ed/mojo/public/cpp/bindings/tests/pickle_unittest.cc
,
Apr 18 2017
,
Apr 20 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/build/+/c1b0c780a218b38df08a29b4e1fc6321369cb45e commit c1b0c780a218b38df08a29b4e1fc6321369cb45e Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Thu Apr 20 17:58:24 2017
,
Apr 20 2017
The following revision refers to this bug: https://chrome-internal.googlesource.com/chrome/tools/build/+/c1b0c780a218b38df08a29b4e1fc6321369cb45e commit c1b0c780a218b38df08a29b4e1fc6321369cb45e Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Thu Apr 20 17:58:24 2017
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/build/+/34e259420ac72f7b6a516528a11ceb5dbc7cea24 commit 34e259420ac72f7b6a516528a11ceb5dbc7cea24 Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Thu Apr 20 20:17:25 2017 Pin the SyzyAsan builders to VS2015. SyzyAsan doesn't support VS2017 yet, see https://codereview.chromium.org/2762093003/#msg56 for more context. BUG= 683729 Change-Id: I0b7157979f8d23c88983fe898b32107b725c078a Reviewed-on: https://chromium-review.googlesource.com/483070 Reviewed-by: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> [modify] https://crrev.com/34e259420ac72f7b6a516528a11ceb5dbc7cea24/scripts/slave/recipes/webrtc/standalone.expected/tryserver_webrtc_win_asan.json [modify] https://crrev.com/34e259420ac72f7b6a516528a11ceb5dbc7cea24/scripts/slave/recipe_modules/chromium/config.py [modify] https://crrev.com/34e259420ac72f7b6a516528a11ceb5dbc7cea24/scripts/slave/recipes/webrtc/standalone.expected/client_webrtc_win_syzyasan.json [modify] https://crrev.com/34e259420ac72f7b6a516528a11ceb5dbc7cea24/scripts/slave/recipes/chromium.expected/full_chromium_lkgr_Win_SyzyASAN_LKGR.json
,
Apr 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5634becc3cf55dd16d8e5f6e56a7105c4efcf8af commit 5634becc3cf55dd16d8e5f6e56a7105c4efcf8af Author: brucedawson <brucedawson@chromium.org> Date: Sat Apr 22 04:29:53 2017 Changing default Windows compiler to VS 2017 This CL is currently purely for testing purposes. BUG= 683729 Review-Url: https://codereview.chromium.org/2762093003 Cr-Commit-Position: refs/heads/master@{#466536} [modify] https://crrev.com/5634becc3cf55dd16d8e5f6e56a7105c4efcf8af/build/vs_toolchain.py
,
Apr 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a9d5d30b3deb074bb9eea410b75cd1d2220ac9ea commit a9d5d30b3deb074bb9eea410b75cd1d2220ac9ea Author: findit-for-me <findit-for-me@appspot.gserviceaccount.com> Date: Sat Apr 22 18:40:21 2017 Revert of Changing default Windows compiler to VS 2017 (patchset #9 id:160001 of https://codereview.chromium.org/2762093003/ ) Reason for revert: Findit(https://goo.gl/kROfz5) identified CL at revision 466536 as the culprit for failures in the build cycles as shown on: https://findit-for-me.appspot.com/waterfall/culprit?key=ag9zfmZpbmRpdC1mb3ItbWVyRAsSDVdmU3VzcGVjdGVkQ0wiMWNocm9taXVtLzU2MzRiZWNjM2NmNTVkZDE2ZDhlNWY2ZTU2YTcxMDVjNGVmY2Y4YWYM Original issue's description: > Changing default Windows compiler to VS 2017 > > This CL is currently purely for testing purposes. > > BUG= 683729 > > Review-Url: https://codereview.chromium.org/2762093003 > Cr-Commit-Position: refs/heads/master@{#466536} > Committed: https://chromium.googlesource.com/chromium/src/+/5634becc3cf55dd16d8e5f6e56a7105c4efcf8af TBR=thakis@chromium.org,scottmg@chromium.org,dpranke@chromium.org,sebmarchand@chromium.org,brucedawson@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 683729 Review-Url: https://codereview.chromium.org/2832373002 Cr-Commit-Position: refs/heads/master@{#466538} [modify] https://crrev.com/a9d5d30b3deb074bb9eea410b75cd1d2220ac9ea/build/vs_toolchain.py
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/83c058a98cc8f4e089f8cb82b728611e323bab94 commit 83c058a98cc8f4e089f8cb82b728611e323bab94 Author: brucedawson <brucedawson@chromium.org> Date: Mon Apr 24 19:29:59 2017 Avoid signed/unsigned warning in VC++ 2017 builds VC++ 2017's STL doesn't suppress warnings as aggressively as prior versions did. This causes warnings on code which mixes signed and unsigned types. In this case a deque of unsigned integers was being queried to see how many signed integers it contains. This could be fixed by passing in unsigned 0, 1, and 2 to std::count but changing the deque from unsigned to int is simpler. R=adamk@chromium.org BUG= chromium:683729 Review-Url: https://codereview.chromium.org/2834293002 Cr-Commit-Position: refs/heads/master@{#44814} [modify] https://crrev.com/83c058a98cc8f4e089f8cb82b728611e323bab94/test/unittests/base/iterator-unittest.cc
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/gyp/+/b62d04ff85e6234e4fec7fff9377dd96c09d41a7 commit b62d04ff85e6234e4fec7fff9377dd96c09d41a7 Author: Refael Ackermann <refack@gmail.com> Date: Mon Apr 24 22:04:19 2017 win,ninja: ninja generator better on windows * add compatibility with VS2017 * adjust `_TargetConfig` and `/FS` for VS2017 compat * find new place of `vcvarsall.bat` in VS2017 * normalize "path like" arguments of actions * better check for `.lib` and `.def` file names BUG= 683729 Change-Id: I123bff7bd8a0011cf65d27a62b5267ba884e3b42 Reviewed-on: https://chromium-review.googlesource.com/482580 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Commit-Queue: Dirk Pranke <dpranke@chromium.org> [modify] https://crrev.com/b62d04ff85e6234e4fec7fff9377dd96c09d41a7/pylib/gyp/MSVSVersion.py [modify] https://crrev.com/b62d04ff85e6234e4fec7fff9377dd96c09d41a7/pylib/gyp/msvs_emulation.py
,
Apr 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/gyp/+/b62d04ff85e6234e4fec7fff9377dd96c09d41a7 commit b62d04ff85e6234e4fec7fff9377dd96c09d41a7 Author: Refael Ackermann <refack@gmail.com> Date: Mon Apr 24 22:04:19 2017 win,ninja: ninja generator better on windows * add compatibility with VS2017 * adjust `_TargetConfig` and `/FS` for VS2017 compat * find new place of `vcvarsall.bat` in VS2017 * normalize "path like" arguments of actions * better check for `.lib` and `.def` file names BUG= 683729 Change-Id: I123bff7bd8a0011cf65d27a62b5267ba884e3b42 Reviewed-on: https://chromium-review.googlesource.com/482580 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Commit-Queue: Dirk Pranke <dpranke@chromium.org> [modify] https://crrev.com/b62d04ff85e6234e4fec7fff9377dd96c09d41a7/pylib/gyp/MSVSVersion.py [modify] https://crrev.com/b62d04ff85e6234e4fec7fff9377dd96c09d41a7/pylib/gyp/msvs_emulation.py
,
Apr 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/gyp/+/e8850240a433259052705fb8c56e51795b7dc9c3 commit e8850240a433259052705fb8c56e51795b7dc9c3 Author: Mark Mentovai <mark@chromium.org> Date: Tue Apr 25 03:27:52 2017 Fix MSVC++ 32-on-32 builds after b62d04ff85e6 BUG= 683729 Change-Id: Ic8c227960b859ddc3c19fce0e98144510f5e74bf Reviewed-on: https://chromium-review.googlesource.com/486380 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Mark Mentovai <mark@chromium.org> [modify] https://crrev.com/e8850240a433259052705fb8c56e51795b7dc9c3/pylib/gyp/MSVSVersion.py
,
Apr 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/gyp/+/ffd524cefaad622e72995e852ffb0b18e83f8054 commit ffd524cefaad622e72995e852ffb0b18e83f8054 Author: Mark Mentovai <mark@chromium.org> Date: Tue Apr 25 04:29:16 2017 win ninja/make: Always use a native compiler executable with MSVS 2017 A host-native executable will always be used, and it will be a cross compiler if the target architecture differs from the host architecture. BUG= 683729 Change-Id: I02a09e1755dd2ab7eca5c9d1957d7aeb56db6af6 Reviewed-on: https://chromium-review.googlesource.com/486400 Commit-Queue: Mark Mentovai <mark@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> [modify] https://crrev.com/ffd524cefaad622e72995e852ffb0b18e83f8054/pylib/gyp/MSVSVersion.py
,
Apr 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/060d293f1d87d450a824dc46f564792272ed34a3 commit 060d293f1d87d450a824dc46f564792272ed34a3 Author: brucedawson <brucedawson@chromium.org> Date: Sat Apr 29 11:47:47 2017 Changing default Windows compiler to VS 2017 This is a single character change to temporarily switch Chrome to building with VC++ 2017. This CL is currently purely for testing purposes and will be landed for the weekend in order to flesh out any remaining bugs. This is a retry of crrev.com/2762093003 which failed due to a compiler warning which was missed in local testing and the try bots. That warning has been resolved and a local build of 'all' completed cleanly. BUG= 683729 Review-Url: https://codereview.chromium.org/2852433005 Cr-Commit-Position: refs/heads/master@{#468239} [modify] https://crrev.com/060d293f1d87d450a824dc46f564792272ed34a3/build/vs_toolchain.py
,
May 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/93cf7d6a5e0ccbb248ac818c3c7c7181a409b45b commit 93cf7d6a5e0ccbb248ac818c3c7c7181a409b45b Author: brucedawson <brucedawson@chromium.org> Date: Mon May 01 06:49:56 2017 Revert of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2852433005/ ) Reason for revert: Reverting as planned - it was just a test switch to VS 2017, which seems to have gone smoothly. I'm hopeful that canary 60.0.3086.0 is being built with VS 2017, to complete the test. Original issue's description: > Changing default Windows compiler to VS 2017 > > This is a single character change to temporarily switch Chrome to > building with VC++ 2017. This CL is currently purely for testing > purposes and will be landed for the weekend in order to flesh out any > remaining bugs. > > This is a retry of crrev.com/2762093003 which failed due to a compiler > warning which was missed in local testing and the try bots. That warning > has been resolved and a local build of 'all' completed cleanly. > > BUG= 683729 > > Review-Url: https://codereview.chromium.org/2852433005 > Cr-Commit-Position: refs/heads/master@{#468239} > Committed: https://chromium.googlesource.com/chromium/src/+/060d293f1d87d450a824dc46f564792272ed34a3 TBR=thakis@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 683729 Review-Url: https://codereview.chromium.org/2851143002 Cr-Commit-Position: refs/heads/master@{#468298} [modify] https://crrev.com/93cf7d6a5e0ccbb248ac818c3c7c7181a409b45b/build/vs_toolchain.py
,
May 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/build/+/b7712e04694d0e3da2609b7395f1dfd0293e3195 commit b7712e04694d0e3da2609b7395f1dfd0293e3195 Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue May 02 22:58:01 2017 Don't force PGO builds to use VS 2015 Currently PGO builds are hard-coded to use VS 2015 - they ignore the default compiler as set in build\vs_toolchain.py, which leads to confusion. For instance, the 60.0.3086.0 canary used VS 2015 and this was initially assumed to be because it started building after the VS 2017 default-change was reverted, but that is not actually the case. VS 2017 became the default on #468239 and stopped being the default on #468298, but the canary build was built from #468266. Because the default compiler is currently VS 2015 this should not make any difference until the default in build\vs_toolchain.py is changed. The CL that changed the default compiler from VS 2013 to VS 2015 (crrev.com/1607063004) was more complex because it included changes to paths, whereas switching between VS 2015 and VS 2017 should be a one character change. Bug: 683729 Change-Id: Idbde58fc9649f5021d60c594a5a71df940a73c34 Reviewed-on: https://chromium-review.googlesource.com/492108 Reviewed-by: Sebastien Marchand <sebmarchand@google.com> Reviewed-by: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> [modify] https://crrev.com/b7712e04694d0e3da2609b7395f1dfd0293e3195/scripts/slave/recipes/chromium_pgo.expected/full_tryserver_chromium_win_win_pgo.json [modify] https://crrev.com/b7712e04694d0e3da2609b7395f1dfd0293e3195/scripts/slave/recipes/chromium_pgo.expected/full_chromium_fyi_Chromium_Win_PGO_Builder.json [modify] https://crrev.com/b7712e04694d0e3da2609b7395f1dfd0293e3195/scripts/slave/recipes/chromium_pgo.expected/full_chromium_fyi_Chromium_Win_x64_PGO_Builder.json [modify] https://crrev.com/b7712e04694d0e3da2609b7395f1dfd0293e3195/scripts/slave/recipe_modules/chromium/config.py [modify] https://crrev.com/b7712e04694d0e3da2609b7395f1dfd0293e3195/scripts/slave/recipe_modules/pgo/example.expected/full_chromium_pgo_test_Test_builder.json
,
May 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/11493012245d4434b492fb7ac2b666f3eeaface5 commit 11493012245d4434b492fb7ac2b666f3eeaface5 Author: sebmarchand <sebmarchand@chromium.org> Date: Wed May 03 20:19:34 2017 Bump Syzygy version to v0.8.29.0 Changelog: [ab9b65e1fd] Add support for the VS2017 built binaries. [5970d392db] Improve the decoding of the VEX encoded instructions. BUG= 683729 Review-Url: https://codereview.chromium.org/2857223002 Cr-Commit-Position: refs/heads/master@{#469103} [modify] https://crrev.com/11493012245d4434b492fb7ac2b666f3eeaface5/DEPS
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/build/+/f25c842180da0df876d765503b0edddc0f95e048 commit f25c842180da0df876d765503b0edddc0f95e048 Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Thu May 04 17:42:34 2017 Don't pin the SyzyAsan bots to VS2015. Syzygy support VS2017 now, this is a revert of https://chromium-review.googlesource.com/c/483070/ Bug:683729 Change-Id: I09e45f66ab0d32e2bfbd18a81de7f474681770ec Reviewed-on: https://chromium-review.googlesource.com/493844 Reviewed-by: Michael Moss <mmoss@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipe_modules/chromium/config.py [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipes/webrtc/standalone.expected/client_webrtc_win_syzyasan.json [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipes/chromium.expected/full_chromium_lkgr_Win_SyzyASAN_LKGR.json
,
May 4 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/build/+/f25c842180da0df876d765503b0edddc0f95e048 commit f25c842180da0df876d765503b0edddc0f95e048 Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Thu May 04 17:42:34 2017 Don't pin the SyzyAsan bots to VS2015. Syzygy support VS2017 now, this is a revert of https://chromium-review.googlesource.com/c/483070/ Bug:683729 Change-Id: I09e45f66ab0d32e2bfbd18a81de7f474681770ec Reviewed-on: https://chromium-review.googlesource.com/493844 Reviewed-by: Michael Moss <mmoss@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipe_modules/chromium/config.py [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipes/webrtc/standalone.expected/client_webrtc_win_syzyasan.json [modify] https://crrev.com/f25c842180da0df876d765503b0edddc0f95e048/scripts/slave/recipes/chromium.expected/full_chromium_lkgr_Win_SyzyASAN_LKGR.json
,
May 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ce36c5acc6e27a75e8fa455c92277de713922ac0 commit ce36c5acc6e27a75e8fa455c92277de713922ac0 Author: thakis <thakis@chromium.org> Date: Sat May 06 18:45:47 2017 Reland of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2851143002/ ) Reason for revert: Trying to get another canary built over the weekend. Will revert again on Sunday. Original issue's description: > Revert of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2852433005/ ) > > Reason for revert: > Reverting as planned - it was just a test switch to VS 2017, which seems to have gone smoothly. I'm hopeful that canary 60.0.3086.0 is being built with VS 2017, to > complete the test. > > Original issue's description: > > Changing default Windows compiler to VS 2017 > > > > This is a single character change to temporarily switch Chrome to > > building with VC++ 2017. This CL is currently purely for testing > > purposes and will be landed for the weekend in order to flesh out any > > remaining bugs. > > > > This is a retry of crrev.com/2762093003 which failed due to a compiler > > warning which was missed in local testing and the try bots. That warning > > has been resolved and a local build of 'all' completed cleanly. > > > > BUG= 683729 > > > > Review-Url: https://codereview.chromium.org/2852433005 > > Cr-Commit-Position: refs/heads/master@{#468239} > > Committed: https://chromium.googlesource.com/chromium/src/+/060d293f1d87d450a824dc46f564792272ed34a3 > > TBR=thakis@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG= 683729 > > Review-Url: https://codereview.chromium.org/2851143002 > Cr-Commit-Position: refs/heads/master@{#468298} > Committed: https://chromium.googlesource.com/chromium/src/+/93cf7d6a5e0ccbb248ac818c3c7c7181a409b45b TBR=brucedawson@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 683729 Review-Url: https://codereview.chromium.org/2863313002 Cr-Commit-Position: refs/heads/master@{#469843} [modify] https://crrev.com/ce36c5acc6e27a75e8fa455c92277de713922ac0/build/vs_toolchain.py
,
May 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7ec9f9be09789ae4bafb7c6067c898d24255363 commit c7ec9f9be09789ae4bafb7c6067c898d24255363 Author: thakis <thakis@chromium.org> Date: Mon May 08 01:27:52 2017 Revert of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2863313002/ ) Reason for revert: We hopefully had a canary with this by now. Original issue's description: > Reland of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2851143002/ ) > > Reason for revert: > Trying to get another canary built over the weekend. Will revert again on Sunday. > > Original issue's description: > > Revert of Changing default Windows compiler to VS 2017 (patchset #1 id:1 of https://codereview.chromium.org/2852433005/ ) > > > > Reason for revert: > > Reverting as planned - it was just a test switch to VS 2017, which seems to have gone smoothly. I'm hopeful that canary 60.0.3086.0 is being built with VS 2017, to > > complete the test. > > > > Original issue's description: > > > Changing default Windows compiler to VS 2017 > > > > > > This is a single character change to temporarily switch Chrome to > > > building with VC++ 2017. This CL is currently purely for testing > > > purposes and will be landed for the weekend in order to flesh out any > > > remaining bugs. > > > > > > This is a retry of crrev.com/2762093003 which failed due to a compiler > > > warning which was missed in local testing and the try bots. That warning > > > has been resolved and a local build of 'all' completed cleanly. > > > > > > BUG= 683729 > > > > > > Review-Url: https://codereview.chromium.org/2852433005 > > > Cr-Commit-Position: refs/heads/master@{#468239} > > > Committed: https://chromium.googlesource.com/chromium/src/+/060d293f1d87d450a824dc46f564792272ed34a3 > > > > TBR=thakis@chromium.org > > # Not skipping CQ checks because original CL landed more than 1 days ago. > > BUG= 683729 > > > > Review-Url: https://codereview.chromium.org/2851143002 > > Cr-Commit-Position: refs/heads/master@{#468298} > > Committed: https://chromium.googlesource.com/chromium/src/+/93cf7d6a5e0ccbb248ac818c3c7c7181a409b45b > > TBR=brucedawson@chromium.org > # Not skipping CQ checks because original CL landed more than 1 days ago. > BUG= 683729 > > Review-Url: https://codereview.chromium.org/2863313002 > Cr-Commit-Position: refs/heads/master@{#469843} > Committed: https://chromium.googlesource.com/chromium/src/+/ce36c5acc6e27a75e8fa455c92277de713922ac0 TBR=brucedawson@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 683729 NOTRY=true Review-Url: https://codereview.chromium.org/2870523002 Cr-Commit-Position: refs/heads/master@{#469904} [modify] https://crrev.com/c7ec9f9be09789ae4bafb7c6067c898d24255363/build/vs_toolchain.py
,
May 10 2017
There's still some issue with the PGO build because the location of the PGO binaries (pgort1x0.dll, pgosweep.exe...) has changed, instead of being in VC\bin\amd64_x86 it's now in VC\Tools\MSVC\14.10.25017\bin\HostX64\x86. I'll update vs_toolchain.py to make it pick up these files in their new location...
,
May 10 2017
Any idea why the pgosweep path change didn't show up when I ran a try job on the PGO bot?
,
May 11 2017
It's because this test has been done before this CL : https://chromium-review.googlesource.com/c/492108/ ("Don't force PGO builds to use VS 2015")
,
May 11 2017
,
May 15 2017
,
May 17 2017
,
May 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f073ac02784b6a426a86e20c4623c09ae2a211ba commit f073ac02784b6a426a86e20c4623c09ae2a211ba Author: brucedawson <brucedawson@chromium.org> Date: Thu May 18 19:26:43 2017 Allow building with VS 2017 Update 3 VS 2017 Update 3 (preview available now) changes _MSC_VER from 1910 to 1911. This change detects this range as being VS 2017 in order to allow building and testing with the Update 3 preview. R=bauerb@chromium.org BUG= 683729 Review-Url: https://codereview.chromium.org/2894493002 Cr-Commit-Position: refs/heads/master@{#472900} [modify] https://crrev.com/f073ac02784b6a426a86e20c4623c09ae2a211ba/chrome/browser/ui/webui/version_ui.cc
,
May 26 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bc58befabe87e204650c836793204bac887992bd commit bc58befabe87e204650c836793204bac887992bd Author: brucedawson <brucedawson@chromium.org> Date: Fri May 26 19:34:56 2017 Switch VS 2017 builds to VS 2017 Update 3 Preview 1 This change switches the VS 2017 package to use the first Update 3 Preview. Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading the VS 2017 Update 3 Preview 1, from https://www.visualstudio.com/vs/preview/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.14393.0 SDK (10.0.14393.795, to be precise) was installed, necessary because Chrome currently requires that SDK. This also installs the x86 and x64 debuggers. Then statreg.h in the VS install was patched to add constexpr for clang-cl (but not for VC++, which can't handle it), per this bug: https://developercommunity.visualstudio.com/content/problem/58907/statregh-doesnt-compile-with-clang-cl-constconstex.html The patched version is attached to this bug comment: https://bugs.chromium.org/p/chromium/issues/detail?id=683729#c113 Finally the packaging script (updated in https://chromium-review.googlesource.com/516442) was run: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.14393.0 VS 2015 builds are still the default. R=scottmg@chromium.org BUG= 683729 Review-Url: https://codereview.chromium.org/2904733004 Cr-Commit-Position: refs/heads/master@{#475088} [modify] https://crrev.com/bc58befabe87e204650c836793204bac887992bd/build/vs_toolchain.py
,
May 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/833aa96095e1f827ffc05af8bf545a094ffa6e35 commit 833aa96095e1f827ffc05af8bf545a094ffa6e35 Author: sebmarchand <sebmarchand@chromium.org> Date: Sat May 27 01:34:31 2017 Changing default Windows compiler to VS2017 Doing another VS2017 test over the week end now that the PGO issues have been fixed. This CL is currently purely for testing purposes and will be reverted by the end of the week end. BUG= 683729 Review-Url: https://codereview.chromium.org/2877993002 Cr-Commit-Position: refs/heads/master@{#475212} [modify] https://crrev.com/833aa96095e1f827ffc05af8bf545a094ffa6e35/build/vs_toolchain.py
,
May 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5ea5799ced8c179ee57cf877d370e763e76d819c commit 5ea5799ced8c179ee57cf877d370e763e76d819c Author: thakis <thakis@chromium.org> Date: Mon May 29 15:14:30 2017 Revert of Changing default Windows compiler to VS2017 (patchset #1 id:1 of https://codereview.chromium.org/2877993002/ ) Reason for revert: We have a canary. Original issue's description: > Changing default Windows compiler to VS2017 > > Doing another VS2017 test over the week end now that the PGO issues have > been fixed. > > This CL is currently purely for testing purposes and will be reverted by > the end of the week end. > > BUG= 683729 > > Review-Url: https://codereview.chromium.org/2877993002 > Cr-Commit-Position: refs/heads/master@{#475212} > Committed: https://chromium.googlesource.com/chromium/src/+/833aa96095e1f827ffc05af8bf545a094ffa6e35 TBR=brucedawson@chromium.org,sebmarchand@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 683729 Review-Url: https://codereview.chromium.org/2909903002 Cr-Commit-Position: refs/heads/master@{#475354} [modify] https://crrev.com/5ea5799ced8c179ee57cf877d370e763e76d819c/build/vs_toolchain.py
,
May 30 2017
,
May 30 2017
I used this query (thanks stanisc@) to grab the top 100 crash signatures for 61.0.3114.0 (VS 2017) and 61.0.3113.0 (VS 2015): SELECT custom_data.ChromeCrashProto.magic_signature_1.name as Signature, COUNT(*) as Count FROM crash.prod.latest WHERE product.name='Chrome' AND Product.Version = '61.0.3114.0' GROUP BY Signature, ORDER BY Count DESC LIMIT 100 I then hacked up a script to remove the common entries. With that done the VS 2017-only crashes and their counts are: 8 Third party - taskbardockappintegration64.dll 8 [GPU hang] RtlUserThreadStart 8 [Out of Memory] base::`anonymous namespace'::OnNoMemory 8 [Out of Memory] gpu::gles2::GLES2DecoderImpl::ClearLevel 8 [Renderer hang] blink::BoundaryNodeWillBeRemoved 9 [Dump without crash] DependencyManager::AssertContextWasntDestroyed 9 [Dump without crash] content::WebURLLoaderImpl::Context::Start 9 [GPU hang] media::DXVAVideoDecodeAccelerator::CreateD3DDevManager 9 [GPU hang] nvwgf2um.dll 9 [Third party - igd10umd32.dll] gl::CopyingGLImageDXGI::BindTexImage 9 [ppFlash DRM] CoreGlobals::Destroy 10 [ppPlugin hang] SObject::FreeChildren 11 [ANGLE] rx::SwapChain11::present 11 [Dump without crash] base::SequencedWorkerPool::Inner::ThreadLoop 11 base::RecommitSystemPages 11 pepper::Module::GetFirstInstanceHandleHack 12 [GPU hang] media::DXVAVideoDecodeAccelerator::Invalidate 13 Third party - nzbrcom.dll 13 [GPU hang] atiumd64.dll 13 [GPU hang] base::PendingTask::PendingTask 13 blink::HeapObjectHeader::Finalize 15 [Out of Memory] crashpad::ReadMemoryInfo 15 [Renderer hang] v8::internal::IncrementalMarking::Step 15 v8::internal::IterateAndScavengePromotedObjectsVisitor::VisitPointers 18 blink::Resource::AddClient - old, crbug.com/722820 19 [GPU hang] base::internal::MessageLoopTaskRunner::PostDelayedTask 19 blink::PrePaintTreeWalk::Walk - old, crbug.com/712985 20 blink::LocalFrameView::PerformLayout - new, now bug yet. 21 [GPU hang] Microsoft::WRL::ComPtr<IDWriteLocalizedStrings>::InternalRelease 23 content::WebContents::FromRenderFrameHost - investigated as crbug.com/724113, not new 30 [Shutdown hang] base::internal::TaskSchedulerImpl::Shutdown - investigated as crbug.com/727526, new in 61.0.3114.0 38 [ANGLE] std::basic_string<char,std::char_traits<char>,std::allocator<char> >::basic_string<char,std::char_traits<char>,std::allocator<char> > - matches crbug.com/727671, could be a compiler bug, or just a different signature. 58 [Out of Memory] v8::internal::AccountingAllocator::GetSegment - probably equivalent to v8::internal::AccountingAllocator::AllocateSegment on VS 2015 And the VS 2015-only crashes and their counts are: 4 [Dump without crash] content::BrowserChildProcessHostImpl::TerminateOnBadMessageReceived 4 [GPU hang] ANGLE: rx::Renderer11::testDeviceLost 4 [GPU hang] TargetNtOpenFile 4 [Renderer hang] blink::ScopedStyleResolver::CollectMatchingAuthorRules 4 [Shutdown hang] base::internal::TaskTracker::PerformShutdown 4 v8::internal::FlexibleBodyVisitor<v8::internal::StaticScavengeVisitor,v8::internal::FlexibleBodyDescriptor<16>,int>::Visit 5 [GPU hang] igdumdim64.dll 5 [GPU hang] media::DXVAVideoDecodeAccelerator::StopOnError 5 [Renderer hang] v8::internal::BodyDescriptorBase::IteratePointers<v8::internal::MarkCompactMarkingVisitor> 5 [Renderer kill 24] content::DatabaseMessageFilter::OnDatabaseModified 5 [Shutdown hang] OSCrypt::DecryptString 5 blink::MutationObserver::EnqueueMutationRecord 5 blink::PersistentRegion::AllocatePersistentNode 5 blink::SubtreeLayoutScope::SubtreeLayoutScope 6 [GPU hang] ANGLE: malloc_base 6 [ThreadWatcher UI hang] base::MessagePumpForUI::WaitForWork 6 gpu::GpuChannelMessageFilter::OnChannelClosing 7 [Dump without crash] base::debug::TaskAnnotator::RunTask 7 [GPU hang] ANGLE: Concurrency::task_options::~task_options 7 [GPU hang] ANGLE: free_base 7 [Renderer hang] blink::Node::parentNode 7 [Renderer hang] blink::SelectorChecker::MatchSelector 7 v8::internal::FlexibleBodyVisitor<v8::internal::IncrementalMarkingMarkingVisitor,v8::internal::JSObject::FastBodyDescriptor,void>::Visit 7 v8::internal::IncrementalMarkingMarkingVisitor::VisitFixedArrayIncremental 8 Third party - igdumd64.dll 8 [Out of Memory] v8::internal::Heap::TracePossibleWrapper 9 [GPU hang] scoped_refptr<gpu::gles2::Buffer>::~scoped_refptr<gpu::gles2::Buffer> 10 blink::LocalFrameView::RemoveScrollableArea 13 [GPU hang] base::win::ScopedComPtr<IMFMediaType>::Reset 15 content::RenderFrameDevToolsAgentHost::GetType 26 [ANGLE] rx::ResourceManager11::allocate<ID3D11ShaderResourceView> 30 [Out of Memory] v8::internal::AccountingAllocator::AllocateSegment 45 base::i18n::InitializeICU The third party and GPU hang crashes can probably be treated as noise, and the most-hit 2017 crash is probably just a different signature for a VS 2015 crash. Beyond that it's hard to know what to conclude. Is it all just noise? I'll dig in to some of the top entries. Note that if we assume that the GetSegment crash matches the VS 2015 AllocateSegment crash then the top twenty crashes all match up between the two of them, which seems like a good sign. I've looked briefly at the top nine unmatched VS 2017 crashes and I haven't found anything definitive.
,
May 30 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/aad003b6c1e081db8012c1d2f7a76e5c2f83d6ce commit aad003b6c1e081db8012c1d2f7a76e5c2f83d6ce Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue May 30 23:29:55 2017 Support VS 2017 Preview and changed VS directories VS 2017 Preview installs to a different directory from VS 2017 RTM, so the packaging script needs to be updated to handle this. It does this by using vswhere.exe so that any VS 2017 install can be found automatically. If there are multiple installs then it is not well defined which one will be found, so make sure you don't have multiple installs. The other change is to more robustly find the many directory paths which contain embedded version numbers. Previously these were hard-coded for VS 2017 RTM but this quickly gets tedious so now glob.glob is used to find the matching directories. This will intentionally fail if there is any ambiguity. R=scottmg@chromium.org BUG= 683729 Change-Id: I02f7ae7589e271d6d9897f899e0730d7163f76ef Reviewed-on: https://chromium-review.googlesource.com/516442 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> [modify] https://crrev.com/aad003b6c1e081db8012c1d2f7a76e5c2f83d6ce/win_toolchain/package_from_installed.py
,
May 31 2017
Not strictly VS 2017 related, but the Windows 10.0.15063.0 SDK has a version of event.h (win_sdk\Include\10.0.15063.0\winrt\wrl\event.h) that is malformed and can't be processed by clang-cl. I'm attaching a patched version here so that the patched statreg.h and event.h can be found within the same bug. This bug describes a broken Bits.h (now fixed) and the broken event.h (now broken in a slightly different way): https://developercommunity.visualstudio.com/content/problem/42961/15063-sdk-is-broken-bitsh-indirectly-references-no.html
,
May 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/0209d792775b1efa537a6c30cfeee699a33a82da commit 0209d792775b1efa537a6c30cfeee699a33a82da Author: Bruce Dawson <brucedawson@chromium.org> Date: Wed May 31 23:38:01 2017 Fix toolchain packaging script for latest SDKs On recent SDKs the size of the toolchain package grew. This change filters out some unneeded directories in order to minimize this growth. This change also fixes the bin paths for the 10.0.15063.0 SDK. Starting with this SDK version the SDK version is part of the path. The script does *not* handle packaging older SDKs anymore - older versions of the script can be used for that purpose. The 10.0.15063.0 SDK will be needed eventually in order to support Windows 10 Creators Update. Test builds are running on crrev.com/2913873003 (VS 2017) and crrev.com/2914643003 (VS 2015). Bug: 683729 , 682416 Change-Id: Ia89e3253869a45dd10c923a2edee53aaf086e12c Reviewed-on: https://chromium-review.googlesource.com/519982 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> [modify] https://crrev.com/0209d792775b1efa537a6c30cfeee699a33a82da/win_toolchain/package_from_installed.py
,
May 31 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/0209d792775b1efa537a6c30cfeee699a33a82da commit 0209d792775b1efa537a6c30cfeee699a33a82da Author: Bruce Dawson <brucedawson@chromium.org> Date: Wed May 31 23:38:01 2017 Fix toolchain packaging script for latest SDKs On recent SDKs the size of the toolchain package grew. This change filters out some unneeded directories in order to minimize this growth. This change also fixes the bin paths for the 10.0.15063.0 SDK. Starting with this SDK version the SDK version is part of the path. The script does *not* handle packaging older SDKs anymore - older versions of the script can be used for that purpose. The 10.0.15063.0 SDK will be needed eventually in order to support Windows 10 Creators Update. Test builds are running on crrev.com/2913873003 (VS 2017) and crrev.com/2914643003 (VS 2015). Bug: 683729 , 682416 Change-Id: Ia89e3253869a45dd10c923a2edee53aaf086e12c Reviewed-on: https://chromium-review.googlesource.com/519982 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> [modify] https://crrev.com/0209d792775b1efa537a6c30cfeee699a33a82da/win_toolchain/package_from_installed.py
,
Jun 13 2017
The code-gen bug ( crbug.com/723893 ) and the statreg.h bug (https://developercommunity.visualstudio.com/content/problem/58907/statregh-doesnt-compile-with-clang-cl-constconstex.html) have both been fixed in VS 2017 Update 3 Preview 2 (the second preview of Update 3, released June 8th). Try job is proceeding at crrev.com/2938453003.
,
Jun 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/d7e6ea67db02f96d1787c94de9e7bd6f275cbb48 commit d7e6ea67db02f96d1787c94de9e7bd6f275cbb48 Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue Jun 13 00:13:14 2017 Fix bug in bug handling code in packaging script When no files are found where there should be on the VS packaging script throw an exception - using a non-existent variable. Resolving the missing files is a separate problem that I have filed a VS bug for: https://developercommunity.visualstudio.com/content/problem/67864/vs-2017-update-3-preview-2-is-missing-mfc-redist-f.html Bug: 683729 Change-Id: I1a3ba2a342ce7f8fa826300bb808e87c36969b52 Reviewed-on: https://chromium-review.googlesource.com/532114 Reviewed-by: Scott Graham <scottmg@chromium.org> Reviewed-by: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> [modify] https://crrev.com/d7e6ea67db02f96d1787c94de9e7bd6f275cbb48/win_toolchain/package_from_installed.py
,
Jun 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/53ecf9341f32b7f3746e6f721da9d4dc6839fb98 commit 53ecf9341f32b7f3746e6f721da9d4dc6839fb98 Author: iclelland <iclelland@chromium.org> Date: Tue Jun 13 21:45:02 2017 Move container policy logic to frame owner classes. This specifically allows <frame> tags to have an exemption from supporting the Fullscreen API, even in same-origin contexts, and even when the declared policy would otherwise enable Fullscreen. BUG= 729658 Review-Url: https://codereview.chromium.org/2923563003 Cr-Commit-Position: refs/heads/master@{#479165} [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/BUILD.gn [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameElement.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameElement.h [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameElementBase.h [add] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameElementTest.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLFrameOwnerElement.h [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLIFrameElement.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLIFrameElement.h [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLIFrameElementTest.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/core/html/HTMLPlugInElement.h [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.h [modify] https://crrev.com/53ecf9341f32b7f3746e6f721da9d4dc6839fb98/third_party/WebKit/Source/platform/feature_policy/FeaturePolicyTest.cpp
,
Jun 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6460371218a734a724df68694975882f22c52d31 commit 6460371218a734a724df68694975882f22c52d31 Author: brucedawson <brucedawson@chromium.org> Date: Thu Jun 15 00:31:12 2017 VS 2017 Update 3 Preview 2 with 10.0.15063.0 SDK This change switches the VS 2017 package to use the 10.0.15063.0 SDK and the second preview of VS 2017 Update 3. Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading the VS 2017 Update 3 Preview 1, from https://www.visualstudio.com/vs/preview/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.15063.0 SDK installer was used to install the Debuggers package. Then wrl\event.h was patched to work around a problem with clang-cl builds, as described towards the end of this bug: https://developercommunity.visualstudio.com/content/problem/42961/15063-sdk-is-broken-bitsh-indirectly-references-no.html The patched version of event.h is attached to this bug comment: https://bugs.chromium.org/p/chromium/issues/detail?id=683729#c120 The packaging script was updated in https://chromium-review.googlesource.com/c/534353/ to support this version and was then run like this: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.15063.0 VS 2015 builds are still the default. R=scottmg@chromium.org BUG= 682416 , 727970 , 683729 Review-Url: https://codereview.chromium.org/2938453003 Cr-Commit-Position: refs/heads/master@{#479555} [modify] https://crrev.com/6460371218a734a724df68694975882f22c52d31/build/vs_toolchain.py
,
Jun 15 2017
,
Jun 15 2017
,
Jun 16 2017
While working on a CL to get rid of static initializers by making more use of constexpr I noticed that this works in VC++ 2017 but not VC++ 2015:
struct C {
static const int x;
};
constexpr int C::x = 10;
This simplifies getting rid of some static initializers.
Unfortunately this seemingly identical construct is still not supported:
extern const int foo_const;
constexpr int foo_const = 10;
So far I've incidentally found three constexpr definitions that are supported by VC++ 2017 but not VC++ 2015.
,
Jun 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f278a33ca6aff0723f13942bbb47b3753bea543d commit f278a33ca6aff0723f13942bbb47b3753bea543d Author: brucedawson <brucedawson@chromium.org> Date: Sat Jun 17 01:40:04 2017 Test changing default Windows compiler to VS2017 Doing another VS2017 test over the week end now to see if a recently discovered code-gen bug has been fixed. The VS 2017 package now uses VS 2017 Update 3 Preview 2 (was Preview 1 last time). At least one code-gen bug was fixed by Preview 2 but this bug may be a new one. This CL is currently purely for testing purposes and will be reverted by the end of the week end. R=scottmg@chromium.org BUG= 683729 ,727671 Review-Url: https://codereview.chromium.org/2862723004 Cr-Commit-Position: refs/heads/master@{#480264} [modify] https://crrev.com/f278a33ca6aff0723f13942bbb47b3753bea543d/build/vs_toolchain.py
,
Jun 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eb339abb6c31f0f6a02d7b7038031ced69898eea commit eb339abb6c31f0f6a02d7b7038031ced69898eea Author: brucedawson <brucedawson@chromium.org> Date: Sun Jun 18 23:26:06 2017 Revert of Test changing default Windows compiler to VS2017 (patchset #1 id:1 of https://codereview.chromium.org/2862723004/ ) Reason for revert: Build 61.0.3134.0 uses VS 2017 and that will be sufficient to let us look for performance regressions and crashes, so I am reverting. Original issue's description: > Test changing default Windows compiler to VS2017 > > Doing another VS2017 test over the week end now to see if a recently > discovered code-gen bug has been fixed. The VS 2017 package now uses > VS 2017 Update 3 Preview 2 (was Preview 1 last time). At least one > code-gen bug was fixed by Preview 2 but this bug may be a new one. > > This CL is currently purely for testing purposes and will be reverted by > the end of the week end. > > R=scottmg@chromium.org > BUG= 683729 ,727671 > > Review-Url: https://codereview.chromium.org/2862723004 > Cr-Commit-Position: refs/heads/master@{#480264} > Committed: https://chromium.googlesource.com/chromium/src/+/f278a33ca6aff0723f13942bbb47b3753bea543d TBR=scottmg@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG= 683729 ,727671 Review-Url: https://codereview.chromium.org/2944773002 Cr-Commit-Position: refs/heads/master@{#480315} [modify] https://crrev.com/eb339abb6c31f0f6a02d7b7038031ced69898eea/build/vs_toolchain.py
,
Jun 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/60ce12e4bf84419b990ae44ebb876b727edce313 commit 60ce12e4bf84419b990ae44ebb876b727edce313 Author: brucedawson <brucedawson@chromium.org> Date: Thu Jun 29 23:14:43 2017 Avoid constexpr compiler bug in VS 2017 The constexpr definition of kStaleFrameLimit in a lambda triggered an internal compiler error in VS 2017. A bug is being filed but we want to unblock VS 2017 builds while waiting for a fix. Moving the definition to the global scope is safe and efficient because it is still constexpr, so it just uses a bit of const space. This bug was triggered by crrev.com/c/546917. A VS compiler bug was filed here: https://developercommunity.visualstudio.com/content/problem/74761/ice-on-constexpr-in-lambda-in-update-3-of-preview.html BUG= 683729 Review-Url: https://codereview.chromium.org/2964573002 Cr-Commit-Position: refs/heads/master@{#483536} [modify] https://crrev.com/60ce12e4bf84419b990ae44ebb876b727edce313/media/filters/vpx_video_decoder.cc
,
Jul 6 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9da63a8364a4cdec18db79b537ac819d29dd4284 commit 9da63a8364a4cdec18db79b537ac819d29dd4284 Author: brucedawson <brucedawson@chromium.org> Date: Thu Jul 06 19:38:31 2017 VS 2017 Update 3 Preview 3 with fixed SDK This change switches the VS 2017 package to use the 10.0.15063.468 SDK and the third preview of VS 2017 Update 3. Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading the VS 2017 Update 3 Preview 3, from https://www.visualstudio.com/vs/preview/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.15063.468 SDK installer was used to install the Debuggers package and patch wrl\event.h (still broken in the SDK installed by VS 2017 Updat3 3). The packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.15063.0 VS 2015 builds are still the default so this makes no immediate difference. R=dpranke@chromium.org BUG= 683729 Review-Url: https://codereview.chromium.org/2966713003 Cr-Commit-Position: refs/heads/master@{#484715} [modify] https://crrev.com/9da63a8364a4cdec18db79b537ac819d29dd4284/build/vs_toolchain.py
,
Jul 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bdd28407468ded3d8565577c6ee6a5585b8534c4 commit bdd28407468ded3d8565577c6ee6a5585b8534c4 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Jul 14 01:20:08 2017 Update VC++ 2017 compiler version checking VC++ 2017 has had several _MSC_VER values which has required updating the code that displays what compiler Chrome is built with. This change future-proofs those checks to handle all future versions of VC++ 2017, based on information from Microsoft. BUG= 683729 Change-Id: Icc3ddb14534a16fed7ab4f54a71ee175974658ba Reviewed-on: https://chromium-review.googlesource.com/570124 Reviewed-by: Pam Greene <pam@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#486595} [modify] https://crrev.com/bdd28407468ded3d8565577c6ee6a5585b8534c4/chrome/browser/ui/webui/version_ui.cc
,
Jul 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/218308404f31ef8f428249febca2db1282f783a5 commit 218308404f31ef8f428249febca2db1282f783a5 Author: Bruce Dawson <brucedawson@chromium.org> Date: Sat Jul 15 02:20:35 2017 VS 2017 Update 3 Preview 4 with fixed SDK This change switches the VS 2017 package to use the 10.0.15063.468 SDK and the fourth preview of VS 2017 Update 3. Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading the VS 2017 Update 3 Preview 4, from https://www.visualstudio.com/vs/preview/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.15063.468 SDK installer was used to install the Debuggers package. The latest version of vswhere.exe doesn't show pre-release versions of VS by default so win_toolchain/package_from_installed.py was locally patched to add the -prerelease flag to the vswhere.exe invocation. Then the packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.15063.0 VS 2015 builds are still the default so this makes no immediate difference. R=dpranke@chromium.org BUG= 683729 Change-Id: Ic9515f6f315931c72a762411ea6713e86351ce37 Reviewed-on: https://chromium-review.googlesource.com/572480 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Cr-Commit-Position: refs/heads/master@{#486967} [modify] https://crrev.com/218308404f31ef8f428249febca2db1282f783a5/build/vs_toolchain.py
,
Jul 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/95ebf5a518b2cc7f96046d605057be87ab0e5682 commit 95ebf5a518b2cc7f96046d605057be87ab0e5682 Author: Bruce Dawson <brucedawson@chromium.org> Date: Sat Jul 15 21:54:58 2017 Test changing default Windows compiler to VS2017 Doing another VS2017 test over the week end now with the newly packaged VS 2017 Update 3 Preview 4 (was Preview 2 last time). This CL is currently purely for testing purposes and will be reverted by the end of the weekend. R=dpranke@chromium.org BUG= 683729 Change-Id: Ie5c2e92b789b1dcbd51d4e0028230b5b72ce9eb9 Reviewed-on: https://chromium-review.googlesource.com/572500 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#486999} [modify] https://crrev.com/95ebf5a518b2cc7f96046d605057be87ab0e5682/build/vs_toolchain.py
,
Jul 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8e6e8c57c1c30caf7e2756e95d5a59e90336b0bd commit 8e6e8c57c1c30caf7e2756e95d5a59e90336b0bd Author: Bruce Dawson <brucedawson@chromium.org> Date: Mon Jul 17 16:39:20 2017 Revert "Test changing default Windows compiler to VS2017" This reverts commit 95ebf5a518b2cc7f96046d605057be87ab0e5682. Reason for revert: Testing is done - VS 2017 canary should appear? Original change's description: > Test changing default Windows compiler to VS2017 > > Doing another VS2017 test over the week end now with the newly packaged > VS 2017 Update 3 Preview 4 (was Preview 2 last time). > > This CL is currently purely for testing purposes and will be reverted by > the end of the weekend. > > R=dpranke@chromium.org > BUG= 683729 > > Change-Id: Ie5c2e92b789b1dcbd51d4e0028230b5b72ce9eb9 > Reviewed-on: https://chromium-review.googlesource.com/572500 > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#486999} TBR=dpranke@chromium.org,brucedawson@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 683729 Change-Id: I65044b790dd7415e380381a47d204a838c7bd837 Reviewed-on: https://chromium-review.googlesource.com/573623 Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#487111} [modify] https://crrev.com/8e6e8c57c1c30caf7e2756e95d5a59e90336b0bd/build/vs_toolchain.py
,
Jul 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1d441d93779f4e81634c48119c542559d1155603 commit 1d441d93779f4e81634c48119c542559d1155603 Author: Nico Weber <thakis@chromium.org> Date: Mon Jul 17 17:14:19 2017 Revert "Test changing default Windows compiler to VS2017" This reverts commit 95ebf5a518b2cc7f96046d605057be87ab0e5682. Reason for revert: Weekend is over, and the tot bots are red while this is in ( https://crbug.com/727447 ) Original change's description: > Test changing default Windows compiler to VS2017 > > Doing another VS2017 test over the week end now with the newly packaged > VS 2017 Update 3 Preview 4 (was Preview 2 last time). > > This CL is currently purely for testing purposes and will be reverted by > the end of the weekend. > > R=dpranke@chromium.org > BUG= 683729 > > Change-Id: Ie5c2e92b789b1dcbd51d4e0028230b5b72ce9eb9 > Reviewed-on: https://chromium-review.googlesource.com/572500 > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#486999} TBR=dpranke@chromium.org,brucedawson@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 683729 Change-Id: I95eba007031776caacf6595485ecc47d131def45 Reviewed-on: https://chromium-review.googlesource.com/574434 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#487129}
,
Jul 19 2017
According to crbug.com/746245 the reverting of the VC++ 2017 test caused a "10.4% regression in thread_times.tough_scrolling_cases". In other words, VC++ 2017 gave a 10.4% speed boost (9.4% reduction in time) on this particular test.
,
Jul 20 2017
And, according to crbug.com/744727 the starting of the VC++ 2017 test caused a 26.8% regression in media_perftests, which is a particularly extreme version of a previously noticed regression in sinc_resampler_convolve/unoptimized_aligned which is believed to be caused by VC++ 2017 no longer generating aligned load/store AVX instructions from intrinsics.
,
Jul 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/97504bede7b77bcba21369e034de1b5cc9ee25e4 commit 97504bede7b77bcba21369e034de1b5cc9ee25e4 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Jul 21 17:49:15 2017 Roll src\tools\gyp eb296f67d..d61a9397e (9 commits) https://chromium.googlesource.com/external/gyp.git/+log/eb296f67da07..d61a9397e668 $ git log eb296f67d..d61a9397e --date=short --no-merges --format='%ad %ae %s' 2017-06-27 mblsha mac_tool.py: Handle non-zero ibtool return code. 2017-04-25 refack win: mkdir even when copying directory 2017-04-24 mark win ninja/make: Always use a native compiler executable with MSVS 2017 2017-04-24 mark Fix MSVC++ 32-on-32 builds after b62d04ff85e6 2017-04-24 dpranke Disable flaky test/copies/gyptest-all under msvs. 2017-04-24 refack win,ninja: ninja generator better on windows 2017-04-24 dpranke Clean up gyptest.py. 2017-04-21 dpranke Disable a bunch of tests on Mac. 2017-04-18 dpranke Update test/no-cpp/gyptest-no-cpp. In order to support building clang with a locally installed copy of VC++ 2017 using gn we need the latest version of tools\gyp. BUG= 683729 Change-Id: Id3420b00667f89b7eb33aa2227f2e8fdb8de180d Reviewed-on: https://chromium-review.googlesource.com/579892 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/master@{#488701} [modify] https://crrev.com/97504bede7b77bcba21369e034de1b5cc9ee25e4/DEPS
,
Jul 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/tools/depot_tools/+/5a80eab0f460a4ea63de21fefacca828c7a5d57d commit 5a80eab0f460a4ea63de21fefacca828c7a5d57d Author: Bruce Dawson <brucedawson@chromium.org> Date: Mon Jul 24 20:13:11 2017 Use -prerelease flag to vswhere when packaging VS With VS 2017 Update 3 Preview 4 the behavior of vswhere was changed so that it only reports on non-prerelease versions by default. This can be overridden by passing -prerelease. This broke our packaging setup. A temporary fix was used to package Preview 4 and this is the permanent. When -prerelease is passed then vswhere will report on all installed versions of VS, whether prerelease or not. The script will package the first one that it encounters. For best results you should only install one copy of VS when packaging it. Trivia: the original RTW version of VS 2017 was incorrectly tagged as isPrerelease: 1 which means that without the -prerelease flag it doesn't show up either! BUG= 683729 Change-Id: I98c1acb671dccef7ede4443fbbf498796946c52b Reviewed-on: https://chromium-review.googlesource.com/578767 Reviewed-by: Scott Graham <scottmg@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> [modify] https://crrev.com/5a80eab0f460a4ea63de21fefacca828c7a5d57d/win_toolchain/package_from_installed.py
,
Aug 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/eea6a9320ee23f115a1e18ac2b032ff835249746 commit eea6a9320ee23f115a1e18ac2b032ff835249746 Author: Sebastien Marchand <sebmarchand@chromium.org> Date: Fri Aug 18 13:02:20 2017 Fix a VS2017 compilation issue in wasm-js.cc The MSVC2017 build of Chrome fais with the following message: c:\src\chrome\src\out\debug\gen\base\trace_event\common\../../../../../../v8/src/wasm/wasm-js.cc(76): error C2872: 'byte': ambiguous symbol c:\src\chrome\src\out\debug\gen\base\trace_event\common\../../../../../../v8/src/wasm/wasm-js.cc(25): note: could be 'uint8_t byte' C:\src\chrome\src\v8\src/globals.h(141): note: or 'v8::internal::byte' Bug: chromium:683729 Change-Id: Icbc25cd1296d19b8c3942c5d968434ec03707c2f Reviewed-on: https://chromium-review.googlesource.com/617405 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> Cr-Commit-Position: refs/heads/master@{#47428} [modify] https://crrev.com/eea6a9320ee23f115a1e18ac2b032ff835249746/src/wasm/wasm-js.cc
,
Aug 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0269b680ee726032e7b2bd0e46923ef2ba08a7b9 commit 0269b680ee726032e7b2bd0e46923ef2ba08a7b9 Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue Aug 22 20:01:13 2017 VS 2017 Update 3 This change switches the VS 2017 package to use the 10.0.15063.468 SDK and the non-preview release of VS 2017 Update 3. Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading VS 2017 Update 3, from https://www.visualstudio.com/vs/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.15063.468 SDK installer was used to install the Debuggers package. Then the packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.15063.0 VS 2015 builds are still the default so this makes no immediate difference. R=scottmg@chromium.org BUG= 683729 Change-Id: I9a53d1739f0a3684efc719c03022c32a2e95175e Reviewed-on: https://chromium-review.googlesource.com/614920 Reviewed-by: Scott Graham <scottmg@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#496414} [modify] https://crrev.com/0269b680ee726032e7b2bd0e46923ef2ba08a7b9/build/vs_toolchain.py
,
Aug 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4289fd90c31584ce642f58d3b61ed7090e57e4a9 commit 4289fd90c31584ce642f58d3b61ed7090e57e4a9 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Aug 25 01:53:26 2017 Fix VC++ 2017 STL break with deque iterator circular_deque_const_iterator has non-const versions of operator* and operator->. The VC++ 2017 STL implementation of vector::assign ends up with const iterators (reasonable enough) and then cannot dereference them, leading to this error: include\xmemory(125): error C2678: binary '*': no operator found which takes a left-hand operand of type 'const base::internal::circular_deque_iterator<T>' when compiling: output.assign(history_.begin(), history_.end()); in components\drive\event_logger.cc. The fix is to tag the functions as const. Note that this breakage happens with both the clang and VC++ 2017 compilers, whenever the VC++ 2017 STL is used. BUG= 683729 Change-Id: Id6aad72017015cfbb16673fee1f1009d10ed6602 Reviewed-on: https://chromium-review.googlesource.com/633963 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#497294} [modify] https://crrev.com/4289fd90c31584ce642f58d3b61ed7090e57e4a9/base/containers/circular_deque.h
,
Aug 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1a56a637268fb862ea7c4fbfd8fc2d89c4b9eff4 commit 1a56a637268fb862ea7c4fbfd8fc2d89c4b9eff4 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Aug 25 18:56:35 2017 VS 2017 Update 3.2 This change switches the VS 2017 package to use the 10.0.15063.468 SDK and VS 2017 Update 3.2 (includes fix to code-gen bug hit when building clang with VC++ 2017). Packaging was done on a Windows Server 2016 VM, cleanly created for this purpose. Compiler was packaged up by downloading VS 2017 Update 3.2, from https://www.visualstudio.com/vs/, and then running this command (executable name was different): vs_professional.exe --add Microsoft.VisualStudio.Workload.NativeDesktop --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended --passive Then the Windows 10.0.15063.468 SDK installer was used to install the Debuggers package. Then the packaging script was run like this: python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.15063.0 VS 2015 builds are still the default so this makes no immediate difference. R=scottmg@chromium.org BUG= 683729 , 727447 Change-Id: Ie615737503ff3a502c6c4df3651c7511db901ffc Reviewed-on: https://chromium-review.googlesource.com/628243 Reviewed-by: Scott Graham <scottmg@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#497477} [modify] https://crrev.com/1a56a637268fb862ea7c4fbfd8fc2d89c4b9eff4/build/vs_toolchain.py
,
Aug 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ec9a1e6ce2708f93ea08f82dd76a1f556310af91 commit ec9a1e6ce2708f93ea08f82dd76a1f556310af91 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Aug 25 23:55:03 2017 Change default VC++ compiler from 2015 to 2017 Now that VC++ 2017 15.3.2 is packaged up we can try again to have VC++ 2017 as the default compiler. This will be reverted at the end of the weekend. If the clang workaround for 727447 is reverted then this will also test whether that code-gen bug is fixed. R=thakis@chromium.org BUG= 683729 , 727447 Change-Id: I74b070a0f8b5c58348309e1bea553136499c6922 Reviewed-on: https://chromium-review.googlesource.com/636325 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#497599} [modify] https://crrev.com/ec9a1e6ce2708f93ea08f82dd76a1f556310af91/build/vs_toolchain.py
,
Aug 27 2017
,
Aug 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/43b6c849b3c49f71261a71fcb40455d0e263c49d commit 43b6c849b3c49f71261a71fcb40455d0e263c49d Author: Bruce Dawson <brucedawson@chromium.org> Date: Mon Aug 28 01:12:50 2017 Revert "Change default VC++ compiler from 2015 to 2017" This reverts commit ec9a1e6ce2708f93ea08f82dd76a1f556310af91. Reason for revert: Weekend testing of VC++ 2017 is complete. A canary was produced (62.0.3197.0) and a bug was found ( crbug.com/759402 ), so it was a worthwhile experiment. Original change's description: > Change default VC++ compiler from 2015 to 2017 > > Now that VC++ 2017 15.3.2 is packaged up we can try again to have VC++ > 2017 as the default compiler. This will be reverted at the end of the > weekend. If the clang workaround for 727447 is reverted then this will > also test whether that code-gen bug is fixed. > > R=thakis@chromium.org > BUG= 683729 , 727447 > > Change-Id: I74b070a0f8b5c58348309e1bea553136499c6922 > Reviewed-on: https://chromium-review.googlesource.com/636325 > Reviewed-by: Nico Weber <thakis@chromium.org> > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Cr-Commit-Position: refs/heads/master@{#497599} TBR=thakis@chromium.org,brucedawson@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 683729 , 727447 Change-Id: I9bef79f3197597fea6009692ec96809ff7ecf560 Reviewed-on: https://chromium-review.googlesource.com/637046 Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#497684} [modify] https://crrev.com/43b6c849b3c49f71261a71fcb40455d0e263c49d/build/vs_toolchain.py
,
Aug 28 2017
Note that https://chromeperf.appspot.com/report?sid=63def557d27e5ca5a15507e81a77624f7374e76f269728a602eecb6496a9d524 shows some nice binary-size savings from VC++ 2017. With nothing else changing the sizes for chrome.dll are: VC++ 2015: 38,261,800 VC++ 2017: 36,731,400 So, a savings of 1,530,400 bytes or 4.0%.
,
Aug 30 2017
crbug.com/760564 is a 7.3% performance regression when reverting back to VC++ 2015, so an improvement under VC++ 2017.
,
Sep 1 2017
Now that bug 759402 is more-or-less fixed (worked around once Angle rolls) the only blocking bug that I am aware of is the PDB size issue tracked in bug 755611 , and there seems to be good progress on that bug. So, we can start talking about switching to VC++ 2017 (pros/cons, including in the context of clang-cl) next week.
,
Sep 6 2017
In addition crbug.com/760180 (size regression when returning to VC++ 2015) showed the following sizes for chrome_child.dll: VC++ 2015: 53,769,200 VC++ 2017: 52,483,100 So, a savings of 1,286,100 bytes or 2.4% for VC++ 2017.
,
Sep 11 2017
I am not aware of any blocking issues for switching to VS 2017. Switching will give us greater conformance, smaller binaries, faster fastlink linking, some speed improvements, and some minor regressions. The one open 'blocked on' issue has been worked around and is only open to track Microsoft shipping an actual fix. I think we should try switching and possibly leave it enabled. I think that switching is compatible with the eventual switch to clang because both compilers give us greater C++ conformance and because we also want the newer header files that come with VS 2017 (part of the conformance improvements). Thoughts? I can put together a switch CL and its then just a matter of deciding when to land it.
,
Sep 11 2017
+1 to switching, I've been using VS2017 for a while now ant it works great (better link time etc).
,
Sep 12 2017
,
Sep 14 2017
I was just CCed on these two bugs. The first is a size regression when switching to VS 2017, and the second is a size regression when switching back: crbug.com/744745: 0.6% regression in sizes at 486999:486999 crbug.com/744746 : 1.5% regression in sizes at 487109:487111 The good news is that the second regression is bigger so that's a net gain, sort of. The first bug shows that 64-bit chrome.dll goes from 51,858,400 to 53,407,200 bytes, and 32-bit mini_installer.exe goes from 42,879,000 to 43,124,700 bytes when going to VS 2017. The second bug shows that 32-bit chrome_child.dll goes from 52,244,000 to 53,051,900 bytes and 64-bit chrome_child.dll goes from 71,249,900 to 71,915,500 bytes when going back to VS 2015. I'm not sure how this correlates with crbug.com/760180 which showed 32-bit chrome.dll and chrome_child.dll getting larger when going back to VS 2017. That is, how can 32-bit mini_installer.exe get bigger when switching to VS 2017 if chrome.dll and chrome_child.dll both get smaller? See https://chromeperf.appspot.com/group_report?rev=486999 for all perf changes from switching to VS 2017.
,
Sep 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8707de2d756841d799483ceff0427e316961f468 commit 8707de2d756841d799483ceff0427e316961f468 Author: Bruce Dawson <brucedawson@chromium.org> Date: Fri Sep 15 23:00:10 2017 Make VS 2017 the default compiler on Windows All known blockers for VS 2017 as the default compiler for Chrome on Windows have been addressed. Switching to VS 2017 will give us: - Better C++ conformance and various bug fixes, especially around constexpr - Faster fastlink links and fixes to linker bugs which can cause incremental linking to fail - Newer STL header files for increased STL conformance - Debugger stability fixes (it is quite possible to debug VS 2015 binaries with VS 2017 but using the same toolchain for both is preferable) Note that many of these benefits apply even in the context of switching to clang - faster links are always good, and increased VS conformance makings switching between VS and clang easier. Test switches to VS 2017 have been done enough times to make us reasonably confident that the switch will go smoothly. If not then it can be easily reverted. If the switch sticks then the documentation pages will need to be updated. Note that the Windows 10 Creators Update SDK will be made required soon after this change. Bug: 683729 Change-Id: I79fdd9e44c6bb7ef25ab6bcb88845ac18e5cf56f Reviewed-on: https://chromium-review.googlesource.com/665637 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Commit-Position: refs/heads/master@{#502421} [modify] https://crrev.com/8707de2d756841d799483ceff0427e316961f468/build/vs_toolchain.py
,
Sep 16 2017
Hey Bruce, just a heads up : this seems to have broken a few dEQP tests again (x64 Release Windows only). No need to revert if you can apply the disable optimization trick again: https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20x64%20dEQP%20Release%20%28NVIDIA%29/builds/2261 dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat2x4_mat2x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat4_mat4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat4_mat4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat3x4_mat3x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat3x4_mat3x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat3x4_mat3x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat4_mat4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat2x4_mat2x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat2x4_mat2x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat3x4_mat3x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat2x4_mat2x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat2x4_mat2x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat4_mat4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat2x4_mat2x4_fragment dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat3x4_mat3x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_highp_mat3x4_mat3x4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_mediump_mat4_mat4_vertex dEQP_GLES3.Default/functional_shaders_matrix_matrixcompmult_dynamic_lowp_mat4_mat4_vertex
,
Sep 16 2017
It looks like the same style of tests but for the ES3 version. I'll see if I can patch it. Will follow up in issue 759402 .
,
Sep 18 2017
Other failures were found on the Win10 Tests x64 bot. These failures were initially hidden because the bot was already failing, but the switch to VS 2017 seemed to cause additional failures. Prior to VS 2017 the failure list looked like: browser_tests renderer_side_navigation_browser_tests Afterwards the list of failures was: browser_tests renderer_side_navigation_browser_tests gfx_unittests headless_browsertests renderer_side_navigation_headless_browsertests media_unittests So, four additional failures. The media_unittests failures were easily reproduced - one of the tests was crashing: [ RUN ] VpxVideoDecoderTest.MemoryPoolAllowsMultipleDisplay [3421/3421] VpxVideoDecoderTest.MemoryPoolAllowsMultipleDisplay (CRASHED) The crash is because vpx_internal_error is called (in VS 2015 and VS 2017) and it calls longjmp and longjmp eventually calls RtlFastFail2, saying: "Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!)" It appears that calling vpx_internal_error is normal, but the crash is new. Reverting while I investigate.
,
Sep 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/eaccacb6302f7b0ea235fd7d1ff3aa7eaf8b20ef commit eaccacb6302f7b0ea235fd7d1ff3aa7eaf8b20ef Author: Bruce Dawson <brucedawson@chromium.org> Date: Mon Sep 18 06:35:37 2017 Revert "Make VS 2017 the default compiler on Windows" This reverts commit 8707de2d756841d799483ceff0427e316961f468. Reason for revert: media_unittests is crashing in vpx_internal_error https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds/15967 Original change's description: > Make VS 2017 the default compiler on Windows > > All known blockers for VS 2017 as the default compiler for Chrome on > Windows have been addressed. Switching to VS 2017 will give us: > > - Better C++ conformance and various bug fixes, especially around > constexpr > - Faster fastlink links and fixes to linker bugs which can cause > incremental linking to fail > - Newer STL header files for increased STL conformance > - Debugger stability fixes (it is quite possible to debug VS 2015 > binaries with VS 2017 but using the same toolchain for both is > preferable) > > Note that many of these benefits apply even in the context of switching > to clang - faster links are always good, and increased VS conformance > makings switching between VS and clang easier. > > Test switches to VS 2017 have been done enough times to make us > reasonably confident that the switch will go smoothly. If not then it > can be easily reverted. If the switch sticks then the documentation > pages will need to be updated. > > Note that the Windows 10 Creators Update SDK will be made required soon > after this change. > > Bug: 683729 > Change-Id: I79fdd9e44c6bb7ef25ab6bcb88845ac18e5cf56f > Reviewed-on: https://chromium-review.googlesource.com/665637 > Commit-Queue: Bruce Dawson <brucedawson@chromium.org> > Reviewed-by: Dirk Pranke <dpranke@chromium.org> > Reviewed-by: Scott Graham <scottmg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#502421} TBR=dpranke@chromium.org,brucedawson@chromium.org,scottmg@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: 683729 Change-Id: Icf40a84f30941980b1c9e038cc4336b057ea10c0 Reviewed-on: https://chromium-review.googlesource.com/670283 Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#502535} [modify] https://crrev.com/eaccacb6302f7b0ea235fd7d1ff3aa7eaf8b20ef/build/vs_toolchain.py
,
Sep 18 2017
,
Sep 19 2017
,
Sep 19 2017
The new failures seen on the switch to VS 2017 on this build: https://build.chromium.org/p/chromium.win/builders/Win10%20Tests%20x64/builds/15967 are: gfx_unittests and media_unittests - covered by crbug.com/766236 headless_browsertests and renderer_side_navigation_headless_browsertests - covered by crbug.com/766884
,
Sep 20 2017
,
Sep 22 2017
,
Sep 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d7af1e3aba05d9839ecffa52585b6e4808212142 commit d7af1e3aba05d9839ecffa52585b6e4808212142 Author: Bruce Dawson <brucedawson@chromium.org> Date: Sat Sep 23 00:35:11 2017 Make VS 2017 the default compiler on Windows All known blockers for VS 2017 as the default compiler for Chrome on Windows have been addressed. Switching to VS 2017 will give us: - Better C++ conformance and various bug fixes, especially around constexpr - Faster fastlink links and fixes to linker bugs which can cause incremental linking to fail - Newer STL header files for increased STL conformance - Debugger stability fixes (it is quite possible to debug VS 2015 binaries with VS 2017 but using the same toolchain for both is preferable) Note that many of these benefits apply even in the context of switching to clang - faster links are always good, and increased VS conformance makings switching between VS and clang easier. Test switches to VS 2017 have been done enough times to make us reasonably confident that the switch will go smoothly. If not then it can be easily reverted. If the switch sticks then the documentation pages will need to be updated. Note that the Windows 10 Creators Update SDK will be made required soon after this change. Bug: 683729 Change-Id: Ib1cd215618983f12f2bdb141211028464ded1175 Reviewed-on: https://chromium-review.googlesource.com/678859 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#503915} [modify] https://crrev.com/d7af1e3aba05d9839ecffa52585b6e4808212142/build/vs_toolchain.py
,
Sep 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dfe573b3621abc60d458ef675580ee3ba25d8de7 commit dfe573b3621abc60d458ef675580ee3ba25d8de7 Author: Bruce Dawson <brucedawson@chromium.org> Date: Thu Sep 28 19:56:06 2017 Require VS 2017 Update 3.2 to build on Windows Last week VS 2017 was made the default compiler on Windows. It didn't take long for a dependency to creep in and now VS 2017 is *required* to build Chrome on Windows. This CL makes this explicit, to avoid confusing error messages, and it requires a particular minimum *version* of VS 2017 in order to avoid compiler bugs that were seen in previous versions. crrev.com/c/678859 was the change that made VS 2017 the default. Bug: 683729 Change-Id: I3db12c0c9d98400077e6bd41afea16d4d071352a Reviewed-on: https://chromium-review.googlesource.com/688746 Reviewed-by: Daniel Bratell <bratell@opera.com> Reviewed-by: Justin Schuh <jschuh@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#505124} [modify] https://crrev.com/dfe573b3621abc60d458ef675580ee3ba25d8de7/base/win/windows_version.cc
,
Sep 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/91958392e61a7859f888a40a858e99377b1bf1e9 commit 91958392e61a7859f888a40a858e99377b1bf1e9 Author: Bruce Dawson <brucedawson@chromium.org> Date: Thu Sep 28 21:03:58 2017 Update Chrome build instructions for Windows Update the instructions to mention that VS 2017 and the 10.0.15063 SDK are required in order to build Chromium. Remove references to VS 2015 and earlier SDKs. Much simpler now! Bug: 683729 Change-Id: Ie101a835eb7fa72a3436e338f089d1efa29c9249 Reviewed-on: https://chromium-review.googlesource.com/688228 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#505153} [modify] https://crrev.com/91958392e61a7859f888a40a858e99377b1bf1e9/docs/windows_build_instructions.md
,
Oct 3 2017
I'm currently investigating crbug.com/770574 which is an alignment bug which appears to have started appearing with VS 2017. The VC++ documentation says that function parameters are not guaranteed to be aligned, VC++ 2017 does align function parameters (up to 32 bytes) in my tests, and I'm not sure exactly where the failure is happening. It sounds like the failure was initially not noticed because the alignment is (probably) correct half the time which is enough for retries to cover it during the switches to VS 2017.
,
Oct 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3051a8821522607ae6fd9dd66fa168019d8891dd commit 3051a8821522607ae6fd9dd66fa168019d8891dd Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue Oct 03 21:41:13 2017 Remove workarounds for VS 2015 and early-VS 2017 bugs Bug: 683729 Change-Id: I407081d16aa83a54f9c5227e77d7806f51ea79d9 Reviewed-on: https://chromium-review.googlesource.com/691141 Reviewed-by: Primiano Tucci <primiano@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#506187} [modify] https://crrev.com/3051a8821522607ae6fd9dd66fa168019d8891dd/base/allocator/allocator_shim_default_dispatch_to_winheap.cc [modify] https://crrev.com/3051a8821522607ae6fd9dd66fa168019d8891dd/mojo/public/cpp/bindings/tests/pickle_unittest.cc
,
Oct 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7295a84e468138d53fc1f2259d737768f52e803c commit 7295a84e468138d53fc1f2259d737768f52e803c Author: Tomasz Moniuszko <tmoniuszko@opera.com> Date: Thu Oct 05 06:37:35 2017 Generate projects for Visual Studio 2017 by default GN should generate projects for Visual Studio 2017 by default since this is the default compiler now. Bug: 683729 Change-Id: I560983cf4c228a785e0ed2648567c7e0f07584d4 Reviewed-on: https://chromium-review.googlesource.com/700258 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Bruce Dawson <brucedawson@chromium.org> Commit-Queue: Tomasz Moniuszko <tmoniuszko@opera.com> Cr-Commit-Position: refs/heads/master@{#506665} [modify] https://crrev.com/7295a84e468138d53fc1f2259d737768f52e803c/tools/gn/command_gen.cc
,
Oct 5 2017
,
Oct 5 2017
,
Oct 6 2017
All blocking bugs fixed, VS 2017 has been holding steady for two weeks, I'm calling this fixed.
,
Oct 6 2017
This got added to the wrong bug, so adding it here. So far I've seen three performance bugs attributed to the VS 2017 change. I think these are real but I think WontFix is the correct resolution for them. They are: crbug.com/768394 - unimportant test code (closed) crbug.com/771303 - outnumbered by improvements (closed) crbug.com/771307 - outnumbered by improvements (closed)
,
Oct 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0febf3c866810f188fb4122f0d2e3b5cfa030b94 commit 0febf3c866810f188fb4122f0d2e3b5cfa030b94 Author: Bruce Dawson <brucedawson@chromium.org> Date: Sat Oct 07 00:39:08 2017 Change clang-cl version to 1911 (VS 2017 Update 3) Now that Chromium has switched to using and requiring VC++ 2017 for Windows builds it makes sense for clang-cl to simulate VC++ 2017 instead of VC++ 2015. This gets _MSC_VER to be set to 1911 and _MSC_FULL_VER to 191100000. Bug: 683729 Change-Id: Ie9ec7243eafe60a7579b7c55ab05716d5fe7e4ce Reviewed-on: https://chromium-review.googlesource.com/706349 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#507245} [modify] https://crrev.com/0febf3c866810f188fb4122f0d2e3b5cfa030b94/build/config/win/BUILD.gn
,
Oct 10 2017
The following revision refers to this bug: https://swiftshader.googlesource.com/SwiftShader.git/+/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341 commit 8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341 Author: Nicolas Capens <capn@google.com> Date: Tue Oct 10 18:14:35 2017 Upgrade SwiftShader solution and projects to Visual Studio 2017. Chrome now uses Visual Studio 2017 as the default compiler on Windows. To ensure we maintain compatibility during standalone development, we should use VS2017 for SwiftShader as well. The 'Community' edition of Visual Studio 2017 is freely available. Bug chromium:683729 Change-Id: I3ed1edaeb9fa786b575202ba5b9c86faf1daa3c0 Reviewed-on: https://swiftshader-review.googlesource.com/13048 Tested-by: Nicolas Capens <nicolascapens@google.com> Reviewed-by: Alexis Hétu <sugoi@google.com> Reviewed-by: Nicolas Capens <nicolascapens@google.com> [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/SwiftShader.sln [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/D3D8/D3D8.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/D3D9/D3D9.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/compiler/Compiler.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/compiler/preprocessor/preprocessor.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/libEGL/libEGL.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/libGL/libGL.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/libGLES_CM/libGLES_CM.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/OpenGL/libGLESv2/libGLESv2.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/Reactor/Reactor.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/Reactor/Subzero.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/Reactor/SubzeroLLVMDependencies.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/Reactor/SubzeroTest.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/src/SwiftShader/SwiftShader.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/tests/OGLSimpleCube/OGLSimpleCube.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/tests/unittests/unittests.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/include/llvm/intrinsics_gen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Analysis/LLVMAnalysis.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/CodeGen/LLVMCodeGen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/CodeGen/SelectionDAG/LLVMSelectionDAG.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/ExecutionEngine/JIT/LLVMJIT.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/ExecutionEngine/LLVMExecutionEngine.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/MC/LLVMMC.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Support/LLVMSupport.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/TableGen/LLVMTableGen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/LLVMTarget.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/InstPrinter/LLVMX86AsmPrinter.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/LLVMX86CodeGen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/MCTargetDesc/LLVMX86Desc.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/TargetInfo/LLVMX86Info.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/Utils/LLVMX86Utils.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Target/X86/X86CommonTableGen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Transforms/InstCombine/LLVMInstCombine.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Transforms/Scalar/LLVMScalarOpts.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/Transforms/Utils/LLVMTransformUtils.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/lib/VMCore/LLVMCore.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/LLVM/utils/TableGen/llvm-tblgen.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Examples/Advanced/ChameleonMan/OGLES2/Build/WindowsVC2010/OGLES2ChameleonMan.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Examples/Beginner/01_HelloAPI/OGLES2/Build/WindowsVC2010/OGLES2HelloAPI.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Examples/Beginner/04_BasicTnL/OGLES/Build/WindowsVC2010/OGLESBasicTnL.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Examples/Intermediate/ColourGrading/OGLES3/Build/WindowsVC2010/OGLES3ColourGrading.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Examples/Intermediate/DisplacementMap/OGLES2/Build/WindowsVC2010/OGLES2DisplacementMap.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Tools/OGLES2/Build/WindowsVC2010/OGLES2Tools.vcxproj [modify] https://crrev.com/8c59ccdcf2be0b5a7c6f9dbc38aa1c03dd671341/third_party/PowerVR_SDK/Tools/OGLES3/Build/WindowsVC2010/OGLES3Tools.vcxproj
,
Oct 11 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/dca552efd71db6cdc0bb7b9f46ff8fa1adf513e7 commit dca552efd71db6cdc0bb7b9f46ff8fa1adf513e7 Author: Bruce Dawson <brucedawson@chromium.org> Date: Wed Oct 11 01:18:48 2017 Remove CRLF line ending Somehow the last change got through with a CRLF ending. I thought that was impossible - fixing. Bug: 683729 Change-Id: I7fac0561bfe4daf01c51a53f529b1fd32d93236f Reviewed-on: https://chromium-review.googlesource.com/710678 Reviewed-by: Justin Schuh <jschuh@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#507847} [modify] https://crrev.com/dca552efd71db6cdc0bb7b9f46ff8fa1adf513e7/base/win/windows_version.cc
,
Dec 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cea79358b2c6f2d0d7834f3d153072fbe0bcc1a5 commit cea79358b2c6f2d0d7834f3d153072fbe0bcc1a5 Author: Bruce Dawson <brucedawson@chromium.org> Date: Tue Dec 05 21:09:47 2017 Remove obsolete references to VS 2015 Chrome cannot build with VS 2015 anymore. Having it listed as a supported compiler can lead to confusion for new Chromium developers. This change scrubs inappropriate '2015' references from the Chromium repo. Bug: 683729 Change-Id: I2e02bc31ae8fd57a31ac65f1bb8a45eb5a5cd433 Reviewed-on: https://chromium-review.googlesource.com/807526 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by: Scott Graham <scottmg@chromium.org> Cr-Commit-Position: refs/heads/master@{#521829} [modify] https://crrev.com/cea79358b2c6f2d0d7834f3d153072fbe0bcc1a5/build/vs_toolchain.py [modify] https://crrev.com/cea79358b2c6f2d0d7834f3d153072fbe0bcc1a5/build/win/merge_pgc_files.py
,
Dec 12 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c851ab862aaf3d893863cf5a6150d8bf0a22e52a commit c851ab862aaf3d893863cf5a6150d8bf0a22e52a Author: Eric Roman <eroman@chromium.org> Date: Tue Dec 12 00:49:52 2017 Update gn documentation for --ide=vs. The default is VS 2017 as of 7295a84e468138d53fc1f2259d737768f52e803c. Bug: 683729 Change-Id: I795011162e0a9f6c39af799b50d32587b0baed76 Reviewed-on: https://chromium-review.googlesource.com/821211 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Eric Roman <eroman@chromium.org> Cr-Commit-Position: refs/heads/master@{#523274} [modify] https://crrev.com/c851ab862aaf3d893863cf5a6150d8bf0a22e52a/tools/gn/command_gen.cc [modify] https://crrev.com/c851ab862aaf3d893863cf5a6150d8bf0a22e52a/tools/gn/docs/reference.md
Showing comments 83 - 182
of 182
Older ›
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
