When importing C++ class template instantiations, Swift generates a type name for each instantiation. The generated names must be unique, since they are used for mangling.
If multiple different C++ types declare nested types with the same name, which are then used as template arguments, Swift was generating the same name for those template instantiations (e.g. `shared_ptr<Impl>` for different `Impl` types).
This change makes sure we use fully-qualified type names of template parameters when generating Swift type names for class template instantiations (e.g. `shared_ptr<MyNamespace.MyClass.Impl>`).
This fixes an assertion failure coming out of IRGen:
```
Assertion failed: (Buffer.empty() && "didn't claim all values out of buffer"), function ~ConstantInitBuilderBase, file ConstantInitBuilder.h, line 75.
```
rdar://141962480
This conforms mutable C++ container types, such as `std::vector`, to `MutableCollection` via a new overlay protocol `CxxMutableRandomAccessCollection`.
rdar://134531554
When importing a C++ class template instantiation, Swift translates the template parameter type names from C++ into their Swift equivalent.
For instance, `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t>>` gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `wchar_t` is imported as `CWideChar`, which is a typealias for `Scalar` on most platforms including Darwin. Notice that Swift goes through the `CWideChar` typealias on the specific platform. Another instantiation `basic_string<uint32_t, char_traits<uint32_t>, allocator<uint32_t>>` also gets imported as `basic_string<Scalar, char_traits<Scalar>, allocator<Scalar>>`: `uint32_t` is also imported as `Scalar`. This is problematic because we have two distinct C++ types that have the same name in Swift.
This change makes sure Swift doesn't go through typealiases when emitting names of template parameters, so `wchar_t` would now get printed as `CWideChar`, `int` would get printed as `CInt`, etc.
This also encourages clients to use the correct type (`CInt`, `CWideChar`, etc) instead of relying on platform-specific typealiases.
rdar://115673622
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
C++ standard library module is called `std`. To make it more clear to a Swift developer that this module is a C++ stdlib, and not a Swift stdlib, let's rename it to `CxxStdlib`.
This is the first step in the module rename. We don't ban `std` in this patch to be able to build SwiftCompilerSources with hosttools until a new Swift compiler is shipped.
To inject a modulemap into the libstdc++ directory, Swift needs to know the path of the libstdc++ installation. Previously it was assumed to be `/usr/include/c++/{version}`, however, this might not be the case. For example, on CentOS the stdlib is located at `/opt/rh/devtoolset-{version}/root/usr/include/c++/{version}`.
This change teaches Swift to extract the libstdc++ include paths from the Clang driver, and fixes C++ stdlib lookup on CentOS.
rdar://93341210
CentOS 7 comes with an outdated libstdc++ version. In that version, `std::basic_string` has a `mutable` member, which makes all of `basic_string`'s member functions mutating in Swift. This prevents us from calling `size()` or `empty()` on an immutable value of `std.string`.
rdar://91548568
rdar://91670704
When importing an older version of libstdc++, the decls might get printed in a different order. This change makes the test work properly for libstdc++-7 as well as libstdc++-9.
rdar://91518316
This change adds a module map for libstdc++, which allows it to be properly imported into Swift as a module. The module map is installed into `usr/lib/swift/linux/{arch}` similarly to `glibc.modulemap`, and is passed to Clang as `-fmodule-map-file`.
That means it is now possible to import std directly from Swift on Linux, when C++ interop is enabled.
The module map currently declares a single `std` module without splitting the headers into submodules. This is going to change in the near future.
rdar://87654514
