This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
This moves `libstdcxx.modulemap` and `libstdcxx.h` from `*.xctoolchain/usr/lib/swift/macosx/arm64e` to `*.xctoolchain/usr/lib/swift/macosx` to simplify distribution.
rdar://110788977
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
* Fix unnecessary one-time recompile of stdlib with -enable-ossa-flag
This includes a bit in the module format to represent if the module was
compiled with -enable-ossa-modules flag. When compiling a client module
with -enable-ossa-modules flag, all dependent modules are checked for this bit,
if not on, recompilation is triggered with -enable-ossa-modules.
* Updated tests
We need ClangImporterOptions to be persistent for several scenarios: (1)
when creating a sub-ASTContext to build Swift modules from interfaces; and
(2) when creating a new Clang instance to invoke Clang dependencies scanner.
This change is NFC.
The ModuleManager in Clang maintains a mapping from FileEntry nodes to
ModuleFile data. Because FileEntry nodes are unique'd by underlying
inode number, an attacker can craft a collision by ensuring that two
different PCMs share an inode number.
This failure can be encountered with some regularity in a highly
concurrent compilation session on filesystems that use Orlov's Algorithm
to allocate inode numbers (like ext4 on Linux). Here, we use a much
simpler algorithm that forgets that PCMs have distinct inode numbers.
A future version of clang will increase the entropy of the key value to
take into account the mod time and size, which we also conveniently map
to 0 to throw it off our trail.
This reapplies four commits for the ClangImporter. They broke the build
on master because the associated commits on swift-clang's
swift-5.1-branch never made it to stable due to automerger woes. This
time I'll push everything through manually.
These are the commits being reapplied:
- a42bc62397 "ClangImporter: Share a module cache between CompilerInstances"
- 9eed34235b "ClangImporter: Adjust to r355777, PCMCache => ModuleCache"
- da8a1c57e8 "ClangImporter: Use the new CacheGeneratedPCH in Clang"
- 2134b17a20 "ClangImporter: Test that PCHs are actually cached in memory"
rdar://problem/48545366
