Swift has some module maps it overlays on Linux and Windows that groups all of the C standard library headers into a single module. This doesn’t allow clang and C++ headers to layer properly with the OS/SDK modules. clang will set -fbuiltin-headers-in-system-modules as necessary for Apple SDKs, but Swift will need to pass that flag itself when required by its module maps.
Add new APIs libSwiftScan that can be used for cache query and cache
replay. This enables swift-driver or build system to query the cache and
replay the compilation results without invocation swift-frontend for
better scheduling.
Clang does not accept `-x objective-c` with WebAssembly target and it
crashes with "Objective-C support is unimplemented for object file
format" for now. `-enable-objc-interop` can work without the objc
runtime support (which is indicated by `objc_interop` feature), so this
adds a new `objc_codegen` feature to require Objective-C support only
at compile-time.
WASI does not provide any interface to inject dynamic library at
runtime and all stdlib are now always statically linked, so don't
need to inject dynamically.
When we're statically linking the standard library, we need to force
the inclusion of the backtracing code in the runtime, otherwise we don't
get on-crash backtraces.
Also, add a test to make sure that this works.
rdar://115774613
This allows the tests that use libdispatch to find its modulemap, plus add the
libdispatch compilation flags to one test that was missing them and fix one
async test on linux.
Use this to define the macro location rather than the "host" dir (which
is actually for the build and not the host). Furthermore, on Windows,
the build dir is /usr/lib/swift as the host content is in the SDK.
This prepares the tests for Windows.
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
After
05d613ea93
17 tests started to fail on Windows when when the SOURCE_DIR is on a
substitute drive due to the path expansion difference.
This fixes 7 of these tests.
Also, make the analogous change to apple/swift-driver#1372, which gets the
sanitizer tests working on Android again, and remove the lld_lto feature in the
tests, which is now unused.
Tests that use the `%target-swift-emit-module-interface` lit substitution are
designed to test the behavior of the compiler when emitting module interfaces
for resilient libraries. It therefore makes sense to pass `-parse-as-library`
by default for these frontend invocations.
Fixes a few tests that were accidentally depending on parsing source files as
top level code.
This solves deprecation warnings in build-script:
```
DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
```
This change assumes that the minimum version
of Python3 is 3.3, which has `shlex.quote`.
Since our build bots currently use 3.6 as their
Python version, we can't yet use `shlex.join`
to further simplify some of the code using
quote.
tests: configure Wasm runtime selection in `lit.cfg`
Currently `wasmer` is hardcoded as a Wasm runtime for running tests. We should make this configurable to be able to select an arbitrary runtime.
The code of `ScanDependencies.cpp` was creating invalid JSON since #66031
because in the case of having `extraPcmArgs` and `swiftOverlayDependencies`,
but not `bridgingHeader`, a comma will not be added at the end of
`extraPcmArgs`, creating an invalid JSON file. Additionally that same PR
added a trailing comma at the end of the `swiftOverlayDependencies`, which
valid JSON does not allow, but that bug was removed in #66366.
Both problems are, however, present in the 5.9 branch, because #66936
included #66031, but not #66366.
Besides fixing the problem in `ScanDependencies.cpp` I modified every test
that uses `--scan-dependencies` to pass the produced JSON through
Python's `json.tool` in order to validate proper JSON is produced. In
most cases I was able to pipe the output of the tool into `FileCheck`,
but in some cases the validation is done by itself because the checks
depend on the exact format generated by `--scan-dependencies`. In
a couple of tests I added a call to `FileCheck` that seemed to be
missing.
Without these changes, two tests seems to be generating invalid JSON in
my machine:
- `ScanDependencies/local_cache_consistency.swift` (which outputs `Expecting ',' delimiter: line 525 column 11 (char 22799)`)
- `ScanDependencies/placholder_overlay_deps.swift`
zippered.
This also introduces a dependency on new testing tool
llvm-tapi-diff. This allows for a structural difference check on tbd
files.
resolves: rdar://107368040
Unlike `swift-frontend -scan-dependencies` option, when dependency
scanner is used as a library by swift driver, the SwiftScanningService
is shared for multiple driver invocations. It can't keep states (like
common file dependencies) that can change from one invocation to
another.
Instead, the clang/SDK file dependencies are computed from each driver
invocations to avoid out-of-date information when scanning service is
reused.
The test case for a shared Service will be added to swift-driver repo
since there is no tool to test it within swift compiler.
In LLVM unified builds `%swift_obj_root` points to `<LLVM build dir>/tools/swift`,
and folders like `bin`, `lib` and `share` are not under `swift_obj_root`, which
makes some tests fail.
For the cases in which `%swift_obj_root/lib` was used, replace it by
using `%swift-lib-dir` instead. Replicate `%swift-lib-dir` to create
`%swift-bin-dir` and `%swift-share-dir`, and use those instead of
`%swift_obj_root/bin` and `%swift_obj_root/share`.
This alternates work both in Swift build-script builds and also in LLVM
unified builds.
CMake: fix missing `SWIFT_CONCURRENCY_GLOBAL_EXECUTOR` value
`SWIFT_CONCURRENCY_GLOBAL_EXECUTOR` is defined in `stdlib/cmake/modules/StdlibOptions.cmake`, which is not included during the first pass of evaluation of the root `CMakeLists.txt`. It is available on subsequent evaluations after the value is stored in CMake cache. This led to subtle bugs, where `usr/lib/swift_static/linux/static-stdlib-args.lnk` didn't contain certain flags on clean toolchain builds, but did contain them in incremental builds.
Not having these autolinking flags in toolchain builds leads to errors when statically linking executables on Linux.
Additionally, since are trivial tests previously didn't link Dispatch statically, the didn't expose a bug where `%import-static-libdispatch` substitution had a missing value. To fix that I had to update `lit.cfg` and clean up some of the related path computations to infer a correct substitution value.
Resolves some of the errors reported in https://github.com/apple/swift/issues/65097.
Some of the conditions in lit.cfg assume a simulator always targets
Intel, but this is not true after the introduction of Apple Silicon.
Rely instead on run_environment.
Addresses rdar://108751951, rdar://108788348
In some Linux setups, one might need to provide extra arguments to setup
the environment for invocations done during the tests. The Swift
frontend and driver already had a mechanism to provide those arguments
in the shape of `SWIFT_FRONTEND_TEST_OPTIONS` and
`SWIFT_DRIVER_TEST_OPTIONS`. `swift-ide-test` was sadly missing the same
feature, which meant that many tests might fail or tests against the
incorrect environment.
The changes implement the `SWIFT_IDE_TEST_TEST_OPTIONS` mechanism to
cover that gap.
