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
Why are the python reasons for having our code nested in a directory
called ``swift_build_support.swift_build_support/`` instead of simply
``swift_build_support/``? Is that what we really want here?
In a normal swiftless clang build, if it doesnt know CLANG_VERSION_*,
clang's cmake falls back on LLVM_VERSION_*. We pass a CLANG_COMPILER_VERSION
to swift, but it is not necessarily what clang wants to know.
The intention of this CLANG_VERSION_* flag in Clang is to know
what Swift calls clang_user_visible_version. This is the non-specific
version of Clang. For example, clang-900 - this is 9.0.0, while Swift
would like clang_compiler_version to be the specific version that the
driver will print out.
Flag naming!
Fix tests
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.
Today, when you enable ASAN, build-script just reconfigures your normal build
directory to use ASAN. This forces you to recompile LLVM and Swift with ASAN
enabled and then (once you have finished using ASAN) to recompile LLVm/Swift
without ASAN.
By using a different build-directory, one still has to (potentially) recompile
LLVM/Swift, but one's original directory has not become invalidated. Thus when
you switch back to a normal build, one does not have to recompile LLVM and
(potentially) Swift!
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.
There is no reason not to do this (and it is really cheap) and I want to make
some scripts use it with various clang tooling techniques like clang-tidy to
improve code quality. This will ensure that by default people can just use these
scripts without knowing about how things are working under the hood.
* swift_build_support: do not raise exception when capturing shell with optional flag
This fixes one of https://bugs.swift.org/browse/SR-2966 failed tests when testing environment trying to instantiate FreeBSD toolchain on Linux and `sysctl` is not in the PATH
* swift_build_support: fix shell test
The benchmark bot uses this functionality today to run the benchmarks. By
default build-script only uses 3 samples for each test. Given the noise on our
systems, this is definitely not sufficient for any sort of robust numbers.
Using this patch, I am going to change the benchmarking bot to take the minimum
of 20 samples as we do for our internal benchmarking. This should help make the
benchmark bot give better data. This will have as a cost cause the bot to take
more time. The testing time issue can be solved down the line by changing to a
protocol where we first do tests with a small number of samples (< 5). Then any
benchmark with a delta > 5% is rerun with 20 samples or perhaps until a
statistical criterion is satisfied. But until that is implemented, this at least
makes the bot useful.
There are other things that need to be changed on the benchmarking bot as well,
namely that it should build on a separate machine from which it is running the
benchmarks on. The benchmarking machine should be quiet and not have any work
being done on it. But that is also for another time.
