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
If a closure doesn't have a contextual type inferred yet it should
be delayed in favor of already resolved closure conjunction because
"resolving" such a closure early could miss result builder attribute
attached to a parameter the closure is passed to.
Partially resolves https://github.com/apple/swift/issues/67363
It's possible for out-of-scope type variable to be the type of
declaration if such declaration is recursively referenced in
the body of a closure located in its initializer expression.
In such cases type of the variable declaration cannot be connected
to the closure because its not known in advance (determined by the
initializer itself).
Resolves: https://github.com/apple/swift/issues/63455
Currently solver picks the first conjunction it can find,
which means - the earliest resolved closure. This is not
always correct because when calls are chained closures
passed to the lower members could be resolved sooner
than the ones higher up but at the same time they depend
on types inferred from members higher in the chain.
Let's make sure that multi-statement closures are always
solved in order they appear in the AST to make sure that
types are available to members lower in the chain.
If a variable with attached property wrapper has an initializer
expression it could be modified by implicit wrapper application,
if there is no initializer - one would be synthesized by the
compiler (without arguments). In both cases target has to be
pre-checked before constraints are generated for it.
Resolves: https://github.com/apple/swift/issues/61024
Using `computeWrappedValueType` is incorrect because
that return a type of the wrapped variable and not
the *wrapper* variable (one that starts with `_`).
Resolves: https://github.com/apple/swift/issues/61017
`MissingMemberFailure::diagnoseInLiteralCollectionContext`
should verify that a parent (or parent of a parent) expression
is indeed a collection expression instead of checking types.
Resolves: rdar://91452726
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Avoid mutating case label items while solving, instead let's use types
recorded in the constraint system for each pattern variable and use
that for var reference in the case body. This also helps to detect
and diagnose type conflicts while solving.
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
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
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.
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
Hamish Knight
Pavel Yaskevich
Slava Pestov
Michael Gottesman
Pavel Yaskevich
Alex Hoppen