Revert "Remove properties from AST nodes"
This reverts commit e4b8a829fe.
Revert "Suppress more false-positive 'self is unused' warnings"
This reverts commit 35e028e5c2.
Revert "fix warning annotation in test"
This reverts commit dfa1fda3d3.
Revert "Permit implicit self for weak self captures in nonescaping closures in Swift 5 (this is an error in Swift 6)"
This reverts commit 94ef6c4ab4.
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
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.
