Instead of appending characters one-by-one, which resizes the resulting string multiple times, let's reserve the required number of bytes beforehand.
rdar://127423949
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 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
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)`.
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.
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.
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.
