Skip to content

[CodeCompletion] Delete expr type state after getting expr completions #7930

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
Mar 6, 2017
Merged

[CodeCompletion] Delete expr type state after getting expr completions #7930

merged 1 commit into from
Mar 6, 2017

Conversation

bitjammer
Copy link
Contributor

When we are getting completions for an initializer at the open
parenthesis, as in:

class C {
func foo<S: Sequence>(x: S) {
String(#^A^#
}
}

after getting all of the overloads for String.init or other applicable
completions for the expression, we leave the stateful expression type
set when performing the last part of code completion, which is getting
other visible declarations at that point.

In this example, C.foo is available to call. However, if the expression
type is left around, we will mistakenly try to use it to substitute
generics of the found declaration, which doesn't make sense, because
foo is a method on C, not String in this case.

We really need to make this part of the compiler less stateful in
the future, or at least formalize the state changes more. It might
also make sense to further separate different kinds of completions
and the mechanisms for getting types, as we reuse the same machinery
for methods and module functions, making a lot of fallback assumptions.

rdar://problem/30137466

When we are getting completions for an initializer at the open
parenthesis, as in:

class C {
  func foo<S: Sequence>(x: S) {
    String(#^A^#
  }
}

after getting all of the overloads for String.init or other applicable
completions for the expression, we leave the stateful expression type
set when performing the last part of code completion, which is getting
other visible declarations at that point.

In this example, C.foo is available to call. However, if the expression
type is left around, we will mistakenly try to use it to substitute
generics of the found declaration, which doesn't make sense, because
foo is a method on C, not String in this case.

We really need to make this part of the compiler less stateful in
the future, or at least formalize the state changes more. It might
also make sense to further separate different kinds of completions
and the mechanisms for getting types, as we reuse the same machinery
for methods and module functions, making a lot of fallback assumptions.

rdar://problem/30137466
@bitjammer
Copy link
Contributor Author

@swift-ci Please test

@tkremenek tkremenek merged commit c982578 into swiftlang:swift-3.1-branch Mar 6, 2017
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