Repair the VS2017 build after #28543. It would fail to convert the
dependency set's keys into a vector of StringRefs:
```
error C2678: binary '*': no operator found which takes a left-hand operand of type 'const _Iter' (or there is no acceptable conversion)
with [
_Iter=llvm::StringMapKeyIterator<char>
]
C:\agent\_work\2\s\toolchain\llvm\include\llvm/ADT/StringMap.h(549): note: could be 'llvm::StringRef &llvm::StringMapKeyIterator<ValueTy>::operator *(void)'
with
[
ValueTy=char
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\xmemory(217): note: while trying to match the argument list '(const _Iter)'
with
[
_Iter=llvm::StringMapKeyIterator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\vector(1823): note: see reference to function template instantiation '_FwdIt *std::_Uninitialized_copy<_Iter,llvm::StringRef*,std::allocator<_Ty>>(const _InIt,const _InIt,_FwdIt,_Alloc &)' being compiled
with
[
_FwdIt=llvm::StringRef *,
_Iter=llvm::StringMapKeyIterator<char>,
_Ty=llvm::StringRef,
_InIt=llvm::StringMapKeyIterator<char>,
_Alloc=std::allocator<llvm::StringRef>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\vector(708): note: see reference to function template instantiation 'llvm::StringRef *std::vector<llvm::StringRef,std::allocator<_Ty>>::_Ucopy<_Iter>(_Iter,_Iter,llvm::StringRef *)' being compiled
with
[
_Ty=llvm::StringRef,
_Iter=llvm::StringMapKeyIterator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\vector(708): note: see reference to function template instantiation 'llvm::StringRef *std::vector<llvm::StringRef,std::allocator<_Ty>>::_Ucopy<_Iter>(_Iter,_Iter,llvm::StringRef *)' being compiled
with
[
_Ty=llvm::StringRef,
_Iter=llvm::StringMapKeyIterator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\vector(723): note: see reference to function template instantiation 'void std::vector<llvm::StringRef,std::allocator<_Ty>>::_Range_construct_or_tidy<_Iter>(_Iter,_Iter,std::forward_iterator_tag)' being compiled
with
[
_Ty=llvm::StringRef,
_Iter=llvm::StringMapKeyIterator<char>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\vector(723): note: see reference to function template instantiation 'void std::vector<llvm::StringRef,std::allocator<_Ty>>::_Range_construct_or_tidy<_Iter>(_Iter,_Iter,std::forward_iterator_tag)' being compiled
with
[
_Ty=llvm::StringRef,
_Iter=llvm::StringMapKeyIterator<char>
]
C:\agent\_work\2\s\toolchain\swift\lib\Driver\Compilation.cpp(1571): note: see reference to function template instantiation 'std::vector<llvm::StringRef,std::allocator<_Ty>>::vector<IteratorT,void>(_Iter,_Iter,const _Alloc &)' being compiled
with
[
_Ty=llvm::StringRef,
IteratorT=llvm::StringMapKeyIterator<char>,
_Iter=llvm::StringMapKeyIterator<char>,
_Alloc=std::allocator<llvm::StringRef>
]
C:\agent\_work\2\s\toolchain\swift\lib\Driver\Compilation.cpp(1571): note: see reference to function template instantiation 'std::vector<llvm::StringRef,std::allocator<_Ty>>::vector<IteratorT,void>(_Iter,_Iter,const _Alloc &)' being compiled
with
[
_Ty=llvm::StringRef,
IteratorT=llvm::StringMapKeyIterator<char>,
_Iter=llvm::StringMapKeyIterator<char>,
_Alloc=std::allocator<llvm::StringRef>
]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\xmemory(217): error C2100: illegal indirection
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\\include\xmemory(217): error C2062: type 'unknown-type' unexpected
```
Attempt to make it more explicit with a `std::copy`.
Frontend outputs source-as-compiled, and source-ranges file with function body ranges and ranges that were unparsed in secondaries.
Driver computes diffs for each source file. If diffs are in function bodies, only recompiles that one file. Else if diffs are in what another file did not parse, then the other file need not be rebuilt.
Two places in Driver are creating temporary files at a point in the
process where failure is not expected. We should do something better
about this, but meanwhile harmonize their failures and include a
little more info.
Filed https://bugs.swift.org/browse/SR-11541 to improve this.
Windows requires a handle to get memory usage, so do a slight refactor
to collect the child's memory usage as it exits instead of as the parent
is cleaning up.
