This constructor is unsafe, as it allows creating a `std::span` with a count higher than the size of the sequence of objects it refers to. Therefore, when hardening is enabled, an out-of-bounds access won't trap.
We make it deprecated to discourage its use.
We were trying to instantiate a constructor for `std::function` from a C function pointer with a non-const function pointer type. That worked well on most platforms, where `std::function` defines a single constructor for const and non-const function pointers, but failed on UBI 9.
This fixes a test (`Interop/Cxx/stdlib/use-std-function.swift`) on UBI Linux.
rdar://118026392
These x-refs might not be resolvable using regular lookup from the 'std' module as they could be instantiated/synthesized
by the clang importer. Augment the lookup logic in that case to try clang importer lookup logic that is used during
the conformance to the C++ iterator protocol.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
libc++ recently split the `std` module into many top-level modules: 571178a21a
This broke the logic that conforms C++ iterator types to `UnsafeCxxInputIterator`/`UnsafeCxxRandomAccessIterator`. To determine if a C++ type is an iterator type, we look for its inner type called `iterator_category`. After module std was split, Clang instantiates `std::string::const_iterator::iterator_category` twice and doing a Clang lookup within the `const_iterator` type returns two identical `TypedefDecl`s. Clang itself has logic to merge them, but Swift doesn't.
rdar://119270491
C++ `operator bool()` is currently imported into Swift as `__convertToBool()`, which shouldn't be used by clients directly.
This adds a new protocol into the C++ stdlib overlay: `CxxConvertibleToBool`, along with an intitializer for `Swift.Bool` taking an instance of `CxxConvertibleToBool`.
rdar://115074954
This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
This fixes a compiler error when building SwiftCompilerSources in hosttools mode with a recent Xcode.
```
<unknown>:0: error: calling a private constructor of class 'clang::StmtIterator'
swift/llvm-project/clang/include/clang/AST/StmtIterator.h:137:3: note: declared private here
StmtIterator(const StmtIteratorBase &RHS)
^
```
rdar://113514872
This makes it possible to initialize `std::vector` from a Swift Sequence. This also conforms C++ vectors to `ExpressibleByArrayLiteral`, making it possible, for instance, to pass a Swift array to a C++ function that takes a vector of strings as a parameter.
rdar://104826995
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
This is an inheritor of the existing `UnsafeCxxInputIterator` protocol, with the only difference being the ability to mutate `var pointee` via a non-const `operator*()`.
This is needed to support mutable subscripts for `std::map` via `CxxDictionary`.
rdar://105399019
This fixes the automatic `std::unordered_map` conformance to CxxDictionary on Linux. Previously `std::unordered_map::const_iterator` was not auto-conformed to UnsafeCxxInputIterator because its `operator==` is defined on a templated base class of `const_iterator`.
rdar://105220600
`std::set::insert` isn't exposed into Swift, because it returns an instance of an unsafe type.
This change adds a Swift overload of `insert` for `std::set` and `std::unordered_set` that has the return type identical to `Swift.Set.insert`: a tuple of `(inserted: Bool, memberAfterInsert: Element)`.
rdar://111036912
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.
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.
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.
C++ iterator types are often templated, and sometimes declare `operator==` as a non-member templated function. In libc++, an example of this is `__wrap_iter` which is used as an iterator type for `std::vector` and `std::string`.
We don't currently import templated non-member operators into Swift, however, we still want to support common C++ iterator patterns.
This change adds logic to instantiate templated non-member `operator==` for types that define `iterator_category` and are therefore likely to be valid iterator types.
rdar://97915515
If an operator is declared as a method of a templated class, we were failing to look it up during auto-conformance to `UnsafeCxxInputIterator`.
This fixes `Interop/Cxx/stdlib/use-std-map.swift` on Ubuntu.
rdar://102420290
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.
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")`.
My recent change started linking ClangImporter with Sema, which accidentally introduced a circular dependency between the two.
This patch avoid the usage of type checker logic from ClangImporter's automatic protocol conformance logic.
rdar://101763817
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+=`.
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
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`.
