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
