We need to traverse the module dependency graph and track which modules expose
which other modules' ABIs, while making sure that we don't hit a loop while
trawling through Clang (sub)modules.
Fixes rdar://64993153.
Overlay-overlay dependencies are incorrectly marked indirect when the
downstream overlay's underlying module imports the upstream overlay's
underlying module but the downstream overlay does not explicitly import
the upstream overlay.
This doesn't yet allow including C++ headers on platforms where libc++
isn't the default; see comments in UnixToolChains.cpp for details.
However, it does, for example, allow throwing and catching exceptions in C++
code used through interop, unblocking
https://github.com/apple/swift/pull/30674/files.
The flags (-enable-experimental-cxx-interop and -experimental-cxx-stdlib) carry
"experimental" in the name to emphasize that C++ interop is still an
experimental feature.
Co-authored-by: Michael Forster <forster@google.com>
The driver and any other client that attempts to properly link Swift
code need to know which compatibility libraries should be linked on a
per-target basis. Vend that information as part of -print-target-info.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
Attempt to properly quote the python interpreter path in the lit
configuration. This was quoted in some places but not others. This
attempts to homogenise the path quoting.
Hardlinking to a symlink is not permitted, so use "swift-frontend"
instead of "swift" as the hard-link target.
Also, update one Linux-specific test to check for swift-frontend.
This obviates the need for "-frontend", although we still accept it
for backward compatibility. Switch lit's %target-swift-frontend et al
over to calling swift-frontend.
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.
When compiling against a platform different than the host, like it
happens when testing against Android stdlib from a Linux host, one needs
to use %target-swiftc_driver to setup the tools directory correctly and
the target options, otherwise errors will happen when trying to link a
host targetted file against the destination platform libraries.
Previously the path to covered files in the __LLVM_COV / __llvm_covmap
section were absolute. This made remote builds with coverage information
difficult because all machines would have to have the same build root.
This change uses the values for `-coverage-prefix-map` to remap files in
the coverage info to relative paths. These paths work correctly with
llvm-cov when it is run from the same source directory as the
compilation, or from a different directory using the `-path-equivalence`
argument.
This is analogous to this change in clang https://reviews.llvm.org/D81122
The Swift driver (swift/swiftc) is supposed to always be used with an
accompanying SDK, which it derives from the environment. Our test
infrastructure was clearing out this SDK, making it deviate from the
normal operating environment unnecessarily. Switch to providing the
SDK used for building the standard library, which provides a
more-consistent test environment, and tag the few places in tests
where we have explicit dependencies on "no SDK."
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.
-enable-experimental-private-intransitive-dependencies -> -enable-direct-intramodule-dependencies
-disable-experimental-private-intransitive-dependencies -> -disable-direct-intramodule-dependencies
While we're here, rename DependencyCollector::Mode's constants and clean
up the documentation.
