Fix an oversight where syntactic checking was not performed on
any statements in a body of a multi-statement after successful
solution application.
Resolves: rdar://94049113
`fallthrough` requires both source and destination `case`
"preambles" be type-checked before it could be validated,
which means that solution application for `case` statements
in a `switch` has to be split in two - preamble first and
bodies afterwards.
Resolves: https://github.com/apple/swift/issues/59035
Resolves: rdar://93796211
Type finder is still allowed to walk into closures to find any
referenced variables, but it should bring external result type
into scope only if a particular `return` belongs to the same
closure as the element.
If a syntactic element references an external declaration (relative
to its own context), let's check whether it has any type variables,
and if so, replace them with errors to remove any possibility of
bringing external constraints into element's scope.
Resolves: rdar://92347054
Add ClosureExpr to the list of expressions we don't
walk into for the purposes of diagnosing trailing
closures in conditional initializers.
rdar://92521618
All variables without explicit initializers were considered to be
uninitialized which is incorrect because if a variable has a property
wrapper attached to it that wrapper needs its initializer type-checked,
for example:
```
@propertyWrapper
struct Wrapper {
var name: String
...
}
test {
@wrapper(name: "wrapper")
var v;
}
```
`v` gets initialized via a call to `Wrapper(name: "wrapper")`.
Resolves: rdar://91225620
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 ... }
```
Since constraint solver can now handle statements, patterns, and declarations,
it's possible to that ambiguity could be detected in a non-expression context,
for example - pattern matching in switch statements. Augment `diagnoseAmbiguity`
to accept overloads with non-expression anchors and diagnose them in order of
their appearance in a solution.
`TrailingClosureAmbiguityFailure::diagnoseAsNote()` is used by
`diagnoseAmbiguity` opportunistically, which means that anchor
could be a pattern or a statement condition element.
Referencing a member in pattern context is not a regular member reference,
it should use only enum element declarations, just like leading-dot syntax
does, so both locators should end with `pattern matching` element to indicate
that to the member lookup.
Resolves: rdar://90347159
Solution application target can have its declaration context differ
from one used for constraint system, since target could be e.g. a
pattern associated with pattern binding declaration, a statement or
a sub-element of one (e.g. where clause) used in a closure etc.
`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.
A local function can capture a variable that has been declared after it,
which means that type-checking such declaration in-order would trigger
sub-typecheck that would corrupt AST underness the solution application
walker.
Augment the constraint solver to fallback to implicit `~=` application
when member couldn't be found for `EnumElement` patterns because
`case` statement should be able to match enum member directly, as well
as through an implicit `~=` operator application.
Source compatibility workaround.
func test<T>(_: () -> T?) {
...
}
A multi-statement closure passed to `test` that has an optional
`Void` result type inferred from the body allows:
- empty `return`(s);
- to skip `return nil` or `return ()` at the end.
Implicit `return ()` has to be inserted as the last element
of the body if there is none. This wasn't needed before SE-0326
because result type was (incorrectly) inferred as `Void` due to
the body being skipped.
Resolves: rdar://85840941
With the argument list refactoring, it's no
longer sufficient to stop walking when we encounter
an explicit tuple or paren. Add an additional
check to stop walking when we encounter an explicit
argument list.
rdar://85343171
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.
