This fixes a deserialization failure in the compiler that occurred while loading the CxxStdlib overlay module:
```
Cross-reference to module 'Swift'
... Optional
... some
... with type <τ_0_0 where τ_0_0 : ~Copyable, τ_0_0 : ~Escapable> (Optional<τ_0_0>.Type) -> (τ_0_0) -> Optional<τ_0_0>
```
This was happening because the overlays were built against a different version of the Swift stdlib than is being used. The compiler is able to rebuild the Cxx and CxxStdlib modules from their textual interfaces. Let's use that feature unconditionally in production toolchains to avoid this kind of binary incompatibilities.
rdar://150416863
(cherry picked from commit 16b280862a)
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
(cherry picked from commit 0100104ff7)
A first step towards creating safe overloads for C++ APIs using span
(rdar://139074571).
Note that we need to mark span as owned because it the libc++
implementation was mistakenly recognized as owned and might now rely on
span methods like `data` being renamed as `__dataUnsafe`. We will change
it under a new interop version. But for the time being, we want
consistent behavior across stdlib versions.
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
C++ `operator bool()` is currently imported into Swift as `__convertToBool()`, which shouldn't be used by clients directly.
This adds a new protocol into the C++ stdlib overlay: `CxxConvertibleToBool`, along with an intitializer for `Swift.Bool` taking an instance of `CxxConvertibleToBool`.
rdar://115074954
This adjusts Cxx to be built statically on all platforms including
Windows. The static library support is sufficient to support this
module linking statically on Windows.
This makes it possible to initialize `std::vector` from a Swift Sequence. This also conforms C++ vectors to `ExpressibleByArrayLiteral`, making it possible, for instance, to pass a Swift array to a C++ function that takes a vector of strings as a parameter.
rdar://104826995
With the changes introduced in #65055, the Cxx module will build even
when not building the stdlib as long as
`SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` was set. With the further changes
in #65122 the previous flag is not necessary, and only
`SWIFT_BUILD_STDLIB_CXX_MODULE` (which defaults to `TRUE`) is necessary.
However, `stdlib/public/Cxx` did rely on `StdlibOptions.cmake` to be
include before it, or the functions that build the target libraries will
find a half configured state. `StdlibOptions.cmake` are included in
`stdlib/toolchain`, in `stdlib/` and `StandaloneOverlay.cmake`. Before #65122
it was working just because `stdlib/toolchain` was added just before.
The second changes adds dependencies on the legacy layouts and the clang
headers. The legacy layouts are a dependency only added to the libraries of
the stdlib core (IS_STDLIB_CORE flag). Since enabling that flag also enables
a bunch other stuff, and I am not sure that Cxx should be classified as "core"
anyway, I preferred to add the dependency. The clang headers are another
dependency of the swiftCore, which otherwise causes problems to not find
the compiler headers when building Cxx. This is necessary for builds
that use a previously built compiler to compile the stdlib.
Cxx & CxxStdlib modules are Swift-only, they do not require invoking clang directly.
When building with `SWIFT_INCLUDE_TOOLS=NO`, Clang is not available as a CMake target (see `swift_common_standalone_build_config`).
rdar://107780733
The C++ stdlib overlay binaries now a part of the toolchain, not the OS SDKs. This makes sure that these binaries are built when building the toolchain separately from the stdlib.
rdar://106002094
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::optional` when used from Swift code.
As of now, the overlay adds an initializer of `Swift.Optional` that takes an instance of `CxxOptional` as a parameter.
The C++ stdlib overlay binaries (`libswiftCxx` and `libswiftCxxStdlib`) are now a part of the toolchain, not the OS SDKs. This makes sure that `libswiftCxx` is built when building the toolchain separately from the stdlib.
rdar://105799283
Since the unsafe iterator types are now used throughout the overlay, not just by `CxxSequence` and `CxxRandomAccessCollection`, let's move them to a separate file.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::map` and `std::unordered_map` when used from Swift code.
As of now, `CxxDictionary` adds a subscript with an optional return type that mimics the subscript of `Swift.Dictionary`.
Similar to https://github.com/apple/swift/pull/63244.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::set`, `std::unordered_set` and `std::multiset` when used from Swift code.
As of now, `CxxSet` adds a `contains` function to C++ sets.
C++ stdlib set types are automatically conformed to `CxxSet`: `std::set`, `unordered_set`, `std::multiset`. Custom user types are not conformed to `CxxSet` automatically: while a custom type might have an interface similar to `std::set`, the semantics might differ, and adding a conformance would cause confusion.
Instead of a dynamic `swiftCxx.dylib` library, let's build a static library to simplify backdeployment and reduce potential compatibility difficulties in the future.
This also adds `NO_LINK_NAME` option to `add_swift_target_library` to prevent the CMake scripts from passing `-module-link-name` to swiftc when building a given module. This fixes linker errors, which would otherwise occur due to the force-load symbol name (`_swift_FORCE_LOAD_$xyz`) being emitted for the libraries that are now static (`swiftCxx`, `swiftstd`).
Since we don't automatically conform C++ non-random-access collections to `Swift.Sequence` anymore for performance reasons, we need an alternative way to access the elements of a C++ sequence from Swift.
This allows explicitly converting a C++ sequence to a Swift Array/Set.
This helps to bridge C++ random access collections, such as `std::vector` and `std::string`, to Swift by conforming them to `Swift.RandomAccessCollection`
This allows projects that don't want to pull in the entire C++ standard library to use stdlib-independent C++ interop utilities like `CxxSequence`.
This also makes the utilities available on platforms where we don't currently have the `std` overlay available, e.g. Windows.
This change adds basic helper protocols and structs that are going to be used for making C++ sequences and collection safe and Swifty by adding conformances to `Swift.Sequence`, `Swift.Collection`, etc.
This is not meant to be a final design.
Since libstdc++ doesn't come with a Clang modulemap, Swift provides its own modulemap for libstdc++. This change makes the modulemap available while building SwiftCompilerSources.
This change adds a module map for libstdc++, which allows it to be properly imported into Swift as a module. The module map is installed into `usr/lib/swift/linux/{arch}` similarly to `glibc.modulemap`, and is passed to Clang as `-fmodule-map-file`.
That means it is now possible to import std directly from Swift on Linux, when C++ interop is enabled.
The module map currently declares a single `std` module without splitting the headers into submodules. This is going to change in the near future.
rdar://87654514
