This is currently a no-op since we don't auto-conform custom types to any kind of `MutableCollection` protocols: `UnsafeCxxMutableInputIterator` is only used for `std::map` conformance to `CxxDictionary` in the overlay. However, this will be useful in the future if we start conforming mutable C++ containers to certain Swift protocols: that way containers that use raw non-const pointers as iterators would be treated as mutable in Swift.
This is an inheritor of the existing `UnsafeCxxInputIterator` protocol, with the only difference being the ability to mutate `var pointee` via a non-const `operator*()`.
This is needed to support mutable subscripts for `std::map` via `CxxDictionary`.
rdar://105399019
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
This moves `libstdcxx.modulemap` and `libstdcxx.h` from `*.xctoolchain/usr/lib/swift/macosx/arm64e` to `*.xctoolchain/usr/lib/swift/macosx` to simplify distribution.
rdar://110788977
`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.
