Sema: Correctly treat overloads in unavailable extensions as unavailable #77258
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 smoke test |
xedin
approved these changes
Oct 28, 2024
|
Looks like I will need to resolve an ambiguity error that arises in Embedded Swift first. Because |
This was referenced Oct 30, 2024
Functions like `fatalError()` have overloads for Embedded Swift only that take StaticString instead of String, since String is unavailable. Unfortunately, many of these overloads create the opportunity for ambiguity in certain contexts. The easiest way to avoid the ambiguities is to mark each of the overloads taking `String` as `@_disfavoredOverload`. Another approach that could work would be to remove the default arguments from the `String` variants in Embedded Swift only, but that would create even more duplication of source code so it doesn't seem worth it.
tshortli
force-pushed
the
discard-overloads-in-unavailable-extensions-in-constraint-solver
branch
from
007b7e0 to
91d73b2
Compare
tshortli
force-pushed
the
discard-overloads-in-unavailable-extensions-in-constraint-solver
branch
from
91d73b2 to
1bededa
Compare
…ble. Instead of checking for unavailability attributes directly in the solver, which does not correctly handle members of unavailable extensions, query `checkDeclarationAvailability()` instead. By using the same underlying logic as the availability checker the constraint solver can be confident in the accuracy of this result. Resolves rdar://87403752.
tshortli
force-pushed
the
discard-overloads-in-unavailable-extensions-in-constraint-solver
branch
from
1bededa to
98b34c6
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
tshortli
deleted the
discard-overloads-in-unavailable-extensions-in-constraint-solver
branch
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.
Instead of checking for unavailability attributes directly in the solver, which does not correctly handle members of unavailable extensions, query
checkDeclarationAvailability()instead. By using the same underlying logic as the availability checker the constraint solver can be confident in the accuracy of this result.Now that availability of overloads is being checked consistently, an ambiguity in Embedded Swift has been revealed. Functions like
fatalError()have overloads for Embedded Swift only that takeStaticStringinstead ofString, sinceStringis unavailable. Unfortunately, many of these overloads create the opportunity for ambiguity in certain unavailable contexts. The easiest way to avoid the ambiguities is to mark each of the overloads takingStringas@_disfavoredOverload. Another approach that could work would be to remove the default arguments from theStringvariants in Embedded Swift only, but that would create even more duplication of source code so it doesn't seem worth it.Resolves rdar://87403752.