SwiftPM built with Swift 6.0 and later snapshots crashes on macOS 14

[kateinoigakukun]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI.

Description

You can reproduce the crash by running the following simple command on macOS 14 and later with swift-DEVELOPMENT-SNAPSHOT-2024-04-09-a or later.

$ /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-04-09-a.xctoolchain/usr/bin/swift package --version
zsh: segmentation fault   package --version

The segmentation fault is caused by trying to dereference an async function pointer $ss23withCheckedContinuation9isolation8function_xScA_pSgYi_SSyScCyxs5NeverOGXEtYalFTu, which is introduced by #72578 and only available in toolchain stdlib but unavailable in OS stdlib yet.

Note that #72578 itself is not wrong, but it just revealed a long-living issue.

Solution?

All images compiled with snapshot toolchains should use toolchain stdlib instead of OS stdlib because:

1. _stdlib_isOSVersionAtLeast(9999._builtinWordValue, 0._builtinWordValue, 0._builtinWordValue) always returns true after [Stdlib] Special-case major version 9999 as always available. #22658
2. All new stdlib APIs introduced in the next release are marked with @available(macOS 9999, ...) until the version is fixed to be a concrete OS version.
3. if #available and @backDeploy check the running OS version by using _stdlib_isOSVersionAtLeast, and it leads to referencing symbols with @available(macOS 9999) at runtime.

So as long as we use the availability placeholder, executables built with such stdlib must link exactly the same stdlib library at runtime.

Why it doesn't happen on macOS 13 or earlier?

It looks like the /usr/lib/swift/libswiftCore.dylib in the version did not include #22658, so _stdlib_isOSVersionAtLeast(9999._builtinWordValue, 0._builtinWordValue, 0._builtinWordValue) returns false.

Alternative Consideration

You might think we can revert #22658 not to make APIs marked with the placeholder always available and adjust test suites. However the implementation is already shipped as a part of macOS 14, so the issue remains as long as we use macOS 14.

Expected behavior

Not crash

Swift & OS version (output of swift --version ; uname -a)

Apple Swift version 6.0-dev (LLVM 6bf0f1dbf510217, Swift f36060f01135902)
Target: arm64-apple-macosx14.0
Darwin Yutas-Mac-mini.local 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:12:41 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T8103 arm64

[kateinoigakukun]

Hmm, due to the absolute install_name specified by LC_ID_DYLIB in libswiftCore.dylib in toolchains, Swift executables always load libswiftCore.dylib from absolute /usr/lib/swift/libswiftCore.dylib without checking @rpath.
So just adding -rpath linker option did not work unfortunately.

[kateinoigakukun]

Another approach might be reverting #22658 and making _stdlib_isOSVersionAtLeast @_alwaysEmitIntoClient.

[kateinoigakukun]

#72801 seems trying to solve the same issue for typed throws

[rauhul]

+1 I'm hitting this locally on my Mac running 14.0

[MaxDesiatov]

The issue only seems to reproduce when SwiftPM is built with 6.0 toolchains. I can't reproduce these crashes when building SwiftPM itself with Swift 5.10. IMO this should be moved to the toolchain repository.