This only enables the swift compiler (not its output) to be used with leaks
sanitizer on linux.
Some important notes: On Linux, right now we are not completely leak clean. I
was only able to get a -Onone build of the stdlib without triggering lsan (I was
unable to run the optimizer and the tests successfully). Additionally even at
-Onone, I had to suppress some leaks in the driver. The point of this though is
to prevent any further -Onone leaks from being committed to the tree since
-Onone leaks that are not bounded (unlike the driver bugs) could cause SourceKit
to leak memory. Since SourceKit is a long running process... such a type of leak
would be bad.
rdar://32876901
In the past if one wanted to be able to develop using multiple swift repos, one
was often stymied by build-script always using build-script-impl from the swift
directory. This includes the case where one invokes the build-script from a
hypothetical directory called swift-2.
On Darwin platforms, the Swift build scripts generally use "xcrun" to
locate various tools, and the build-script's darwin-xcrun-toolchain option
is specified to xcrun. However, with the change to use the just-built clang
to build the runtime (PR #6112), there was an issue with the linker. Clang
normally tries to run the linker from the same directory as the clang
binary, but when there isn't one, it falls back on /usr/bin/ld, which is
just an xcrun-like wrapper. Since there is no way to specify an explicit
toolchain option in that case, set TOOLCHAINS in the environment to
make it use the linker from the specified toolchain.
rdar://problem/30709330
Fix the mocked output files of swiftc. Change the lookup of
clang from build-script to build-script-impl like all the other
commands. Pass more args to LLVM. Fix swiftenv creation. Fix unit tests.
The reason this patch works is that build-script-impl gets
all the arguments that are not handled by build-script.
* Add --ios-all etc with a helpful error
message for those who think it exists.
* Reject --ios --host-test early to avoid a cryptic
"build target does not exist" error much later.
build-script-impl assumes ICU is located at
```
LIBICU_SOURCE_DIR="${WORKSPACE}/icu"
```
However, build-script would try to set it to
```
<path-to-workspace>/libicu"
```
This is wrong, so fix it
Some cmark CMake stuff changed recently and the default rules
we have in the Python build script code doesn't behave correctly
anymore, likely because it was relying on incorrect settings.
Now, by default, if the cmark build type isn't specified, it will
follow Swift's. If we don't do this, Xcode builds are broken, and
building with Xcode is important.
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
Adds a three second delay when the `-c` or `--clean` options are
given to utils/build-script, providing a chance to cancel the build
before the existing build folder is removed.
This continues the workaround from 7213a4d8. We should still get a better
solution that does not hardcode the LLVM version like this. That is
tracked by rdar://problem/28801735
