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.
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.
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.
This patch improves the error message emitted when the capture list
contains an item that is a sub-field of a struct/class/etc....
If the closure capture did not include `weak` at the beginning, the
presence of a period would cause the if-chain to fall through the
identifier checking, resulting in an error message about expecting a
`weak` keyword. Instead, I've opted to accept the period at that stage
of parsing so that we can fall through to a better error message.
For the following code
```
{ [self.field] in ... }
```
instead of emitting
`expected 'weak', 'unowned', or no specifier in capture list`,
we now emit
`fields may only be captured by assigning to a specific name`
with a fix-it that changes the code to
```
{ [ field = self.field ] in ... }
```
`one-way` constraints disable some optimizations related to component
selection because they imply strict ordering. This is a problem for
multi-statement closures because variable declarations could involve
complex operator expressions that rely on aforementioned optimizations.
In order to fix that, let's move away from solving whole pattern binding
declaration into scheme that explodes such declarations into indvidual
elements and inlines them into a conjunction.
For example:
```
let x = 42, y = x + 1, z = (x, test())
```
Would result in a conjunction of three elements:
```
x = 42
y = x + 1
z = (x, test())
```
Each element is solved indepedently, which eliminates the need for
`one-way` constraints and re-enables component selection optimizations.
We've always emitted an error if we saw an implicit use of a self
parameter of class type from an escaping closure. In PR #35898, I fixed
this to also emit an error if the reference was to an explicit capture
of self that wasn't made in the current closure. That was causing
some source incompatibilities that we decided were too severe, so in
PR #38947 I weakened that to a warning when the diagnostic walk was
within multiple levels of closures, because I have always thought of
this as a fix to nested closures. However, this was the wrong condition
in two ways.
First, the diagnostic walk does not always start from the outermost
function declaration; it can also start from a multi-statement closure.
In that case, we'll still end up emitting an error when we see uses
of explicit captures from the closure when we walk it, and so we still
have a source incompatibility. That is rdar://82545600.
Second, the old diagnostic did actually fire correctly in nested
closures as long as the code was directly referring to the original
self parameter and not any intervening captures. Therefore, #38947
actually turned some things into warnings that had always been errors.
The fix is to produce a warning exactly when the referenced declaration
was an explicit capture.
Swift has diagnosed implicit uses of class-reference `self` in
escaping closures for a long time as potentially leading to reference
cycles. PR #35898 fixed a bug where we failed to diagnose this
condition in nested closures. Unfortunately, treating this as an
error has proven problematic because there's a lot of code doing
it. Requiring that code to be thoroughly stamped out before we
ship a compiler is just too much to ask. Stage the fix in by
treating it as a warning in Swift versions prior to 6.
As with the non-nested case, this warning can be suppressed by
explicitly either capturing `self` or spelling out `self.` in the
access.
Fixes rdar://80847025.
