Skip to content

[5.0][CodeCompletion] Fix call arguments completion in overloaded case #20797

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

rintaro
Copy link
Member

@rintaro rintaro commented Nov 27, 2018

(Cherry-pick of #20703 and #20721 to swift-5.0-branch)

Not critical for convergence. Not ABI-affecting.

In <expr> '(' <code-completion-token> case, we usually complete call arguments. However, if <expr> isn't typechecked, for example because of overloading, we used to give up arguments completions.

Now, use possible callee informations from CodeCompletionTypeContextAnalyzer. This increases the chance to provide arguments completions.

rdar://problem/41147232
rdar://problem/43703157

These functions are only used by CodeCompletionTypeContextAnalyzer.
Move them into it.

(cherry picked from commit bd4f20d)
To simplify call-site code.

(cherry picked from commit 1af8078)
in context type analysis.
Still NFC, but this is needed by later commits.

(cherry picked from commit 8a6c540)
In `<expr> '(' <code-completion-token>` case, we usually complete call
arguments. If '<expr>' isn't typechecked, for example, because of
overloading, we used to give up arguments completions.

Now, use possible callee informations from the context type analyzer. This
increases the chance to provide accurate completions.

rdar://problem/43703157
(cherry picked from commit c55d6ce)
@rintaro rintaro requested a review from a team November 27, 2018 14:37
Accept `getInterfaceType->hasError()` declarations. Even if the part of
the declaration has error, we still have chance to get context info from
the other part of it. For instance:

  func foo(x: Int, y: INt) { }
  foo(x: #^COMPLETE^#

We should resolve 'Int' as the context type even if parameter `y` is an
error type.

(cherry picked from commit 337d53f)
@rintaro
Copy link
Member Author

rintaro commented Dec 4, 2018

Added cherry-pick of #20964 because it's related. rdar://problem/46311661

@akyrtzi
Copy link
Contributor

akyrtzi commented Dec 5, 2018

@swift-ci test and merge

@akyrtzi akyrtzi merged commit aad7d38 into swiftlang:swift-5.0-branch Dec 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants