If we include this file, it generates inline assembly, which would be fine
except that when apps are being built with bitcode, that isn't allowed.
rdar://103274667
Upstream build system zippering support.
Setting the `SWIFT_ENABLE_MACCATALYST` flag will build the compatibility
libraries with zippering enabled.
Note that AppleClang and LLVM Clang use different flags to write
zippered files. The Swift stdlib build doesn't know what clang we're
using, so we can't ask it for the compiler ID to determine which whether
we're using AppleClang or LLVM clang, hence the nasty `execute_process`
trick to figure out whether the compiler that's actually compiling the
stdlib knows about the flag or not.
The threading library is being pulled into the compatibility libraries,
but in order to do that we need to make sure it gets built with the
correct deployment target. (Which means we need a special version for
the compatibility libraries.)
rdar://96690200
When back-deploying, create global-actor-qualified function types via a
separate entrypoint
(`swift_getFunctionTypeMetadataGlobalActorBackDeploy`) in the
compatibility library, which checks whether it is running with a
new-enough runtime to use `swift_getFunctionTypeMetadataGlobalActor`.
Failing that, it calls into a separate copy of the implementation that
exists only in the back-deployed concurrency library.
Fixes rdar://79153988.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
