This ensures only one process is generating module cache from an interface
file so that we don't blow up memory usage when multiple processes are
doing the same. The locking mechanism is similar to that of Clang's.
A better approach is that the build system takes care of the module building
step as a formal dependency.
rdar://52839445
✔ More informative error messages in case of crashes.
✔ Handling and documenting different cases.
✔ Test cases for different cases.
✔ Make SDKDependencies.swift pass again.
After setting up the .swiftsourceinfo file, this patch starts to actually serialize
and de-serialize source locations for declaration. The binary format of .swiftsourceinfo
currently contains these three records:
BasicDeclLocs: a hash table mapping from a USR ID to a list of basic source locations. The USR id
could be retrieved from the following DeclUSRs record using an actual decl USR. The basic source locations
include a file ID and the results from Decl::getLoc(), ValueDecl::getNameLoc(), Decl::getStartLoc() and Decl::getEndLoc().
The file ID could be used to retrieve the actual file name from the following SourceFilePaths record.
Each location is encoded as a line:column pair.
DeclUSRS: a hash table mapping from USR to a USR ID used by location records.
SourceFilePaths: a hash table mapping from a file ID to actual file name.
BasicDeclLocs should be sufficient for most diagnostic cases. If additional source locations
are needed, we could always add new source location records without breaking the backward compatibility.
When de-serializing the source location from a module-imported decl, we calculate its USR, retrieve the USR ID
from the DeclUSRS record, and use the USR ID to look up the basic location list in the BasicDeclLocs record.
For more details about .swiftsourceinfo file: https://forums.swift.org/t/proposal-emitting-source-information-file-during-compilation
- No need to hash input values first
- Pass many values to a single hash_combine to save on intermediates
- Use hash_combine_range instead of a loop of hash_combines
No functionality change.
Previously, we'd combine just the target architecture, and rely on the
fact that the .swiftinterface is in a reasonably-target-specific
subdirectory to include enough entropy to avoid hash collisions. But in
the presence of a VFS or if two targets are sharing the same
.swiftinterface file (which can sometimes happen in tests), they will
collide since the hash only includes architecture.
Instead, use the same normalization that the serialized module loader
uses, and serialize the normalized target triple instead.
Fixes rdar://55881335
