If all solutions point to the same overload choice that needs
re-labeling it's safe to diagnose it as if there was no ambiguity
because the call site is static.
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
Stop pretending that an optional requirement is immutable via the `StorageImplInfo` request.
This approach has lead astray the conformance checker and may have had a negative impact
on other code paths, and it doesn't work for imported declarations because they bypass the
request. Instead, use a forwarding `AbstractStorageDecl::isSettableInSwift` method
that special-cases optional requirements.
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.
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
