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
`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)`.
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`).
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
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 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.
