`std::set::insert` isn't exposed into Swift, because it returns an instance of an unsafe type.
This change adds a Swift overload of `insert` for `std::set` and `std::unordered_set` that has the return type identical to `Swift.Set.insert`: a tuple of `(inserted: Bool, memberAfterInsert: Element)`.
rdar://111036912
This moves `libcxxshim.modulemap`, `libcxxshim.h` and `libcxxstdlibshim.h` from `*.xctoolchain/usr/lib/swift/macosx/arm64e` to `*.xctoolchain/usr/lib/swift/macosx` to simplify distribution.
rdar://110788977
This adds a new Swift overload for `append` that takes another `std::string` as a parameter.
The original C++ overload for `append` is not exposed into Swift because it returns a mutable reference `string&`.
rdar://107018724
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)`.
