Support: unlock Windows API support, switch to Windows 10 RS1+ APIs

This addresses a small window of in-atomicity in the rename support for
Windows.  IF the ClangImporter is stressed sufficiently, it can run
afoul of the small window of opportunity where the destination file will
not exist.  This causes the `LockFileManger` to improperly handle file
locking for the module compilation resulting in spurious failures as the
file is failed to be read after writing due to multiple processes
overwriting the file and exposing that window constantly to the
scheduled processes when building with a `-num-threads` > 1 for the
Swift driver.

The implementation of `llvm::sys::fs::rename` was changed in SVN r315079
(80e31f1) which even explicitly
identifies the issue:

~~~
This implementation is still not fully POSIX. Specifically in the case
where the destination file is open at the point when rename is called,
there will be a short interval of time during which the destination
file will not exist. It isn't clear whether it is possible to avoid
this using the Windows API.
~~~

Special thanks to Ben Barham for the discussions and help with analyzing
logging to track down this issue!

While this should certainly be upstream'ed, this change is more
intrusive than what would be comfortable to send upstream for immediate
merging.  This aligns the minimum SDK version on non-MinGW builds to the
maximum version supported by the SDK.  This can cause issues if built
against an older SDK and potentially introduce use of APIs which are too
new.  However, this is required to get the updated definitions for the
`FileRenameInfoEx` class which was introduced in Windows 10 RS1.
Unfortunately, the minimum safe level for updating LLVM to is likely
Windows 8 which is still not new enough for this functionality and there
does not seem to be a good way to dynamically detect the Windows build
number to identify if we are on a host that is running RS1 or newer.
For the moment, this will allow increased stability on the Windows
compiler for Swift, and we can look into upstreaming a variant of this
subsequently.

Author: compnerd

llvm/include/llvm/Support/Windows/WindowsSupport.h

@@ -21,13 +21,16 @@
 #ifndef LLVM_SUPPORT_WINDOWSSUPPORT_H
 #define LLVM_SUPPORT_WINDOWSSUPPORT_H
 
+#if defined(__MINGW32__)
 // mingw-w64 tends to define it as 0x0502 in its headers.
 #undef _WIN32_WINNT
 #undef _WIN32_IE
 
 // Require at least Windows 7 API.
 #define _WIN32_WINNT 0x0601
 #define _WIN32_IE    0x0800 // MinGW at it again. FIXME: verify if still needed.
+#endif
+
 #define WIN32_LEAN_AND_MEAN
 #ifndef NOMINMAX
 #define NOMINMAX

llvm/lib/Support/Windows/Path.inc

@@ -465,13 +465,14 @@ static std::error_code rename_internal(HANDLE FromHandle, const Twine &To,
                                   (ToWide.size() * sizeof(wchar_t)));
   FILE_RENAME_INFO &RenameInfo =
       *reinterpret_cast<FILE_RENAME_INFO *>(RenameInfoBuf.data());
-  RenameInfo.ReplaceIfExists = ReplaceIfExists;
+  RenameInfo.Flags = FILE_RENAME_FLAG_POSIX_SEMANTICS
+                   | (ReplaceIfExists ? FILE_RENAME_FLAG_REPLACE_IF_EXISTS : 0);
   RenameInfo.RootDirectory = 0;
   RenameInfo.FileNameLength = ToWide.size() * sizeof(wchar_t);
   std::copy(ToWide.begin(), ToWide.end(), &RenameInfo.FileName[0]);
 
   SetLastError(ERROR_SUCCESS);
-  if (!SetFileInformationByHandle(FromHandle, FileRenameInfo, &RenameInfo,
+  if (!SetFileInformationByHandle(FromHandle, FileRenameInfoEx, &RenameInfo,
                                   RenameInfoBuf.size())) {
     unsigned Error = GetLastError();
     if (Error == ERROR_SUCCESS)