Skip to content

[Swiftify] Always annotate overloads with @_disfavoredOverload #81579

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 24, 2025

Conversation

hnrklssn
Copy link
Contributor

Previously we would only add @_disfavoredOverload if the only type changed was the return type, because in any other case it is unambiguous which overload to call. However it is still ambiguous when storing the function as a value rather than calling the function, unless explicit type annotations are used.

To avoid breaking any existing code, this patch adds @_disfavoredOverload to every overload generated by @_SwiftifyImport.

rdar://151206394

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test linux

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

@hnrklssn hnrklssn force-pushed the swiftify-disfavor-overload branch from 0776462 to 7922b5f Compare May 20, 2025 17:16
@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

@hnrklssn hnrklssn force-pushed the swiftify-disfavor-overload branch from 7922b5f to 371630b Compare May 20, 2025 22:49
@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

2 similar comments
@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

Copy link
Contributor

@j-hui j-hui left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change LGTM, but I recommend some testing/sign-off from someone familiar with SourceKit to make sure this doesn't have any unintended consequences, i.e., tools behaving differently when encountering decls with @_disfavoredOverload in such a way that is bad for dev experience

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test macos

@hnrklssn hnrklssn force-pushed the swiftify-disfavor-overload branch from 371630b to 4c438db Compare May 23, 2025 06:22
@hnrklssn
Copy link
Contributor Author

This is now stacked on top of #81550 to avoid further merge conflicts, since both PRs have been approved separately.

@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.

To avoid breaking any existing code, this patch adds @_disfavoredOverload
to every overload generated by @_SwiftifyImport.

rdar://151206394
@hnrklssn hnrklssn force-pushed the swiftify-disfavor-overload branch from 4c438db to 9c4c0c4 Compare May 23, 2025 19:35
@hnrklssn
Copy link
Contributor Author

@swift-ci please smoke test

@hnrklssn hnrklssn merged commit 0f312ad into swiftlang:main May 24, 2025
3 checks passed
hnrklssn added a commit to hnrklssn/swift that referenced this pull request May 29, 2025
…lang#81579)

Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.

To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.

rdar://151206394
(cherry picked from commit 0f312ad)
hnrklssn added a commit to hnrklssn/swift that referenced this pull request May 29, 2025
…lang#81579)

Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.

To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.

rdar://151206394
(cherry picked from commit 0f312ad)
hnrklssn added a commit to hnrklssn/swift that referenced this pull request May 31, 2025
…lang#81579)

Previously we would only add @_disfavoredOverload if the only type
changed was the return type, because in any other case it is unambiguous
which overload to call. However it is still ambiguous when storing the
function as a value rather than calling the function, unless explicit
type annotations are used.

To avoid breaking any existing code, this patch adds
@_disfavoredOverload to every overload generated by @_SwiftifyImport.

rdar://151206394
(cherry picked from commit 0f312ad)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants