IRGen: Weakly link symbols for unavailable declarations #64353
Merged
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
|
@swift-ci please test |
tshortli
force-pushed
the
weak-link-unavailable-symbols
branch
from
29ffab3 to
cc05fbf
Compare
|
I tweaked this a bit to allow unavailable declarations with an |
When computing linkage, the compiler would treat unavailable declarations as if they were "always available" when they lack an `introduced:` version: ``` // Library @available(macOS, unavailable) public func foo() { // … } // Client import Library @available(macOS, unavailable) func bar() { // Even though foo() and bar() are unavalable on macOS the compiler still // strongly links foo(). foo() } ``` This created an unnecessary dependency between libraries and their clients and also can interfere with back deployment, since unavailable declarations may not be present in a library on all OS versions. Developers could work around these issues by conditionally compiling the code that references an unavailable declaration, but they shouldn't have to given that unavailable code is meant to be provably unreachable at runtime. Additionally, it could improve library code size if we allowed the compiler to strip unavailable declarations from a binary completely. Resolves rdar://106673713
…ions. If a declaration is unavailable but also has an `introduced:` availability version, treat that as an indication that it is considered ABI and should be linked as if it were available. Part of rdar://106673713
tshortli
force-pushed
the
weak-link-unavailable-symbols
branch
from
cc05fbf to
084ef39
Compare
|
@swift-ci please test |
|
I believe that this is causing a regression for Windows: https://ci-external.swift.org/job/oss-swift-windows-toolchain-x86_64-vs2019/2829/console |
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.
When computing linkage, the compiler would treat unavailable declarations as if they were "always available" if they also lack an
introduced:version:This created an unnecessary dependency between libraries and their clients and also can interfere with back deployment, since unavailable declarations may not be present in a library on all OS versions. Developers could work around these
issues by conditionally compiling the code that references an unavailable declaration, but they shouldn't have to given that unavailable code is meant to be provably unreachable at runtime. Additionally, in the future it could improve library code size if we allowed the compiler to strip unavailable declarations from a binary completely.
Resolves rdar://106673713