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
- Handle cases where getArgumentLabelLocs().size() == 0
- Add some assertions to verify invariants
- Explicit handling of 'llvm::Optional' for 'getUnlabeledTrailingClosureIndex()'
- Avoid walking into nodes after the removing happens
rdar://problem/65556791
This used to cause duplicated results in call signature completions.
i.e.:
AlertViewController(#^HERE^# // 2 x (coder: NSCoder)
rdar://problem/65081358
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
1) Explicit TypeExpr nodes must be created with a TypeRepr node
2) Implicit TypeExpr nodes must be created with a contextual type
3) The typing rules for implicit TypeExpr simply opens this type
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
in typechecked AST. This is needed to correctly get the type of the
parsed expression when the expression is a calling to a method in super
class returning 'Self'.
rdar://problem/51504896
- In member completions, when 'callAsFunction' decls are found, suggest
call patterns
- In call pattern completions, fallback to search 'callAsFunction' if
the base type is not a function type
rdar://problem/59792682
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
- 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
