When a CallExpr's callee is implicit (e.g. `callAsFunction`),
`fn->getEndLoc()` collapses to the call site's location, so the
bare-trailing-closure path could compute `lastLoc` at or past the
closure's start. The resulting `fixItReplaceChars(lastLoc,
closureRange.Start, ...)` produced a degenerate SourceRange that crashed
the Swift-syntax-aware diagnostic renderer when constructing
`Range<AbsolutePosition>`. Detect that case and fall back to a plain
insertion at the closure's start.
fixes rdar://170779809
This is a partial revert of https://github.com/swiftlang/swift/pull/87360
The change attempted to infer a concrete thrown error type onto
the closure but that leads to incorrect solutions when closure is
passed as an argument to an overloaded declaration because the
solver doesn't check whether calls in the body do throw the
expected type even with `FullTypedThrows` feature enabled
and so the safest option is still to assume un-typed `throws`
unless typed throws comes from a concrete contextual type.
Resolves: rdar://173132715
If we encounter a variable declared after its use within a closure,
we can fallback to using an outer result if present. This matches the
behavior outside of a closure and generally seems more consistent with
the behavior we have if we also find an inner result.
rdar://163656720
Previously we would allow these in Sema and diagnose them in SILGen,
but allowing them in Sema is unsound because it means the constraint
system ends up kicking interface type requests for declarations that
should be type-checked as part of the closure itself. Adjust the
name lookup logic to look through parent closures when detecting
invalid forward references.
For now we don't fallback to an outer result on encountering a
use-before-declaration to preserve the current behavior. I'm planning
on changing that in the next commit though.
rdar://74430478
`isThrowing` returns `true` for a function type that is `throws(Never)`
even though it's wrong, let's work around that until the underlying issue
is fixed.
In a typed throws context a throwing closure (as determined from the
body or an explicit `throws`) assumes an error type of the context that
is a subtype of `any Error`.
This is a carve out from `FullTypedThrows` feature that let's more
code that adopted typed throws to type-check without source compatibility
impact since without context a closure would still be using un-typed
throws and no additional inference of error type is done.
This fixes an ambiguity introduced by the stdlib change in
0f99458900.
Since (borrowing T) -> () and (T) -> () both convert to
each other, we could end up with ambiguous solutions where
neither one was better than the other. Generalize the
existing trick we use for labeled vs unlabeled tuples to
also strip off ownership specifiers and @convention(...)
from function types. This fixes the regression, as well
an existing FIXME in a test I added a while ago where
the same problem arises with @convention(block).
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
Ben Cohen
Pavel Yaskevich
Hamish Knight
Slava Pestov
Pavel Yaskevich
Cal Stephens
Jamie
bashir
Anthony Latsis
Mykola Pokhylets
Mike Ash
Holly Borla
Sophia Poirier