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
While trying to infer type for pattern always take result of
`getTypeForPattern` and `resolveTypeInExpressionContext` with
a grain of salt because both of these methods produce empty type
if type as-written or one of the sub-pattern types is incorrect.
Resolves: rdar://problem/60534522
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
Currently we always generate a new type variable for any pattern
(represented as `_` in the source), but in cases where it's a
sub-pattern of a typed pattern e.g. `let _: Foo = ...` it makes
more sense to pass a type to it directly otherwise type variable
allocated for any pattern gets disconnected from the rest of
the constraint system.
Now that these are stored in the TypeResolution object itself, and all callers that mutate flags create a new resolution object, this data can be derived from the resolution itself.
Add the appropriate assertions to ensure that the now-redundant options parameters are being kept in sync so they can be retracted.
The eventual goal is to have TypeResolution requestified.
