[Serialization] Restrict resilient swiftmodules to the compiler that built them

Introduce a new loading restriction that is more strict than the serialization
version check on swiftmodules. Tagged compilers will only load
library-evolution enabled swiftmodules that are produced by a compiler with the
exact same revision id. This will be more reliable in production
environments than using the serialization version which we forgot to
update from time to time. This shouldn't affect development compilers that
will still load any module with a compatible serialization version.

rdar://83105234
This commit is contained in:
Alexis Laferrière
2021-06-01 16:57:40 -07:00
parent 2cd0d5e1d3
commit 5c2122a08c
7 changed files with 121 additions and 3 deletions

View File

@@ -56,7 +56,7 @@ const uint16_t SWIFTMODULE_VERSION_MAJOR = 0;
/// describe what change you made. The content of this comment isn't important;
/// it just ensures a conflict if two people change the module format.
/// Don't worry about adhering to the 80-column limit for this line.
const uint16_t SWIFTMODULE_VERSION_MINOR = 629; // BuilderSDK
const uint16_t SWIFTMODULE_VERSION_MINOR = 630; // Precise
/// A standard hash seed used for all string hashes in a serialized module.
///
@@ -755,7 +755,8 @@ namespace control_block {
METADATA = 1,
MODULE_NAME,
TARGET,
SDK_NAME
SDK_NAME,
REVISION,
};
using MetadataLayout = BCRecordLayout<
@@ -785,6 +786,11 @@ namespace control_block {
SDK_NAME,
BCBlob
>;
using RevisionLayout = BCRecordLayout<
REVISION,
BCBlob
>;
}
/// The record types within the options block (a sub-block of the control