autolink-extract is needed on ELF (and windows-cygnus). However, WASM
also has gone down this path and did not actually indicate that it
needed the autolink extract handling. Extract the handling check into a
variable which helps readability.
Add various target-specific and compiler-determined paths to the output
of `-print-target-info`, such as the runtime resource path, SDK path, and
runtime library paths.
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.
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.
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.
The new option `-sanitize-recover=` takes a list of sanitizers that
recovery instrumentation should be enabled for. Currently we only
support it for Address Sanitizer.
If the option is not specified then the generated instrumentation does
not allow error recovery.
This option mirrors the `-fsanitize-recover=` option of Clang.
We don't enable recoverable instrumentation by default because it may
lead to code size blow up (control flow has to be resumable).
The motivation behind this change is that today, setting
`ASAN_OPTIONS=halt_on_error=0` at runtime doesn't always work. If you
compile without the `-sanitize-recover=address` option (equivalent to
the current behavior of the swift compiler) then the generated
instrumentation doesn't allow for error recovery. What this means is
that if you set `ASAN_OPTIONS=halt_on_error=0` at runtime and if an ASan
issue is caught via instrumentation then the process will always halt
regardless of how `halt_on_error` is set. However, if ASan catches an
issue via one of its interceptors (e.g. memcpy) then `the halt_on_error`
runtime option is respected.
With `-sanitize-recover=address` the generated instrumentation allows
for error recovery which means that the `halt_on_error` runtime option
is also respected when the ASan issue is caught by instrumentation.
ASan's default for `halt_on_error` is true which means this issue only
effects people who choose to not use the default behavior.
rdar://problem/56346688
This directory should be excluded during installation since the content is only
used for local development. swiftsourceinfo file is currently emitted to this directory.
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
On targets which support COMDAT (PE/COFF, ELF), use that to relax the
constraints on the emission of `-force-autolink-symbol` so that it is
possible to use that with `-incremental`.
Add a new action, LoadModuleJobAction, that the driver can use to schedule a
load of a given module before we fan out and invoke the frontend multiple
times. This gives the module interface loader a chance to compile it from a
module interface before we start with parallel invocations, avoiding starting
potentially dozens of redundant compiles of a large module. Start by using this
on the standard library.
Quick fix for rdar://52839445
This commit also includes cases where user uses -Fsystem and when path
ends in ".framework/"
(cherry picked from commit a5d9750a9d25441517f3bec97488f57d1bb4b03f)
