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.
Rather than using a specialized matching rule in the type checker that
depends on having default arguments in types, use call argument
matching consistently.
Note #1: This (correctly) breaks some existing code that depends on
inferring a parameter type of () for a single-argument parameter from
a no-argument function type().
Note #2: This pessimizes a code completion test, where the code
completion engine seems to depend on some quirks of argument
matching. The "type relationship" matching needs non-trivial work.
We have code for pruning unlikely overloads, but when it pruned all
overloads it was treating that as if there was nothing to complete.
Instead, fallback to postfix-expr-begin.
We should also figure out why we're not getting any viable types here,
but we need to handle failure gracefully.
rdar://problem/24356118
Fixes a use-after-free when doing code-completion where the expected
type is an array of generic type (or any bound generic type).
takeArray<T>(x: [T]) {}
takeArray(foo.<here>)
rdar://problem/24521470
When not completing a full call pattern for the first argument, such as
here:
foo(<here>, arg2: blah)
we now show the argument label if appropriate.
For rdar://problem/22804670
Swift SVN r32774
Since other module results are cache, manually add the type names of
expected nominal types in call arguments so that we can get the type
relationship correct
For rdar://problem/22271094
Swift SVN r31959
