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.
All callers can trivially be refactored to use ModuleDecl::lookupConformance()
instead. Since this was the last flag in ConformanceCheckOptions, we can remove
that, too.
Previously we were only connecting a closure
constraint to type variables from param decls that
it referenced. This worked fine up until we
started type-checking for-in statements entirely
in the constraint system, meaning that closures
can now reference type variables from the element
pattern.
Tweak the collection logic to consider vars too.
Resolves rdar://62339835
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
