The Swift compiler on linux is built with an older stdlib then runs with the newer shipped stdlib

[finagolfin]

Description

I was just building the toolchain natively on Android when this potential issue struck me. We build the Swift toolchain for linux on all the current CI branches with an older Swift 5.8.1 compiler, then set its runpath to the newer Swift stdlib it ships with:

> readelf -d swift-5.10.1-RELEASE-fedora39/usr/bin/swift-frontend | ag runpath
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib/swift/linux:$ORIGIN/../lib/swift/host]

This probably worked fine before when we bootstrapped the compiler against the new stdlib first, but now that we are only building the Swift compiler with the prebuilt 5.8.1 hosttools, this means the newer stdlib cannot change any of its ABI or behavior used by the compiler itself, or it will cause problems.

A potential solution is to start shipping the Swift 5.8.1 stdlib also with the toolchain, so the newer Swift stdlib is free to keep changing.

I have not observed any problems with this setup yet, but this move is fairly recent.

@etcwilde, @bnbarham, or @shahmishal, let me know what you think.

Reproduction

None

Expected behavior

See above

Environment

Swift 5.9 onwards

Additional information

No response

[rintaro]

You are right. We can't break ABI used by compiler. As stated in the commit 0988236#diff-4b74006b7c38d950627c4183690f1c6b5435d1b4da7a327fdf6ed9bcbb2cc33bR552-R555 , we intentionally did this to make macros work in Linux in the limited time frame.

I think the ideal solution is to do proper bootstrapping:

1. build a toolchain having RPATH to the runtime in the builder's toolchain
2. build a stdlib/runtime using the toolchain (1)
3. build a toolchain with the stdlib/runtime (2)

Until that, yeah, bundling the runtime from the builder toolchain might be a temporary solution. But I think we can defer that until an actual unavoidable ABI break occurs. And we should be able to detect that pretty obviously, like runtime crash.