SuccessChanges

Summary

  1. Merging r311391: ------------------------------------------------------------------------ r311391 | stl_msft | 2017-08-21 15:19:33 -0700 (Mon, 21 Aug 2017) | 28 lines [Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure. This is a reasonably non-intrusive change, which I've verified works for both x86 and x64 DevDiv-internal builds. The idea is to change `bool IsVS2017OrNewer` into a 3-state `ToolsetLayout VSLayout`. Either a build is DevDiv-internal, released VS 2017 or newer, or released VS 2015 or older. When looking at the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`, `"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build. After we get past the directory structure validation, we use this knowledge to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()` uses that. It also knows that DevDiv-internal builds have an `"inc"` subdirectory instead of `"include"`. This may still not be the "right" fix in any sense, but I believe that it's non-intrusive in the sense that if the special directory names aren't found, no codepaths are affected. (`ToolsetLayout::OlderVS` and `ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false` or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`, which are places where Clang cares about VS's directory structure, and the only one that isn't being patched is some logic to deal with cross-compilation. I'm fine with that not working for DevDiv-internal builds for the moment (we typically test the native compilers), so I added a comment. Fixes D36860. ------------------------------------------------------------------------
Revision 311500 by hans:
Merging r311391:
------------------------------------------------------------------------
r311391 | stl_msft | 2017-08-21 15:19:33 -0700 (Mon, 21 Aug 2017) | 28 lines

[Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure.

This is a reasonably non-intrusive change, which I've verified
works for both x86 and x64 DevDiv-internal builds.

The idea is to change `bool IsVS2017OrNewer` into a 3-state
`ToolsetLayout VSLayout`. Either a build is DevDiv-internal,
released VS 2017 or newer, or released VS 2015 or older. When looking at
the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`,
`"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build.

After we get past the directory structure validation, we use this knowledge
to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how
we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()`
uses that. It also knows that DevDiv-internal builds have an `"inc"`
subdirectory instead of `"include"`.

This may still not be the "right" fix in any sense, but I believe that it's
non-intrusive in the sense that if the special directory names aren't found,
no codepaths are affected. (`ToolsetLayout::OlderVS` and
`ToolsetLayout::VS2017OrNewer` correspond to `IsVS2017OrNewer` being `false`
or `true`, respectively.) I searched for all references to `IsVS2017OrNewer`,
which are places where Clang cares about VS's directory structure, and the
only one that isn't being patched is some logic to deal with
cross-compilation. I'm fine with that not working for DevDiv-internal builds
for the moment (we typically test the native compilers), so I added a comment.

Fixes D36860.
------------------------------------------------------------------------
Change TypePath in RepositoryPath in Workspace
The file was modified/cfe/branches/release_50clang.src
The file was modified/cfe/branches/release_50/lib/Driver/ToolChains/MSVC.cppclang.src/lib/Driver/ToolChains/MSVC.cpp
The file was modified/cfe/branches/release_50/lib/Driver/ToolChains/MSVC.hclang.src/lib/Driver/ToolChains/MSVC.h