Allow Linux distributions to provide their own C++ flags to compile the
C++ overlay correctly. The default is kept the same for Ubuntu and
CentOS, but other distributions can provide other flags to use their own
distro GCC stdlibc++ or even libc++ if they choose.
This should not change the current compilation, but opens the door for
other maintainers to provide a different value that work on their
systems.
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.
CentOS 7 is shipped with an outdated version of libstdc++, which does not include `codecvt` stdlib header.
Let's wrap the `#include` with `#if __has_include`.
`cxxString` might get deallocated immediately after `c_str()` call, which would mean that the pointer passed to `String(cString:)` points to invalid memory.
We haven't actually seen this, but let's preemptively add an explicit `withExtendedLifetime` call to avoid running into this in the future.
Previously this header was sometimes getting hijacked by the first header to include it. This caused Swift compiler failures on Linux when using any LLVM header that uses `assert`.
Now `cassert` is referenced directly from a modulemap, which fixes the issue.
Previously the modulemap for the C++ stdlib on Linux was provided via `-fmodule-map-file=` Clang argument pointing to the modulemap file within the Swift toolchain. The modulemap file could not reference the stdlib headers directly, since the exact stdlib include directory varies across Linux versions (it generally looks like `/usr/include/c++/{gcc_version}`). So the modulemap file instead referenced a local header, which `#include <>`-ed the stdlib headers, relying on Clang include resolution.
Unfortunately this did not work properly in the presence of another C++ module which included the stdlib headers: sometimes decls from the stdlib were hijacked by the other module, and were not treated as a part of the stdlib by Clang. This caused compile errors in Swift.
This change uses LLVM VFS to inject the modulemap file into the libstdc++ directory. The modulemap file is now able to reference the stdlib headers directly, which fixes the issue.
Credits to Rintaro Ishizaki for proposing a similar idea for SwiftGlibc back in 2016.
Since libstdc++ doesn't come with a Clang modulemap, Swift provides its own modulemap for libstdc++. This change makes the modulemap available while building SwiftCompilerSources.
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
