When enabling the early swift driver on Windows, these tests need to be
adjusted for the new driver name that is reported. Add an additional
spelling for the driver to accommodate that for the testsuite.
- #58975 switched many tests from XFAIL on linux to linux-gnu, so seven
fail on the Android CI and two natively. They are now explicitly excluded.
- #39605 added several C++ Interop tests, 11 of which fail on the Android CI,
so disable them for now.
- #42478 removed the @noescape attribute for the non-Android
SIL/clang-function-types tests, so I remove it for Android too.
- My pull #40779 moved the Swift pointer tags to the second byte, so
SILOptimizer/concat_string_literals.64 will need to be updated for that,
disabled it for now.
- Compiler-rt moved the directory in which it places those libraries for
Android, llvm/llvm-project@a68ccba, so lit.cfg is updated for that.
lit.py currently allows any substring of `target_triple` to be used as a
feature in REQUIRES/UNSUPPORTED/XFAIL. This results in various forms of
the OS spread across the tests and is also somewhat confusing since they
aren't actually listed in the available features.
Modify all OS-related features to use the `OS=` version that Swift adds
instead. We can later remove `config.target_triple` so that these don't
the non-OS versions don't work in the first place.
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
Build swift-frontend as the primary Swift binary, and have
swift/swiftc/etc. symlink over to it. This is a step toward allowing
swift-driver to replace the swift and swiftc binaries.
These tests are marked XFAIL or UNSUPPORTED because either the tests:
require libc annotation, require Mach-O support, don't recognize calls to
swift-autolink-extract, requires porting alongside Linux, or rely on simd
which is not present.
Additionally, explicit REQUIRES for tsan/asan/fuzzer are added to some
tests, since OpenBSD does not support these sanitizers or fuzzers, since
it's nicer to mark that with REQUIRES rather than XFAIL.
Clang 8 or 9 seems to have changed from EXE to exe. Allow both
capitalizations (which is not important in Windows) as a workaround.
Maybe in the future we can remove the uppercase option.
Use `clang` rather than `clang++` as the linker driver. This ensures
that we do not force a C++ runtime on the general code. This is fine
for now as C++ interop is not yet available for Swift. This prevents
the accidental mix-and-match of various C++ runtimes. This can cause
problems on platforms like android where `libstdc++` is an unsupported
runtime but is generally the default for Linux platforms.
When providing the -parseable-output flag to the swift compiler, it will provide json formatted messages about tasks that run.
I added some optional usage information in form of user time, system time and maxrss to the output. This can be used by other tools using the compiler to get some insights about time and memory usage.
Since the output does not longer match processes run (in batch mode), I also added a real_pid field so the client could reason about jobs that belong together if needed.
rdar://39798231
This patch adds additional entries to the JSON command messages output
by the Swift compiler. It's now possible to get the command executable
("command_executable") and arguments ("command_arguments") as a single
string and array, respectively, rather than having to parse the
shell-escaped command line provided in the "command" key.
<rdar://problem/35701809>
This test ensures that the file name is not improperly escaped when generating
JSON output.
In order to work around Unicode issues with lit, the swiftc invocation is
actually done in a shell script which the test invokes.
This is follow-up to <rdar://problem/18266570>.
Swift SVN r21899
