AST/SILGen: Use @_alwaysEmitIntoClient diagnostic helper in unavailable code #70547
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tshortli
requested review from
hborla,
slavapestov,
a team and
xedin
as code owners
Azoy
reviewed
Dec 19, 2023
…le code. The `_diagnoseUnavailableCodeReached()` function was introduced in the Swift 5.9 standard library and employs `@backDeployed` to support compilation of binaries that target OS releases aligned with earlier Swift releases. Unfortunately, though, this backdeployment strategy doesn't work well for some unusual build environments. Specifically, in some configurations code may be built with a compiler from a recent Swift toolchain and then linked against the dylibs in an older toolchain. When linking against the older dylibs, the `_diagnoseUnavailableCodeReached()` function does not exist but the `@backDeployed` thunks emitted into the binary reference that function and therefore linking fails. The idea of building with one toolchain and then linking to the dylibs in a different, older toolchain is extremely dubious. However, it exists and for now we need to support it. This PR introduces an alternative `_diagnoseUnavailableCodeReached()` function that is annotated with `@_alwaysEmitIntoClient`. Calls to the AEIC variant are now emitted by the compiler when the deployment target is before Swift 5.9. Once these unusual build environments upgrade and start linking against a Swift 5.9 toolchain or later we can revert all of this. Resolves rdar://119046537
tshortli
force-pushed
the
diagnose-unreachable-cant-back-deploy
branch
from
77aaa35 to
6d22433
Compare
|
@swift-ci please test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
_diagnoseUnavailableCodeReached()function was introduced in the Swift 5.9 standard library and employs@backDeployedto support compilation of binaries that target OS releases aligned with earlier Swift releases. Unfortunately, though, this back-deployment strategy doesn't work well for some unusual build environments. Specifically, in some configurations code may be built with a compiler from a recent Swift toolchain and then linked against the dylibs in an older toolchain. When linking against the older dylibs, the_diagnoseUnavailableCodeReached()function does not exist but the@backDeployedthunks emitted into the binary reference that function and therefore linking fails.The idea of building with one toolchain and then linking to the dylibs in a different, older toolchain is extremely dubious. However, it exists and for now we need to support it. This PR introduces an alternative
_diagnoseUnavailableCodeReached()function that is annotated with@_alwaysEmitIntoClient. Calls to the AEIC variant are now emitted by the compiler when the deployment target is before Swift 5.9.Once these unusual build environments upgrade and start linking against a Swift 5.9 toolchain or later we can revert all of this.
Resolves rdar://119046537