This hit an assertion I was trying to add to make
sure we don't try to recursively type-check when
type-checking a closure. Currently we can end up
type-checking the initializer for `x` while generating
constraints for the closure due to the fact that we
eagerly compute the interface type for the backing
lazy storage var. We ought to make that computation
lazy, but in the mean time, add this test case.
Unfortunately we've encountered another source
breaking case here:
```
class C {
func method() {}
func foo() {
Task { [weak self] in
Task {
method()
}
}
}
}
```
In 5.10 we'd only do the unqualified lookup for
`self` when directly in a `weak self` closure,
but with the implicit self rework, we'd start
using the `weak self` here, leading to a
type-checker error.
At this point, adding more edge cases to the
existing logic is going to make things much more
complicated. Instead, reinstate the 5.10 implicit
self lookup behavior and diagnostic logic,
switching over to the new logic only under Swift 6
mode.
rdar://129475277
In 5.10 we warned on this:
```swift
func bar(@_implicitSelfCapture _ fn: @escaping () -> Void) {}
class C {
func foo() {
bar { [weak self] in
foo()
}
}
}
```
But with the implicit self rework, this accidentally
became an error. Fix it to ensure we continue to
warn until Swift 6 mode.
rdar://128941797
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.
