The iOS/watchOS/tvOS deployment targets for Cxx and CxxStdlib binaries got unintentionally bumped in b87b263.
This reverts the deployment targets to the older versions.
rdar://140823785 / resolves https://github.com/swiftlang/swift/issues/77909
If a Swift module built with library evolution enabled is an overlay of a C++ module, allow referring to the non-resilient C++ symbols from the Swift code.
Overlays are usually built and shipped along with the C/C++ modules, so library evolution is less of a concern there. A developer providing a Swift overlay for a C++ library would expect to be able to refer to the symbols from the C++ library within the overlay.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
In certain versions of libstdc++, `std::hash<std::string>` defines `operator()` in a base class. It looks like Swift is not correctly deserializing an inherited `operator()` for inlinable functions. This change sidesteps the issue by moving the call to `callAsFunction`/`operator()` to the C++ shim layer.
rdar://140358388
Prior to throwing, Swift emits a call to `swift_willThrow(Typed)`,
which allows various diagnostic tools (such as debuggers and testing
libraries) to intercept errors at the point where they are initially
thrown.
Since `swift_willThrow(Typed)` can be hooked by arbitrary code at
runtime, there is no way for it to meet performance constraints like
@_noLocks or @_noAllocation. Therefore, in a function that has those
performance constraints specified, disable emission of the call to
`swift_willThrow(Typed)`.
Fixes rdar://140230684.
The change in 269fc941 turned out not to be enough to solve linker errors when using the CxxStdlib overlay with a non-default C++ stdlib.
In addition to `@inlinable`, the Swift functions in the overlay need to be `@_alwaysEmitIntoClient` to prevent Swift from trying to link a program that uses libc++ on Linux against the CxxStdlib binary shipped in the toolchain.
rdar://138838506
This is a requirement for being able to use the CxxStdlib overlay with a C++ standard library which is not the platform default, specifically libc++ on Linux.
The module would get rebuilt from its textual interface (`CxxStdlib.swiftinterface`) by the compiler whenever a custom C++ stdlib is used. Since the mangled names of C++ stdlib symbols differ across implementations (libc++ vs libstdc++), a Swift program that uses these overlay functions would fail to link, unless the definitions of these functions are available.
rdar://138838506
The Span interface requires this. It needs to be able to create dependencies on
UBP values without creating extra temporary copies.
This is only a temporary workaround for:
rdar://140291657 (ASTPrinter: print synthesized conformances on the type
definition, not as an extension)
Until that ASTPrinter bug is fixed, .swiftinterface files drop BitwiseCopyable
conformance on types that have conditionally ~Copyable generic parameters.
Without this fix, the standard library source will break with shortly upcoming
compiler toolchain.
Never explicitly copy a pointer before passing it to an argument that is the
source of a lifetime dependency on the function's return value. That will always
raise a diagnostic error: depending on a temporary value is not the same as
depending on a variable. A temporary value's scope is only the current expression.
Also avoid using ownership modifiers for UnsafePointer. We don't want to treat
them like noncopyable types. They are simply values. Treating them like
noncopyable types creates a lot of overhead in the representation, which is
likely to interfere with diagnostics and optimization.
Without this, supported old compilers which don't recognize LifetimeDependence feature but
recognize the NonEscapableTypes feature will run into lifetime dependence inference errors
on the implicit initializer generated for the stdlib's swiftinterface
It was already supposed to be enabled, but I forgot to update the CMake when I
renamed the feature from ExtensionImportVisibility to MemberImportVisibility.
However, leave it disabled on the CxxStdlib module since the C++ standard
library's modularization varies a lot by platform, making it difficult to add
the right conditional imports.
This fixes incremental builds of the overlay.
The CxxStdlib overlay re-exports the entire C++ standard library, which has headers that transitively include Clang builtin headers, bringing in the _Builtin_float module.
rdar://140036608
Due to the ordering of our build system, we may encounter a race when building standard library variants using tools produced by Swift's 'tools' CMake build.
As a workaround, for now, ensure that the compiler building standard library variants does not rely on libSwiftScan built as part of 'tools'.
Add a new bits/ header to the Android overlay, include runtime libraries that are
auto-extracted and listed many times to the list of libraries to be de-duplicated,
enable a C++ interop test that's working again, and update the doc with new
libraries that need to be available to run a simple executable.
