The reason to do this is that:
1. We already have a separate leaks bot.
2. We are not leaks clean at -O, but are ASAN clean at -O.
It doesn't make sense to limit our ability to verify that on Linux, we stay ASAN
clean at -O since we are not leaks clean at -O. Once we get leaks clean at -O,
we should create a separate bot.
rdar://31276806
* Moved argument-defaults logic that should be determined outside the actual parser back into the build-script. This logic will be relocated again at a later date to a more suitable module with testing.
* Moved test-paths argument default logic into build-script until it can find a better home in the future.
* Removed old default value for stdlib_deployment_targets from the expected options.
I recently broke the out of tree build by mistake [its fixed now ; )]. This
inspired me to make it easy to test this behavior by adding support to
build-script/cmake/etc for running an external benchmark build via
AddExternalProjects.
Now I can just call build-script with --build-external-benchmarks and thats it!
It should just work! It already helped me to avoid breaking the external build
twice!
I hope that eventually we get this on a bot to make sure it keeps working [or
even added to the smoke tests ; )].
*NOTE* This is disabled by default so it will not affect normal builds.
*NOTE* This just builds the external benchmarks. There is an rpath issue that
prevents you from running them (the benchmarks have the rpath set as if they are
next to the stdlib, but they are not. This can be fixed in a few different ways,
but I do not have time to finish implementing it = (. But this commit is a good
first step and at least detects build errors.
Sometimes it's useful to be able to run tests located in specific
directories and/or files, let's enable this in `utils/build-script`
using `--test-paths` option which accepts a list of viable test locations.
Resolves: rdar://problem/32004487
* Added new OptionalTrueAction and OptionalFalseAction classes to the arguments module.
* Fixed missing return statement in help-test generator.
* Renamed all the `skip_build_*` names to the more simple and affirmative `build_*`.
* Renamed all the `skip_test_*` names to the more simple and affirmative `test_*`.
* Added documentation to the OptionalTrueAction and OptionalFalseAction classes.
* Implemented a (mostly) comprehensive test suite for the argument parser (ab)using metaclasses to dynamically generate unit-tests for each valid argument and preset.
* Fixed failing defaults test for build_ninja.
* Added new HelpOption and IgnoreOption classes for generating tests.
* Converted default value test into individual generated tests which should give better output in case the default tests fail.
* Moved the default argument application logic to the new driver_arguments module in preparation for the larger argument parsing refactor.
* Re-ordered imports in order to satisfy python linter.
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.
