Use the PatternBindingInitializer context if we
have one. This also uncovered a parser issue where
we would mistakenly create a
PatternBindingInitializer in top-level code after
parsing the initializers.
Start classifying all potential throw sites within a constraint
system and associate them with the nearest enclosing catch node. Then,
determine the thrown error type for a given catch node by taking the
union of the thrown errors at each potential throw site. Use this to
compute the error type thrown from the body of a `do..catch` block
within a closure.
This behavior is limited to the upcoming feature `FullTypedThrows`.
Follow-up to https://github.com/apple/swift/pull/70148
Just like with arrays it's advantageous to favor dictionary
literals over disjunctions to bind the elements together and
enable inference across elements and, as a consequence,
type pruning.
Resolves: rdar://119040159
If array literal type is not delayed and doesn't have any type variables
associated with it, let's prefer it over a disjunction to facilitate
type propagation through its `Element` type to element expressions.
Resolves: rdar://118993030
Since key path root is now transitively inferred. Key path type
inference can be delayed until key path is resolved enough to
infer its capability.
This solves multiple problems:
- Inference fully controls what key path type is bound to;
- KeyPath constraint simplification doesn't have to double-check
the capability and attempt to re-bind key path type;
- Custom logic to resolve key path type is no longer necessary;
- Diagnostics are improved because capability and root/value type
mismatch are diagnosed when key path is matched against the
contextual type.
Adds `diagnoseForAmbiguity` to `AllowInvalidPropertyWrapperType` fix
because it could be attached to a closure parameter that has ambiguity
in the body so it has to be diagnosable in ambiguous contexts.
Resolves: rdar://116522161
Move some of the checks from the constraint simplification into
`inferKeyPathLiteralCapability` and start using it for both
inference and constraint simplification.
This flag makes it easier to determine what binding to produce
from the default. In cases where some of the member references
are invalid it's better to produce a placeholder for a key
path type instead of letting the solver to attempt to fix more
contextual problems for a broken key path.
The types with missing conformances are allowed to appear in a
valid solution but such solutions should be ranked lower comparing
to solutions fewer or without them.
Type-checker separates `where` clause from `for-in` statement's pattern/sequence
in closure contexts which works as a natural barrier for inference, but
for-in statements in i.e. function bodies still type-check all of the for-in
statement components together, so we need to make sure that where clause
cannot be used to infer a type of the pattern before its sequence expression.
Resolves: rdar://117220710
