If a closure doesn't have a contextual type inferred yet it should
be delayed in favor of already resolved closure conjunction because
"resolving" such a closure early could miss result builder attribute
attached to a parameter the closure is passed to.
Partially resolves https://github.com/apple/swift/issues/67363
Unify the duplicate pattern var checking in
pattern resolution such that it is always called
no matter how we end up type-checking the pattern.
This avoids incorrectly allowing duplicate pattern
vars to compile for patterns as a part of
multi-statement closures.
It's possible for out-of-scope type variable to be the type of
declaration if such declaration is recursively referenced in
the body of a closure located in its initializer expression.
In such cases type of the variable declaration cannot be connected
to the closure because its not known in advance (determined by the
initializer itself).
Resolves: https://github.com/apple/swift/issues/63455
Currently solver picks the first conjunction it can find,
which means - the earliest resolved closure. This is not
always correct because when calls are chained closures
passed to the lower members could be resolved sooner
than the ones higher up but at the same time they depend
on types inferred from members higher in the chain.
Let's make sure that multi-statement closures are always
solved in order they appear in the AST to make sure that
types are available to members lower in the chain.
Revert "Remove properties from AST nodes"
This reverts commit e4b8a829fe.
Revert "Suppress more false-positive 'self is unused' warnings"
This reverts commit 35e028e5c2.
Revert "fix warning annotation in test"
This reverts commit dfa1fda3d3.
Revert "Permit implicit self for weak self captures in nonescaping closures in Swift 5 (this is an error in Swift 6)"
This reverts commit 94ef6c4ab4.
If a variable with attached property wrapper has an initializer
expression it could be modified by implicit wrapper application,
if there is no initializer - one would be synthesized by the
compiler (without arguments). In both cases target has to be
pre-checked before constraints are generated for it.
Resolves: https://github.com/apple/swift/issues/61024
Using `computeWrappedValueType` is incorrect because
that return a type of the wrapped variable and not
the *wrapper* variable (one that starts with `_`).
Resolves: https://github.com/apple/swift/issues/61017
`MissingMemberFailure::diagnoseInLiteralCollectionContext`
should verify that a parent (or parent of a parent) expression
is indeed a collection expression instead of checking types.
Resolves: rdar://91452726
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Avoid mutating case label items while solving, instead let's use types
recorded in the constraint system for each pattern variable and use
that for var reference in the case body. This also helps to detect
and diagnose type conflicts while solving.
