[cxx-interop] Import libstdc++ as a Clang module

[egorzhdan]

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

[egorzhdan]

@swift-ci please smoke test

[egorzhdan]

This patch depends on #42222 being merged first.

Apologies for spamming this PR with git rebases, the test failure wasn't reproducible for me locally.

[egorzhdan]

@swift-ci please smoke test

[zoecarver]

Thank you Egor. This looks great (as usual).

[egorzhdan]

@swift-ci please smoke test Windows

[egorzhdan]

@swift-ci please smoke test

[egorzhdan]

@swift-ci please smoke test Windows

[egorzhdan]

@swift-ci please smoke test

[egorzhdan]

@swift-ci please smoke test Windows

[finagolfin]

@egorzhdan, I cross-compile the trunk toolchain for Android occasionally, and this pull broke cross-compiling the libswift portion of the compiler, because the Android NDK has a C++ modulemap (for some reason, this works fine when natively building the Apr. 21 trunk snapshot on my Android phone). I then disabled the new C++ modulemap portion of this pull for Android, and it cross-compiles and works fine.

Is that what you recommend for such platforms that have a C++ modulemap of their own, or is there something else I should do instead?

[egorzhdan]

@buttaface oh this is interesting. Looks like Swift on Android uses libc++, but when cross-compiling, it uses libstdc++? I'm not familiar with Android, sorry about that. In general, I think the best approach is to always use the system-wide default C++ standard library. If the default stdlib is libc++, which already has a modulemap, then the logic in this PR should not be used.
Does compilation break when building natively with your patch? If it doesn't, then we can just remove NOT "${sdk}" STREQUAL "ANDROID" AND, like you did in your patch.

[finagolfin]

Thanks for the quick response.

Looks like Swift on Android uses libc++, but when cross-compiling, it uses libstdc++?

No, Android always uses libc++, and the Android C++ module map exists in both the cross-compilation and native build environments.

I took a closer look at the build commands and the only difference is that cross-compiling this libswift file specifies the -sdk and -resource-dir flags explicitly, whereas natively bootstrapping doesn't add those two flags. That means the native build never passes your new module map file to the Clang Importer, so there is no conflict.

If that Swift file can be built without the -resource-dir flag, maybe it shouldn't be specified when cross-compiling either?

If the default stdlib is libc++, which already has a modulemap, then the logic in this PR should not be used.
Does compilation break when building natively with your patch? If it doesn't, then we can just remove NOT "${sdk}" STREQUAL "ANDROID" AND, like you did in your patch.

I haven't tried removing it when natively building, but given my above finding that the native build never used your new module map and what you said about libc++ not needing it, removing that line seems like the solution.