Add a case to LifetimeDependence.Scope to support dependencies on address-only
'let' variables. This comes up with C++ interop.
Fixes rdar://147500193 (Spurious lifetime error with closures)
(cherry picked from commit 5831777407)
This conforms mutable C++ container types, such as `std::vector`, to `MutableCollection` via a new overlay protocol `CxxMutableRandomAccessCollection`.
rdar://134531554
For C++ types that are defined in the bridging header, or are `#include`-d from the bridging header, we did not generate the automatic conformances to `CxxSequence`, `CxxRandomAccessCollection` protocols.
To check whether we should try to conform a C++ type to those protocols, the compiler checks for the presence of `requires cplusplus` in the module declaration in a modulemap file. This check is there to prevent us from accidentally pulling in `Cxx`/`CxxStdlib` modules when a client is importing a C library.
This change makes sure those conformances are generated.
rdar://121927459
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 prevented `std::vector<std::string>` from being auto-conformed to `CxxRandomAccessCollection`.
If an iterator type is templated, and does not have an explicit instantiation via a typedef or a using-decl, its specialization will not have an owning Clang module. Make sure we treat it as a part of the Clang module that owns the template decl.
rdar://112762768 / resolves https://github.com/apple/swift/issues/67410
This test is failing on UBI platform in C++20 mode:
```
Command Output (stderr):
--
<unknown>:0: warning: the '-enable-experimental-cxx-interop' flag is deprecated; please pass '-cxx-interoperability-mode=' instead
<unknown>:0: note: Swift will maintain source compatibility for imported APIs based on the selected compatibility mode, so updating the Swift compiler will not change how APIs are imported
<unknown>:0: warning: the '-enable-experimental-cxx-interop' flag is deprecated; please pass '-cxx-interoperability-mode=' instead
<unknown>:0: note: Swift will maintain source compatibility for imported APIs based on the selected compatibility mode, so updating the Swift compiler will not change how APIs are imported
/home/build-user/swift/test/Interop/Cxx/stdlib/use-std-vector.swift:41:14: error: for-in loop requires 'Vector' (aka 'std.vector<Int32, allocator<Int32>>') to conform to 'Sequence'
for e in v {
^
/home/build-user/swift/test/Interop/Cxx/stdlib/use-std-vector.swift:52:15: error: value of type 'Vector' (aka 'std.vector<Int32, allocator<Int32>>') has no member 'map'
let a = v.map { $0 + 5 }
~ ^~~
```
This makes sure we don't run this test in C++20 mode until the conformance to `CxxSequence` is synthesized correctly on UBI.
rdar://109366764
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
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
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
Using std::vector in a for-loop causes problems with some configurations. See rdar://87728422 and rdar://87805795.
This is a temporary fix to make the bots green.
Adds tests for using std-vector and some other interesting types.
This patch fixes four mis conceptions that the compiler was previously making:
1. Implicit destructors have no side effects. (Yes, this means we were not cleaning up some objects.)
2. Implicit destructors have bodies. (Technically they do, but the body doesn't include CallExprs that they make when lowered to IR.)
3. Functions other than methods can be uninstantiated templates.
4. Uninstantiated templates may have executable code. (I.e., we can never take the fast path.)
And makes sure that we visit the destructor of any VarDecl (including parameters).
