mirror of
https://github.com/apple/swift.git
synced 2025-12-14 20:36:38 +01:00
7dba418fe7
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
53 lines
1.4 KiB
Swift
53 lines
1.4 KiB
Swift
// RUN: %swift-ide-test -code-completion -code-completion-token=A -source-filename %s
|
|
// RUN: %swift-ide-test -code-completion -code-completion-token=B -source-filename %s
|
|
// RUN: %swift-ide-test -code-completion -code-completion-token=C -source-filename %s
|
|
// RUN: %swift-ide-test -code-completion -code-completion-token=D -source-filename %s
|
|
// RUN: %swift-ide-test -code-completion -code-completion-token=E -source-filename %s
|
|
// RUN: %swift-ide-test -code-completion -code-completion-token=F -source-filename %s
|
|
|
|
// Make sure that visible members don't mess up code completion,
|
|
// having seen a constructor for an incompatible declaration.
|
|
|
|
class CompeteInMethod {
|
|
// Here, the method foo is actually visible at the
|
|
// point of code-completion.
|
|
func foo() {
|
|
String(#^A^#
|
|
}
|
|
}
|
|
|
|
class CompleteInVar {
|
|
// Same here - var decls are added to code completion results
|
|
// in a different but similarly shaped code path. So here,
|
|
// the var x is actually visible at the point of code-completion.
|
|
var x: Int {
|
|
String(#^B^#
|
|
}
|
|
}
|
|
|
|
class CompleteOutsideMethod {
|
|
func foo() {}
|
|
init() {
|
|
String(#^C^#
|
|
}
|
|
}
|
|
|
|
class CompleteOutsideVar {
|
|
var x: Int { return 1 }
|
|
init() {
|
|
String(#^D^#
|
|
}
|
|
}
|
|
|
|
class CompleteInsideGenericFunc {
|
|
func foo<S: Sequence>(x: S) {
|
|
String(#^E^#
|
|
}
|
|
}
|
|
|
|
class CompleteInsideGenericClass<S: Sequence> {
|
|
func foo(x: S) {
|
|
String(#^F^#
|
|
}
|
|
}
|