VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
Before 09db2902d2, the function builder
transform used to try to detect when the builder type wasn't fully
resolved. In such a case, rather than fail the solution set as we do
currently, it would construct a null TypeLoc, then stash the type-
variable-laden builder type inside of a TypeExpr and rely on CSGen
to reinterpret that as a request to read the stashed type as it was
constructing the rest of the system. This used to rely on the ability to construct
an implicit TypeExpr node with a null type but now such a thing is
banned by the TypeExpr interface.
Instead, we have to detect this case and construct an *explicit*
TypeExpr node pointing to all the usual fake data. This node's type will
be used to resolve the build* member, but the final applied type of the
node will be the builder type we stashed earlier - hopefully with
outstanding type variables solved.
rdar://65116204
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
Avoid solving constraint system if there's only one viable overload.
This should also avoids a crash we are seeing in
'candidates.size() == 1' branch in the constraint system.
rdar://problem/64636688
Currently `generateInitPatternConstraints` assumes that all
patterns have types but it's not the case for patterns that
e.g. reference unknown types or have other structural issues.
Let's fail `generateInitPatternConstraints` if constraint
generation fails.
Resolves: rdar://problem/64157451
Instead of special casing argument-to-parameter matching for
object literal expressions, let's allow constraint system to
lookup a witness initializer and apply it to the given set
of arguments.
This also simplifies constraint application because
`coerceCallArguments` could be used to form type-checked
argument expression.
In `ConstraintGenerator::visitDeclRefExpr` instead of using
`getInterfaceType()` for unknown type and later mapping it into
context, let's use `getType()` which does that interally, that
allows to detect presence of error types in resulting type and
abort constraint generation.
Generalize the code used to generate constraints and apply solutions to
PatternBindingDecls so that it is handled directly by the constaint
system and solution, respectively, rather than as part of the function
builder transform. No functionality change, but this is a cleaner
abstraction.
For example for:
funcName(base.<HERE>)
Wrap 'base' with 'CodeCompletionExpr' so that type checker can check
'base' independently without preventing the overload choice of 'funcName'.
This increases the chance of successful type checking.
rdar://problem/63965160
Single-expression closures have always been traversed differently
from multi-statement closures. The former were traversed as if the
expression was their only child, skipping the BraceStmt and implicit
return, while the later was traversed as a normal BraceStmt.
Unify on the latter treatment, so that traversal
There are a few places where we unintentionally relied on this
expression-as-child behavior. Clean those up to work with arbitrary
closures, which is an overall simplification in the logic.
Introduce a new predicate, shouldTypeCheckInEnclosingExpression(), to
determine when the body of a closure should be checked as part of the
enclosing expression rather than separately, and use it in the various
places where "hasSingleExpressionBody()" was used for that purpose.
Instead of assuming type of its sub-pattern `is` should be able
to infer type from context and then propagate that to the sub-pattern
via conversion. This enables support for patterns like `.foo(_ as Foo)`
where `is` would have a type different from `_` which gets inferred
from associated value of `foo` and converted to `Foo` that becomes
a type of `_` pattern.
Resolves: rdar://problem/63510989
