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.
libstdc++9 has a dependency on the `tbb` package, which is not bundled with Ubuntu as of 20.04:
`<execution>` includes `<pstl/parallel_backend_tbb.h>` which tries to include `<tbb/blocked_range.h>`.
This results in compiler errors when someone is trying to use the C++ stdlib from Swift:
```
/usr/include/c++/9/pstl/parallel_backend_tbb.h:19:10: error: 'tbb/blocked_range.h' file not found
```
Let's only include `<execution>` if tbb headers are available.
rdar://102151194
This will help us to auto-generate conformances to `CxxRandomAccessCollection`, since synthesized conformances must have all of their witnesses explicitly provided.
This helps to bridge C++ random access collections, such as `std::vector` and `std::string`, to Swift by conforming them to `Swift.RandomAccessCollection`
1. Instead of storing the C++ collection within `class CxxIterator`, store a boxed C++ collection and make `CxxIterator` a struct. This enables a number of Swift optimizations for iterators, while preserving the guarantee that the C++ collection is not copied or moved in memory (which would invalidate iterators).
2. Make `sequence` parameter shared. This avoids a second copy of the C++ collection when initializing `CxxIterator`.
Credits to Alex Lorenz for this idea!
Previously the conversion mechanism called `std::string::c_str` and passed it to `String(cString:)` which accepts a null-terminated string. If the string contains a `\0` character, this failed to initialize the entire string properly.
This fixes a crash that happened when creating an instance of `std::string` from a `Swift.String` that contains non-ASCII characters.
When converted to a UTF-8 array, such characters might be represented by numbers that fall out of `CChar`'s boundaries if they have a sign bit set to 1. This is normal and shouldn't trigger a crash or an assertion failure.
By referencing a C++ stdlib header directly from the modulemap, we make sure that the header is treated as a part of the stdlib, not a part of the first clang module to include it.
Addresses the issue described in https://forums.swift.org/t/llvm-fails-to-build-with-modules/59700/8.
This is needed for automatic synthesis of conformances to `CxxSequence` protocol.
It also makes typechecker errors easier to understand when they happen.
This allows `std::string` to be constructed implicitly from a String literal, which is convenient e.g. when calling C++ APIs that take `std::string` as a parameter.
For some reason this isn't working, so I reverted to the previous approach. We can try to re-visit this in the future for a potential perf improvement.
Allow Linux distributions to provide their own C++ flags to compile the
C++ overlay correctly. The default is kept the same for Ubuntu and
CentOS, but other distributions can provide other flags to use their own
distro GCC stdlibc++ or even libc++ if they choose.
This should not change the current compilation, but opens the door for
other maintainers to provide a different value that work on their
systems.
