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.
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
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
The logic here could form AST loops due to passing
in `anchor` for the key path's parsed path.
However setting a parsed path here seems to be a
holdover from the CSDiag days, so set the path to
`nullptr` and rip out and the rest of the synthesis
and SanitizeExpr logic for it.
rdar://85236369
If underlying type of an optional chain has been marked as a hole,
e.g. due to a reference to an invalid or missing member, let's
propagate that information to object type of an optional that
represents a result of an optional chain.
Resolves: rdar://80941497
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
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.
AutoClosureExprs created by the constraint system used to be constructed
with the decl context of the constraint system itself. This meant that
autoclosures in expressions nested in closures would initially be
parented onto any enclosing functions rather than the deepest closure
context. When we ran capture analysis and lookup from inside of the body
of these nascent values, we would fail to find declarations brought into
scope by those parent closures. This is especially relevant when
pre-typechecked code is involved since captures for those declarations
will be forced before their bodies have been recontextualized. See
issue #34230 for why we need to force things so early.
The attached test case demonstrates both bugs: The former a bogus lookup
through the parent context that would incorrectly reject this otherwise
well-formed code. The latter is a crash in SILGen when the capture
computation would fail to note $0.
Use the decl context of the solution application target, which is always
going to be the deepest user-written closure expression available to us,
and therefore the deepest scope that can introduce capturable variables.
rdar://79248469
