-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[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
Conversation
@swift-ci please smoke test |
@swift-ci please smoke test linux |
@swift-ci please smoke test |
0776462
to
7922b5f
Compare
@swift-ci please smoke test |
7922b5f
to
371630b
Compare
@swift-ci please smoke test |
There was a problem hiding this 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
@swift-ci please smoke test macos |
371630b
to
4c438db
Compare
This is now stacked on top of #81550 to avoid further merge conflicts, since both PRs have been approved separately. |
@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
4c438db
to
9c4c0c4
Compare
@swift-ci please smoke test |
…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)
…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)
…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)
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