This fixes the `no such module 'CxxStdlibShim'` error when building CxxStdlib for armv7k.
For watchOS, armv7k is included in `${SWIFT_SDK_${sdk}_MODULE_ARCHITECTURES}` but not in `${SWIFT_SDK_${sdk}_ARCHITECTURES}`.
rdar://108206099
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.
The CxxStdlib module now relies on the libcxxshim modulemap, so we
need to make sure that the modulemap is copied into the correct location before CxxStdlib is built.
rdar://108007693
This fixes a build failure that started occurring on CentOS after https://github.com/apple/swift/pull/65057:
```
error: cannot find 'strlen' in scope
```
rdar://107987115
Currently without an initializer for the unsafe char pointer type swiftc
hits an assert around not being able to handle conversions of unsafe
pointers with Any type. This patch adds the ability to convert to a
std::string.
This is to address issue https://github.com/apple/swift/issues/61218
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 original C++ operators are not currently imported into Swift because they are defined as a non-member templated functions.
This change adds the operators as Swift extension functions. This also adds an `Equatable` conformance for `std::string`.
rdar://107017882
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 makes `CxxConvertibleToCollection` the base protocol in the hierarchy. Both `CxxSequence` and `CxxRandomAccessCollection` now inherit from `CxxConvertibleToCollection`.
This improves the performance of iterating over a C++ container that is automatically conformed to `CxxConvertibleToCollection` protocol by removing the extra copy of the container.
This also tightens the requirements of `CxxConvertibleToCollection` by making `begin()` and `end()` non-mutating.
This makes `Array.init<C: CxxConvertibleToCollection>(C)` more generic by using `RangeReplaceableCollection` protocol instead of concrete `Array` type.
`Swift.String` can be initialized from any other type with an unlabeled initializer, which is either going to use the `CustomStringConvertible` conformance, or reflection. We would like clients to use the most suitable initializer, which is the one that takes `std.string` as a parameter. For instance, that allows us to attach a doc comment to the initializer.
This change makes the initializer unlabeled to make sure it is chosed by overload resolution when a client invokes `String(myCxxString)`.
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.
The modulemap and header files target was added to `ALL`, which works
when invoking the build thru the `build-script`, but make some test fail
when doing a manual configuration and later doing
`check-swift-validation` or similar, because the modulemap/header were
not copied into the build directory.
Follow a pattern similar to the one in GlibC (which this file seemed to
be prepared for, since the `libcxxshim_modulemap_target_list` variable
was already there), create a global target for all the modulemap/headers
of each SDK and add that global target as a dependency of sdk-overlay
(which is a dependency of check-swift-validation and others).
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.
