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.
Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
We'll need this to get the right 'selfDC' when name lookup
finds a 'self' declaration in a capture list, eg
class C {
func bar() {}
func foo() {
_ = { [self] in bar() }
}
}
If reference collection discovered at least `ErrorExpr` in the body
of a closure, let's fail constraint generation only if it's a
single-statement closure, decision about multi-statement closures
should be delayed until body is opened.
This helps code completion because `ErrorExpr` could belong to
a statement unrelated to a completion, so it wouldn't affect
its correctness in any way.
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
* WIP implementation
* Cleanup implementation
* Install backedge rather than storing array reference
* Add diagnostics
* Add missing parameter to ResultFinderForTypeContext constructor
* Fix tests for correct fix-it language
* Change to solution without backedge, change lookup behavior
* Improve diagnostics for weak captures and captures under different names
* Remove ghosts of implementations past
* Address review comments
* Reorder member variable initialization
* Fix typos
* Exclude value types from explicit self requirements
* Add tests
* Add implementation for AST lookup
* Add tests
* Begin addressing review comments
* Re-enable AST scope lookup
* Add fixme
* Pull fix-its into a separate function
* Remove capturedSelfContext tracking from type property initializers
* Add const specifiers to arguments
* Address review comments
* Fix string literals
* Refactor implicit self diagnostics
* Add comment
* Remove trailing whitespace
* Add tests for capture list across multiple lines
* Add additional test
* Fix typo
* Remove use of ?: to fix linux build
* Remove second use of ?:
* Rework logic for finding nested self contexts
If return type is a function, it's possible to return a closure
which can have some of its arguments unused in the body e.g.
`let _: () -> ((Int) -> Void) = { return { } }`
In this case resulting closure has to use its only parameter or
explictly ignore it by declaring `_ in`.
Instead, check them and their error handling right away.
In addition to fixing the crash in the radar, this also causes
us to emit unused variable warnings in functions containing
local functions.
Eventually, TC.definedFunctions should go away altogether.
Fixes <rdar://problem/53956342>.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
We previously allowed these closures to default to (), but be inferred
as other types as well, which means that we will find some expressions
to be ambiguous because we end up finding multiple viable solutions
where there is really only one reasonable solution.
Fixes: rdar://problem/42337247
Currently we always use 'FunctionResult' as a path element when matching
function result types, but closure result type is allowed to be implicitly
converted to Void, which means we need to be careful when to use
'FunctionResult' and 'ClosureResult'.
Resolves: rdar://problem/37790062
Calls involving single trailing closure arguments require special
handling because we don't have as much contextual information
about function/argument types as in with regular calls, which means
that diagnosing such situations only by `visitApplyExpr`
yields subpar results.
Resolves: SR-4836.
The "map into the right context" logic was only getting hit
if we didn't exit early to handle the lvalue case. Move it up
to the top of the function.
Fixes <https://bugs.swift.org/browse/SR-4369>.
rdar://problem/21193574 says that this warning dates back to when closure args before default args used to be considered as trailing closures. This is not the case anymore so Jordan suggested we remove the warning.
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
This reverts commit e172383e2f.
There were two problems with this commit:
- This was a source-breaking change and should have been feature-gated.
- It only addressed one narrow case of SE-0110.
Fixes <rdar://problem/28621719>.
