Clang implicitly enables local submodule visibility when compiling in C++20 mode. ClangImporter does not support it, so let's disable it explicitly.
rdar://108959307 / https://github.com/apple/swift/issues/65710
libstdc++ currently cannot be split into submodules due to the way some types are defined, e.g. there are multiple headers that define `size_t`, so those headers must be a single (sub-)module.
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
This disables TBD validation when C++ interop is enabled, unless an explicit `-validate-tbd-against-ir=` flag was passed.
rdar://83405989 / https://github.com/apple/swift/issues/56458
This ensures that a module built from Swift interface file (and as such interop is disabled),
that references 'exit' (from _SwiftConcurrencyShims module) can resolve the module reference to
'exit' even when it's being imported when interop is enabled (and thus it loads a different underlying _SwiftConcurrencyShims).
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
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::optional` when used from Swift code.
As of now, the overlay adds an initializer of `Swift.Optional` that takes an instance of `CxxOptional` as a parameter.
`std::map` conformance to `CxxDictionary` is synthesized properly, only the `std::unordered_map` conformance is problematic.
Let's make sure we test the `std::map` conformance with libstdc++ on Linux.
This adds a protocol to the C++ standard library overlay which will improve the ergonomics of `std::map` and `std::unordered_map` when used from Swift code.
As of now, `CxxDictionary` adds a subscript with an optional return type that mimics the subscript of `Swift.Dictionary`.
Similar to https://github.com/apple/swift/pull/63244.
This makes sure that Swift is only auto-conforming C++ container types to `CxxSequence`/`CxxConvertibleToCollection` if they expose non-mutating `begin()` and `end()` methods.
We might want to make `begin()` and `end()` non-mutating in the near future to enable performance optimizations. This change makes sure that client code relying on the automatic conformances doesn't suddenly stop compiling if/when the mutability requirement on the protocol function changes.
`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.
