Many places on the testing scripts for Android have the ARMv7
architecture hardcoded. Modify all those instances to support both ARMv7
and AArch64.
Besides the paths being modified depending on the architecture, the
script is also modified to adapt to NDK beyond r14, where the headers
are not under the SDK root, but under a unified sysroot. Two new include
paths are passed to the compiler invocations (one the general one, one
the architecture specific one).
In order to link correctly, the -tools-directory is passed to the Swift
compiler invocation. In order to use a modern linker, the selected
linker in the CMake script is written in the lit.site.cfg.in files. The
system will prefer lld, but will fallback to gold. Plain ld will not be
used, since it cannot link correctly the binaries.
There's a new CMake variable named SWIFT_ANDROID_${ARCH}_ICU_DATA that
should point to libicudataswift.so for each architecture. This part of
ICU is necessary while running the test in the host, so it needs to be
uploaded. Since it is normally side by side with other ICU products, the
linker was finding it for free.
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
CMake defaults to using a special <package>_DIR for finding packages.
Prefer this to import the CMake package for LLVM/Clang/Swift rather than
custom paths.
Add a shared library with a C API that provides access to the syntactic parser with callbacks for the inference of raw syntax nodes.
This is primarily intended to be used by SwiftSyntax to speed-up source code parsing for it.
check-llvm and check-clang have llvm-test-depends and
clang-test-depends targets which build all dependencies but doesn't run
the tests. Add similar target for check-swift. This allows me to easily
cross-compile the tests on a different system and then run on a matching
machine later.
We should have the LLVM build which provides most of the tools that we need.
`strings` is amongst them. Add a new `llvm-strings` substitution from lit and
use that instead of `strings`. This helps with Windows which does not have a
`strings` tool.
I added a test to make sure that this utility continued to work as expected...
but I forgot to add the utility as a dependency of the test... *doh*.
Thanks to the buildczar Slava for catching this. All hail the mighty buildczar!
- Re-enable the use of folders with the USE_FOLDER setting. This got
lost a while ago when we stopped including LLVM's top-level
CMakeLists.txt.
- Put a bunch of new targets into folders.
Should not affect the built product and definitely shouldn't affect
anyone not building with Xcode (or MSVC, I guess).
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
Stress tests are, by definition, stressful. They intentionally burn a
lot of resources by using randomness to hopefully surface state machine
bugs. Additionally, many stress tests are multi-threaded these days and
they may attempt to use all of the available CPUs to better uncover
bugs. In isolation, this is not a problem, but the test suite as a whole
assumes that individual tests are single threaded and therefore running
multiple stress tests at once can quickly spiral out of control.
This change formalizes stress tests and then treats them like long
tests, i.e. tested via 'check-swift-all' and otherwise opt-in.
Finally, with this change, the CI build bots might need to change if
they are still only testing 'validation' instead of all of the tests.
I see three options:
1) Run all of the tests. -- There are very few long tests left these
days, and the additional costs seems small relative to the cost of
the whole validation test suite before this change.
2) Continue checking 'validation', now sans stress tests.
3) Check 'validation', *then* the stress tests. If the former doesn't
pass, then there is no point in the latter, and by running the stress
tests separately, they stand a better chance of uncovering bugs and
not overwhelming build bot resources.
This is needed to support cross-compilation on targets which do not
support FAT binaries (i.e. non-MachO targets). The primary user of this
functionality right now is Windows, but this support is needed for Linux
and android as well.
This change leaves in place the use of -m*-version-min options, but
fixes the -target options to match. We can eventually remove the use of
the -m*-version-min options after everyone has moved to build with
versions of Clang that correctly handle the deployment version in the
-target option.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
Previously, we were just running ObjCARCContract when codegening. This is out of
character with the rest of the LLVM passes in Swift, namely that after these
have run, an IR pass no longer contains any compiler intrinsics. This can be
seen by SwiftARCContract running in the -O pipeline.
This commit harmonizes the behavior here.
For testing purposes, I added a flag that disables the running of
ObjCARCContract for testing purposes.
rdar://34824507
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
Array tests take longer on the simulator and constantly time out.
The proper solution would be to split the Arrays.swift.gyb into
multiple, though.
<rdar://problem/30250367>
This enables one to dump the various passpipelines in a yaml format. Other
pretty print formats can be added in the future as well if desired. Its intended
usage is to provide a source of pass pipeline information for external python
bug-reducing tools. By integrating this as a compiler-tool, we are guaranteed to
never have to update any of these tools in the face of passpipeline changes.
...if the Python 'psutil' module is installed.
We have no individual tests that take longer than 20 minutes, and
having lit provide the timeout will be a better experience than having
a buildbot kill the whole job.
The three included Python scripts work together to generate a sqlite3
database containing mappings of all covered Swift source code regions to
the specific tests that cover them.
Additionally, build-script support is included for utilizing the
coverage database to prioritize tests covering changes in the Swift
repository.
