This adds conformances for C++ string types (`std::string`, `std::u16string`, `std::u32string`) to `Swift.ExpressibleByStringInterpolation`.
These conformances currently implicitly use `DefaultStringInterpolation`. In the future we can provide more performant interpolation mechanisms for C++ strings specifically that avoid the extra conversion between Swift String and C++ string types.
rdar://147249169
The PR https://github.com/swiftlang/swift/pull/77857 added windows-specific workaround for https://github.com/swiftlang/swift/issues/77856, that happened after https://github.com/swiftlang/swift/pull/77843. Unfortunately this caused a new issue on windows - https://github.com/swiftlang/swift/issues/78119. It looks like windows is suffering from a similar serialization issue as libstdc++, although its even more complex as the callAsFunction is not only a derived function from a base class, the base class although has a static call operator. In any case, the libstdc++ callAsFunction deserialization fix should align with the static operator () deserialization too, so for now make windows use the same workaround as other platforms to avoid the deserialization crash (77856).
This change was tested on i686 windows too, ensuring that IR verifier crash no longer happens
In certain versions of libstdc++, `std::hash<std::string>` defines `operator()` in a base class. It looks like Swift is not correctly deserializing an inherited `operator()` for inlinable functions. This change sidesteps the issue by moving the call to `callAsFunction`/`operator()` to the C++ shim layer.
rdar://140358388
The change in 269fc941 turned out not to be enough to solve linker errors when using the CxxStdlib overlay with a non-default C++ stdlib.
In addition to `@inlinable`, the Swift functions in the overlay need to be `@_alwaysEmitIntoClient` to prevent Swift from trying to link a program that uses libc++ on Linux against the CxxStdlib binary shipped in the toolchain.
rdar://138838506
This is a requirement for being able to use the CxxStdlib overlay with a C++ standard library which is not the platform default, specifically libc++ on Linux.
The module would get rebuilt from its textual interface (`CxxStdlib.swiftinterface`) by the compiler whenever a custom C++ stdlib is used. Since the mangled names of C++ stdlib symbols differ across implementations (libc++ vs libstdc++), a Swift program that uses these overlay functions would fail to link, unless the definitions of these functions are available.
rdar://138838506
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.
