Rather than only emitting the target triple, provide additional
information about that particular target, including the module triple
(i.e., what file names will be used for Swift modules for that
triple), the runtime compatibility version if there is one, and
whether linking with rpaths is required for the standard library and
other libraries shipped with Swift. Encode this as JSON so we can
extend it in the future. For now, it looks like this:
```
{
"target": {
"triple": "arm64-apple-ios12.0",
"moduleTriple": "arm64-apple-ios",
"swiftRuntimeCompatibilityVersion": "5.0",
"librariesRequireRPath": true
}
}
```
Which you can deserialize into a TargetInfo instance as defined below:
```
struct Target: Codable {
/// The target triple.
var triple: String
/// The triple used for module file names.
var moduleTriple: String
/// If this platform provides the Swift runtime, the Swift language
version
/// with which that runtime is compatible.
var swiftRuntimeCompatibilityVersion: String?
/// Whether linking against the Swift libraries requires the use of
rpaths.
var librariesRequireRPath: Bool
}
struct TargetInfo: Codable {
var target: Target
}
```
Implements rdar://problem/47095159.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
Add a -print-target-triple command line option to the Swift frontend
and driver to allow other tools (e.g., SwiftPM) to query the host
triple as it is understood by the Swift compiler. This follows the
precedent set by Clang. Implements rdar://problem/57434967.
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`.
This is a first version of cross module optimization (CMO).
The basic idea for CMO is to use the existing library evolution compiler features, but in an automated way. A new SIL module pass "annotates" functions and types with @inlinable and @usableFromInline. This results in functions being serialized into the swiftmodule file and thus available for optimizations in client modules.
The annotation is done with a worklist-algorithm, starting from public functions and continuing with entities which are used from already selected functions. A heuristic performs a preselection on which functions to consider - currently just generic functions are selected.
The serializer then writes annotated functions (including function bodies) into the swiftmodule file of the compiled module. Client modules are able to de-serialize such functions from their imported modules and use them for optimiations, like generic specialization.
The optimization is gated by a new compiler option -cross-module-optimization (also available in the swift driver).
By default this option is off. Without turning the option on, this change is (almost) a NFC.
rdar://problem/22591518
