This simplifies the logic in `ide::typeCheckContextAt` and fixes an issue that prevent code completion from working inside variables that are initialized by calling a closure.
Fixes rdar://90455154 [SR-16012]
Fixes rdar://85600167 [SR-15495]
struct Generic<T> {
init(destination: T, isActive: Bool) { }
}
invalid {
Generic(destination: true, #^COMPLETE^#)
}
In this case, since `invalid { ... }` cannot be type checked.
`ExprContextAnalysis` tries to type check `Generic` alone which resolves
to bound `Generic` type with an unresolved type. Previously, we used to
give up the analysis when seeing unresolved type. That caused mis callee
analyis.
rdar://79092374
Previously, we weren’t suggesting argument labels of enum elements when doing an unresolved member completion. Treat `EnumElementDecl` similar to static `AbstractFunctionDecl`s to show their argument labels.
Fixes rdar://78780690 [SR-14689]
When matching an argument to a parameter list, if there is no matching
parameter, the argument list is not applicable to the parameters. In
such case, code completion should not suggest argument labels of the
function.
rdar://77867723
For example:
class Base {
init(_: Int) {}
convenience init(_: Int) { self.init() }
}
class Derived: Base {
convenience init(sub: Int) { self.init(sub) }
}
Derived(#^HERE^#
In this case, the call is type checked to 'Base.init(_:)' and 'Derived'
is wrapped with 'MetatypeConversionExpr' with type 'Base.Type'. We need
to look through it to get the 'TypeExpr' with 'Derived.Type'.
rdar://74233797
For a function and call like
```swift
func test(_: Foo..., yArg: Baz) {}
test(.bar, #^COMPLETE^#)
```
the parser matches the code completion token to the `yArg` with a missing label, because this way all parameters are provided. However, because of this we don’t suggest any variables that could belong the the previous vararg list.
To fix this, if we encounter such a situation (argument without label after vararg), manually adjust the code completion token’s position in params to belong to the vararg list.
Fixes rdar://76977325 [SR-14515]
The actual fix is to perform qualified lookup on a TypeExpr in `collectPossibleCalleesForApply`.
This changes the behaviour of some test cases in `complete_multiple_trailingclosure.swift`, which now provide argument labels. To make the choices suggested less verbose, I refined the parameter matching to only match trailing closures to parameters of function types.
In `INIT_FALLBACK_1` we technically shouldn't be suggesting `arg3` based on the matched argument types (the closure returns `Int` and the constructor with `arg3` requires the closure to return `String`), but AFAICT we aren't doing type-checking at this stage, so there's no way to rule it out.
Currently, if the code completion token is after a label that refers to a vararg, it is part of that VarargExpansionExpr, so we don’t suggest the subsequent parameter’s label.
Add special handling to detect this situation and suggest the parameter label.
Fixes rdar://76355192
Previously, we always assumed that the position in the arguments would match the position in the parameter, which isn’t true in case of defaulted arguments. Try matching parameters based on argument labels to give better completion results.
Fixes rdar://60346573
The `init` of `self.init` needs to be looked up on the Metatype of `self`, not on the type of `self` itself. We were already doing a similar special-casing for `super.init`, which I extened to also cover `self.init`.
Resolves rdar://36521732
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
At the every usage of 'collectPossibleReturnTypesFromContext()', the
closure must have been typechecked earlier. If the closure has no
valid type at this point, there's no chance to be type-checked by
re-typechecking.
rdar://problem/74430478
This bool was true only for single-expression closure and function bodies that
do not have an explicit `return` in the source. Rename it and its associated
methods, to avoid confusion with the hasSingleExpressionBody methods on
ClosureExpr and AbstractFuncDecl. Those don't care whether the expression was
explicitly written in the source or not.
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
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
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
