This will fix modularization issues caused by the presence of Glibc and libstdc++ in a single context.
Some Glibc headers were getting hijacked by the libstdc++ module, and the decls in them were incorrectly determined to be a part of libstdc++. This caused compiler errors when trying to use those decls.
After this change, we will be able to reference Glibc headers directly from the module map, without using an additional header (`SwiftGlibc.h`).
This logic is going to be extended to inject the modulemap and the header of Glibc in addition to libstdc++. It doesn't depend on the rest of ClangImporter, so let's extract it to a separate file to make incremental builds and IDE features faster.
The ObjCMethodLookupTable for protocols was not being serialized and rebuilt on load, so NominalTypeDecl::lookupDirect() on selectors was not working correctly for deserialized types. Correct this oversight.
Previously when looking up a C++ operator (e.g. `==`), `ClangImporter::Implementation::lookupValue` returned a Swift function with a generated name (e.g. `func __operatorEqualEqual`), while the caller expected the result to be a Swift operator (e.g. `func ==`).
This change makes sure that we're returning a synthesized Swift operator when looking for a C++ operator.
This fixes an assertion failure in the typechecker:
```
swift-frontend: /home/build-user/swift/lib/Sema/ConstraintSystem.cpp:1454: std::pair<Type, Type> swift::constraints::ConstraintSystem::getTypeOfReference(swift::ValueDecl *, swift::FunctionRefKind, swift::constraints::ConstraintLocatorBuilder, swift::DeclContext *): Assertion `func->isOperator() && "Lookup should only find operators"' failed.
```
The Swift build scripts pass `-sdk /` to the Swift compiler when building the Swift stdlib and the overlays, and this affects the default include paths of Clang. We need to make sure that libstdc++ path detected by ClangImporter is the same path that will be used by Clang during compilation. To do that, let's pass `--sysroot` to the Clang driver when detecting the libstdc++ path.
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
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.
LLVM has enabled opaque pointers by default. Disable while we migrate.
Note that individual tests can have opaque pointers enabled by using
`-Xcc -Xclang -Xcc -opaque-pointers`.
`InclusionDirective` was changed in llvm/llvm-project
d79ad2f1dbc2db63121620f55d6cfa915f2733ac to pass an
`Optional<FileEntryRef>` rather than a `FileEntry *`. Update overrides
in Swift to use the new API.
