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.
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.
CentOS 7 is shipped with an outdated version of libstdc++, which does not include `codecvt` stdlib header.
Let's wrap the `#include` with `#if __has_include`.
`cxxString` might get deallocated immediately after `c_str()` call, which would mean that the pointer passed to `String(cString:)` points to invalid memory.
We haven't actually seen this, but let's preemptively add an explicit `withExtendedLifetime` call to avoid running into this in the future.
Previously this header was sometimes getting hijacked by the first header to include it. This caused Swift compiler failures on Linux when using any LLVM header that uses `assert`.
Now `cassert` is referenced directly from a modulemap, which fixes the issue.
