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.
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.
Add `-no-toolchain-stdlib-rpath` flag: the negative version of
`-toolchain-stdlib-rpath`.
Make `-no-toolchain-stdlib-rpath` be the default: use `/usr/lib/swift` as
default RPATH on Darwin platforms instead of toolchain standard library.
Adapted from https://github.com/apple/swift/pull/27206.
tensorflow branch requires the opposite default (use toolchain standard
library as RPATH) because some stdlib modules like TensorFlow do not exist in
`/usr/lib/swift`.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
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`.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This flag adds diagnostic names to the end of their messages, e.g. 'error: cannot convert value of type '[Any]' to specified type '[Int]' [cannot_convert_initializer_value]'. It's intended to be used for debugging purposes when working on the compiler.
Currently we only support building for android armv7, arm64, x86,
x86_64. In the future, if support for MIPS and MIPS64 is added, we
should normalise those as well. This is needed to support compilation
against modern NDKs.
The backwards-deployment install name trickery we're using doesn't
handle "patch" components in version numbers, so we still need to
provide an rpath even when deploying to macOS 10.14.4.
Use `clang` rather than `clang++` as the linker driver. This ensures
that we do not force a C++ runtime on the general code. This is fine
for now as C++ interop is not yet available for Swift. This prevents
the accidental mix-and-match of various C++ runtimes. This can cause
problems on platforms like android where `libstdc++` is an unsupported
runtime but is generally the default for Linux platforms.
The option -enable-anonymous-context-mangled-names prevents stripping of dead metadata to improve debuggability.
But with optimizations enabled, we do a lot of dead code stripping which affects debuggability anyway.
rdar://problem/48123944
