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.
This happens when, e.g. an expression being switched on is invalid so
expression patterns in the switch cases (which may contain the completion
expression) are not checked.
Also setup the Lookup object to handle member completion in ObjC selector
expressions correctly, and fix passing the wrong expression when computing
isStaticallyDerivedMetatype().
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
Constructor call patterns already get a real priority, but because of
the way we do function call patterns we don't have enough information,
and previously we were setting it to "expression specific", which is
unnecessarily high, particularly since functions (unlike inits) have
other better ways to code-complete already.
rdar://31113161
Make sure we build the CatchStmt and DoCatchStmt AST nodes when
code-completing inside the body of a catch so that we can complete the
bindings from the catch.
It's often a good idea to early-exit once we see a code completion
token, but not when we skip building an AST node that provides variable
bindings. In code completion, we don't have Scope-based lookup, and
rely on having reachable AST nodes for patterns so that we can dig the
out the bindings we need.
Also extend the pattern checking to handle "IsPattern", since we
apparently weren't handling "let x as Foo", and that affects all complex
catch patterns because of an implicit "as ErrorType" or explicit
"as NSError".
rdar://problem/21116164
Swift SVN r29070
Then use that to ban NSError.init(), because it doesn't create a valid
NSError. In the long run Foundation will hopefully add this to their
headers, but they can't yet (rdar://problem/19977891).
rdar://problem/21042412
Swift SVN r28881
It's not okay to filter to only ErrorType results, since we may be
trying to chain to an error type result foo.bar.getError(). And the
existing logic had no way to handle results from other modules, so we
were missing key results like 'NSError'.
Eventually we'll want to bring back something like this that handles all
modules, but as a way to bump the priority of ErrorType results rather
than to filter out everything else.
rdar://problem/20985515
Swift SVN r28716
When the code completion token appears after throw keyword,
a set of visible decls and instances conforming _ErrorType are
recommended as completion.
Swift SVN r26565
