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.
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.
Introduce 'TypeCheckSingleASTNode' mode that only type checks single body
element and dependent necessities (i.e. referencing ValueDecls and their
dependencies).
Renamed swift::typeCheckAbstractFunctionBodyAtLoc() to
swift::typeCheckASTNodeAtLoc(DeclContext *, SourceLoc). That type checks
innermost 'ASTNode' at the location. Also, 'TypeCheckSingleASTNode' mode
skips type checking any "body" of the node (i.e. BraceStmt elements for
function body, if statement body, closure body, etc.)
Added on-demand type checking using it:
- VarDecl in TapExpr
- ParamDecl in ClosureExpr
- Return type of ClosureExpr
- Binding value in control statements
(e.g. ForEachStmt, SwitchStmt, DoCatchStmt, etc.)
rdar://problem/63932852
func foo() {}
let a: Int = #^HERE^#
Previously, we marked 'foo()' as 'NotRecommented' because 'Void' doesn't
have any member hence it cannot be 'Int'. But it wass confusing with
'deprecated'.
Now that we output 'typerelation' which is 'invalid' in this case. So clients
can deprioritize results, or even filter them out.
rdar://problem/57726512
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
When completing inside tuple expressions, the context tuple type may
have fewer number of elements. In such cases, we cannot provide the
expected type.
rdar://problem/61668779
Call arguments sometimes affect the inference for the generic parameters of the
type expression. When we want to show all initializers from all
extensions, we do not want to infer any generic arguments.
rdar://problem/53516588
instead of the pre-typechecked type and the referenced decl in the AST
so that we can suggests all overloads even if it happen to be
typechecked to a method. For example
struct MyType {
func foo() {}
func foo(_ int: Int) {}
func foo(name: String, value: String) {}
}
func test(val: MyType) {
value.foo(#^COMPLETE^#)
}
In this case, the call is typechecked to 'MyType.foo(_:)', but we want
to suggest all overloads.
rdar://problem/59285399
let _: [Foo] = [
.create(str: Int)
.create(#^COMPLETE^#)
]
Previously, this completion used to fail because the array expression
isn't typechecked. We need to analyze the context type of the array
literal first, that defines the type of the unresolved member
expression.
rdar://problem/50696432
struct Wrap<T> {
func method<U>(_ fn: (T) -> U) -> Wrap<U> {}
}
func testGenricMethodOnGenericOfArchetype<Val>(value: Wrap<Val>) {
value.method(#^HERE^#)
}
In this case, the type of value is `Wrap<Val[archetype]>`.
`Type::getTypeOfMember()` for 'method' method returns
`( (Val[archetype]) -> U[generic param]) -> Wrap<U[generic param]>`
which crashs 'mapTypeIntoContext()' because it already hass archetype.
rdar://problem/52386176
```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
To return accurate type of the expression.
i.e.
MyType.foo(#^COMPLETE^# // -> (MyType) -> (args...) -> Result
MyType().foo(#^COMPLETE^# // -> (args...) -> Result
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.
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
For:
class MyClass {
func foo(x: SomeType)
func foo(x: OtherType)
}
func test(obj: MyClass) {
obj.foo(x: <HERE>)
}
Type checker doesn't keep overloaded choices for 'obj.foo' in the AST
after typechecking. Code completion need to lookup members to collect
possible parameter types.
(and TupleExpr at non-call argument position).
Now, unresolved member completion in array literal should work.
Also, Don't calculate convertibility to 'Any' type. That would be a
noise to type relation because anything is convertible to 'Any'.
rdar://problem/43302814
Previously, local decls in trailing closure didn't show up if the
closure had preceding arguments and the completion was triggered at
beginning position of expression context. like:
funcName(x: arg1) {
var localVar = 12
if <HERE>
}
The completion mode used to be overwritten in 'completeCallArg()' which
is called from 'parseExprCallSuffix(). We should detect completion for
immediate argument position in 'parseExprList()'.
rdar://problem/41869885
LLVM r336847 changed FileCheck's CHECK-DAG feature to stop supporting
overlapping matches. I already fixed one test by invoking FileCheck with the
-allow-deprecated-dag-overlap option, but it turns out there are a bunch
more of them. This change applies the same workaround to all of them.
For call argument completion, if the expected type and completion result type are
both GenericTypeParameterTypes, comparing them doesn't make sense we can't account
for their different contexts at this point in the code, and hit assertions in the
constraint solver if we try.
For now, don't attempt to add a type relation for this case.
Resolves rdar://problem/38153332.
This was caused by two separate issues:
1. If given a function type with an IUO return, it would add function call
completions, set Done=true, and then progress to some logic to add
completions for the unwrapped type of optionals. That code would check if
the corresponding decl has the IUO attribute set and, if it was but couldn't
be unwrapped, assert. For function types, it now early exits after adding
call completions.
2. If given the type of a bound (`blah?.`) or forced (`blah!.`) optional,
the type is non-optional and can't be unwrapped and the decl still has the
IUO so it asserts. Refined the assertion to account for this case.
Resolves rdar://problem/38188989.
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
When completing
Foo(<here>
We will now provide
bar: <#value#>
instead of
bar: <#value#>)
Inserting the rparen caused some problems in practice:
* the old behaviour optimized for typing Foo(<complete> instead of
Foo(<complete>), which can conflict with user behaviours or ...
* in editors with automatic brace-matching, we often conflicted with the
editor, leading to extraneous closing parens
And in general, it is much more predictable for tooling to either insert
matching ( and ) or to not insert either. While this change may not be
ideal For users of editors that do not do automatic brace-matching, I
believe it is still better overall to have to type a missing paren than
to have to delete an extraneous one.
rdar://31113161
The original hope was we could make these heuristics really good, but
since that is not currently in sight (and may never be), we want to be
able to turn them off. For now, just plumb through an internal flag to
control the behaviour. A future change will customize the behaviour in
SourceKit.
rdar://31113161
When we are type-checking calls, subscripts, or other call-like
expressions, use the argument labels provided by the various
expression nodes rather than those encoded in the tuple type. This
means that argument label matching now matches the callee
declaration's argument labels against the argument labels, without
relying on encoding the argument labels within types in the AST.
This refactor is a stepping stone torward SE-0111.
