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.
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.
