This extends the existing auto-conformance mechanism to synthesize the conformances to `CxxConvertibleToCollection` protocol for C++ sequence types.
This means that the developer can now call `Array(myCxxSequence)` or `Set(myCxxSequence)` without adding any extensions manually.
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.
This became an issue in rebranch: multiple interop tests started failing (e.g. `Interop/Cxx/foreign-reference/pod.swift`).
The problem is not specific to rebranch though.
rdar://102151836
Iterating over a `CxxSequence` that is not a `CxxRandomAccessCollection` triggers a copy of the C++ collection. Let's disable the automatic conformances until we find a more efficient solution.
This means that for now developers won't be able to iterate over a `std::set` or `std::list` with a Swift for-in loop. I will submit a separate patch with an alternative solution for such types.
C++ random access collections, such as `std::vector` or `std::string`, are not affected.
This makes ClangImporter automatically conform C++ collection types to `Cxx.CxxRandomAccessCollection` protocol.
We consider a C++ sequence type to be a random access collection type its iterator conforms to `UnsafeCxxRandomAccessIterator`.
This fixes a couple cases of cases where a malformed C++ iterator type would trigger an assertion in ClangImporter: `Assertion failed: (Val && "isa<> used on a null pointer")`.
This makes ClangImporter automatically conform C++ sequence types to `Cxx.UnsafeCxxInputIterator` protocol.
We consider a C++ type to be a random access iterator type if conforms to `UnsafeCxxInputIterator`, and additionally defines `operator-` and `operator+=`.
This lifts the requirement for the user to explicitly add `import Cxx` in Swift code that relies on protocols from the `Cxx` module, such as `CxxSequence`.
This helps to bridge C++ random access collections, such as `std::vector` and `std::string`, to Swift by conforming them to `Swift.RandomAccessCollection`
To determine whether to conform a C++ type to `CxxSequence` protocol automatically, ClangImporter checks if the corresponding iterator type conforms to `UnsafeCxxInputIterator`.
This logic had false-positives, e.g. `Optional<OpaquePointer>` was treated as if it conforms to `UnsafeCxxInputIterator` while it actually doesn't. This happened because `lookupConformance` returned a conformance with a conditional requirement (`Wrapped : UnsafeCxxInputIterator`) that is not satisfied for `OpaquePointer`.
rdar://100265664
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 makes ClangImporter automatically conform C++ sequence types to `Cxx.CxxSequence` protocol.
We consider a C++ type to be a sequence type if it defines `begin()` & `end()` methods that return iterators of the same type which conforms to `UnsafeCxxInputIterator`.
These errors were sometimes produced when synthesizing conformance to `UnsafeCxxInputIterator`:
```
<unknown>:0: error: circular reference
<unknown>:0: note: through reference here
<unknown>:0: note: through reference here
```
This happened because `NominalTypeDecl::lookupDirect` attempts to deserialize Swift extensions of the type, which might belong to the module which has a dependency to the module that is currently being imported, which leads to deserialization errors.
This change makes sure we don't call `NominalTypeDecl::lookupDirect` when synthesizing conformances for C++ types.
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.
Previosly we didn't detect `func ==` that was declared out-of-class when synthesizing conformaces to `UnsafeCxxInputIterator`. Now we do.
rdar://96235368
This teaches ClangImporter to synthesize conformances of C++ iterator types to `UnsafeCxxInputIterator` protocol from the `Cxx` module.
We consider a C++ type to be an iterator if it defines a subtype (usually a typedef or a using decl) called `iterator_category` that inherits from `std::input_iterator_tag`.
rdar://96235368
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.
