Modules loaded from the resource dir are not usually rebuilt from the
swiftinterface as it would indicate a configuration problem. Lift that
behavior for SDK mismatch and still rebuild them.
This use case applies when a toolchain is used with a different SDK than
the one use to build the modules in the toolchain.
rdar://106101760
Only production compilers should apply the per-SDK restriction on
loading swiftmodules. Use the "is the compiler tagged" information over
a release build to align with the other main swiftmodule loading
restriction accepting only swiftmodules built by the same tag.
Also use an env var SWIFT_DEBUG_FORCE_SWIFTMODULE_PER_SDK to enable
testing this feature in any compilers.
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
When restricting loading swiftmodules to the SDK used to build them,
an exception should be made for modules built against an SDK that is a subset
of the SDK used when loading the module. In such a case, the swiftmodule
file is more reliable.
rdar://92827584
Serialize the canonical name of the SDK used when building a swiftmodule
file and use it to ensure that the swiftmodule file is loaded only with
the same SDK. The SDK name must be passed down from the frontend.
This will report unsupported configurations like:
- Installing roots between incompatible SDKs without deleting the
swiftmodule files.
- Having multiple targets in the same project using different SDKs.
- Loading a swiftmodule created with a newer SDK (and stdlib) with an
older SDK.
All of these lead to hard to investigate deserialization failures and
this change should detect them early, before reaching a deserialization
failure.
rdar://78048939
