Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
Pattern matching in Swift can either be expression pattern matching by comparing two instances using the `~=` operator or using enum matching by matching the enum case and its associated types (+ tuple pattern matching, but that’s not relevant here). We currenlty only consider the expression pattern matching case for code completion. To provide enum pattern matching results, we thus need to have a `~=` operator between the code completion token and the match expression
For example, when we are completing
```swift
enum MyEnum {
case myCase(String)
}
switch x {
case .#^COMPLETE^#
}
```
then we are looking up all overloads of `~=` and try to match it to the call arguments `(<Code Completion Type>, MyEnum)`.
The way we currently get `#^COMPLETE^#` to offer members of `MyEnum`, is that we are trying to make sure that the `~=<T: Equatable>(T, T)` operator defined in the standard library is the best solution even though it has fixes associated with it. For that we need to carefully make sure to ignore other, more favourable overloads of `~=` in `filterSolutions` so that `~=<T: Equatable>(T, T)` has the best score.
This poses several problems:
- If the user defines a custom overload of `~=` that we don't prune when filtering solutions (e.g. `func ~=(pattern: OtherType, value: MyEnum) -> Bool`), it gets a better score than `~=<T: Equatable>(T, T)` and thus we only offer members of `OtherType` instead of members from `MyEnum`
- We are also suggesting static members of `MyEnum`, even though we can't pattern match them due to the lack of the `~=` operator.
If we detect that the completion expression is in a pattern matching position, also suggests all enum members of the matched type. This allows us to remove the hack which deliberately ignores certain overloads of `~=` since we no longer rely on `~=<T: Equatable>(T, T)`. It thus provides correct results in both of the above cases.
Fixes rdar://77263334 [SR-14547]
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
To describe fine grained priorities.
Introduce 'CodeCompletionFlair' that is a set of more descriptive flags for
prioritizing completion items. This aims to replace '
SemanticContextKind::ExpressionSpecific' which was a "catch all"
prioritization flag.
For example, for
class C {
class D: C {
init() {}
}
}
let _: C = .#^HERE^#
We used to suggest 'D()' (not just 'D') because it was invalid without
initialization. However, after SE-0287, it can be valid. For example, if
'D' has:
extension C.D {
static var staticC: C { ... }
}
Users can write:
let _: C = .D.staticC
So we should not suggest constructor calls. Also, this is consistent with
normal type name completion. Users still can get initializer completions
by adding '(' after the type name.
Although initialization call completion with type names was convenient
in some cases, it's too annoying when we have unrelated member types
like:
enum MyEnum {
typealias Content = Int
case value(Content)
}
We don't want `.Content(bitPattern)` etc for implicit member completion
for 'MyEnum' context type.
rdar://75963052
Following on from updating regular member completion, this hooks up unresolved
member completion (i.e. .<complete here>) to the typeCheckForCodeCompletion API
to generate completions from all solutions the constraint solver produces (even
those requiring fixes), rather than relying on a single solution being applied
to the AST (if any). This lets us produce unresolved member completions even
when the contextual type is ambiguous or involves errors.
Whenever typeCheckExpression is called on an expression containing a code
completion expression and a CompletionCallback has been set, each solution
formed is passed to the callback so the type of the completion expression can
be extracted and used to lookup up the members to return.
Using canonical types. Otherwise 'Optional<T>' and 'T?' aren't
considered the same.
Also, for example, the expected context types are 'T?' and 'T', don't
get results from 'T' twice.
rdar://problem/71063455
Calculate and set the type relation in each result building logic which
knows the actual result type.
CodeCompletionResultBuilder couldn't know the actual result type. From
the declaration alone, it cannot know the correct result type because it
doesn't know how the declaration is used (e.g. calling? referencing by
compound name? curried?)
Since the user can now write additional member accesses off of an UnresolvedMemberExpr, we should offer all available completions rather than just those that match the contextual type.
If the type check return type from the context has unresolved types, it
can't be used for checking convertibility. Fallback to get
'TypeContextInfo' of the closure position.
rdar://problem/66002497
For exmaple:
func foo(_: Int, _: IntOption)
func foo(_: Float, _: FloatOption)
foo(intVal, .<HERE>)
Previously code completion suggests static member from 'IntOption' and
'FloatOption' without any prioritization. Prioritize members from
'IntOption' because the user probably wants to input them.
In such cases, 'CodeCompletionExpr' at the cursor position is
pre-typechecked to 'IntOption'. So mark results with matching type with
'ExprSpecific'.
rdar://problem/62121221
If we are code-completion, we need to keep the parsed expression in the
AST. Don't discard the parsed expression if the middle expression in a
ternary expression has code-completion token. This improves the
completions for:
let _: MyEnum = condition ? .<HERE>
let _: MyEnum = condition ? .<HERE> :
rdar://problem/54132682
When a completion happens in a key position and the value expression
is missing. This allows type checker to use TypeVariable so it increases
the chance to type check them successfully.
- Analyze the type of the literal in the context
- If ':' is missing in the literal, treat the expression as a key
expression
- If the parent expression is TupleExpr, analyze the context type of the
tuple first, then return the element type of the position
rdar://problem/57096392
```swift
protocol Proto {}
struct ConcreteProto {}
struct MyStruct<T> {}
extension MyStruct where T: Proto {
static var option: MyStruct<ConcreteProto> { get }
}
func foo<T: Proto>(arg: MyStruct<T>) {}
func test() {
foo(arg: .#^HERE^#)
}
```
In this case, the type of `MyStruct.option` is `MyStruct<ConcreteProto>`
whereas the context type is `MyStruct<T> where T: Proto`.
When checking the convertibility of them , we need to "open archetype types".
rdar://problem/24570603
rdar://problem/51723460
For unresolved member completion, member decls in `Optional`
referenceable by implicit member expression are useless in most cases.
- `init(_: <#Wrapped#>)`
- `init(nilLiteral: ())`
- `.some(<#Wrapped#>)`
- `.none`
Instead, provide `nil` with erasing `.` instruction.
rdar://problem/47806831
When completing in the only expression of closure, use the return type
of the closure as the type context for the code-completion. However,
since code-completion may be on an incomplete input, we only use the
return type to improve the quality of the result, not to mark it
invalid, since (a) we may add another statement afterwards, or (b) if
the context type is Void it doesn't need to match the value.
enum MyEnum {
case null
case str(String)
}
When completing elements for enum like this, the former shows `MyEnum`,
but the latter shows `(String) -> MyEnum`. This is inconsistent with
function call pattern which only shows the result type.
rdar://problem/48220244
For `Initializer` decl context, type context analyzer should look into
its parent context because that might constrain initializer's type.
rdar://problem/48208253
For example, given:
[.foo(), .bar()]
If user want to insert another element in between:
[.foo(), <HERE> .bar()]
'.bar()' is probably not a part of the inserting element. Moreover, having
the suffix doesn't help type inference in any way.
