This never worked correctly and would crash in SILGen, ban the use
of placeholder types. While here, ensure we replace any ErrorTypes
with holes when solving the closure in the constraint system.
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
This test creates an object then checks a weak reference to that object on a background thread. It was doing this check after 10ms, and any small hiccup could potentially delay the object's destruction enough to spuriously fail.
Rearrange the test to check the weak reference in a loop for several seconds before giving up. This makes it very fast on success (it's done the moment it sees nil) while being robust against up to several seconds of delay in destroying the object if that happens.
rdar://149868181
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
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`.
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
