A big test was disabled due to one module failing to verify with
sil-opt. This PR reenables the test for all other modules to catch
errors while this particular problem is being looked into.
rdar://143050566
SIL/verify_all_overlays.py is passing `-F ""` on non-Apple platforms. Swift handles that kind of, but clang doesn't support it and will get argument parsing errors. It's a pathological case, so fix SIL/verify_all_overlays.py to not do that, but also add a failsafe in ClangImporter to not pass on empty paths.
rdar://142441042
The Runtime module requires C++ interop enabled, because that's
the only way to robustly fix things so that it is able to declare various
types and constants without clashing with system headers.
To make this work, we also need to add a missing invocation to sil-opt to
make it pick the correct C++ runtime library.
rdar://143050566
Move the backtracing code into a new Runtime module. This means renaming
the Swift Runtime's CMake target because otherwise there will be a name
clash.
rdar://124913332
Don't delete the OS declaration of `exit` because the concurrency shims aren't always imported, and so the shim declaration might not always be available.
Don't override the OS declaration of `exit` in the concurrency shims since we can't just delete the OS one. Instead, set up internal shims just for building Concurrency that forward declares `exit`.
The `_Backtracing` module has a number of private implementation only
imports that aren't used outside of the module and that don't require
any additional libraries (hence they aren't relevant to the outside
world). `verify_all_overlays.py` needs to know about these when it
does its test, because it loadas the module as the main module, which
results in implementation only imports being required instead of
ignored.
rdar://110261712
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
Otherwise certain modules don't import correctly when built against an
Apple-internal SDK. Should have no effect when using the public SDK,
but we try to minimize divergence between the public and
Apple-internal test suites.
rdar://problem/48513002
This turns out to be the only problem on iOS and tvOS. Oops! macOS
still has some actual failing overlays as tracked by SR-9847.
(We should also add this search path to
ParseableInterface/verify_all_overlays.py.)
rdar://problem/48458622
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
