Currently `getPotentialBindingsForRelationalConstraint` doesn't
respect the fact that type of key path expression has to be a
form of `KeyPath`, instead it could eagerly try to bind it to
`Any` or other contextual type if it's only available
information.
This patch aims to fix this situation by filtering potential
bindings available for type variable representing type of
the key path expression.
Resolves: SR-10467
When type-checking a return statement's result, pass a new
ContextualTypePurpose when that return statement appears in a function
with a single expression. When solving the corresponding constraint
system, the conversion constraint will have a new ConstraintKind. When
matching types, check whether the constraint kind is this new kind,
meaning that the constraint is between a function's single expression
and the function's result. If it is, allow a conversion from
an uninhabited type (the expression's type) to anything (the function's
result type) by adding an uninhabited upcast restriction to the vector
of conversions. Finally, at coercion time, upon encountering this
restriction, call coerceUninhabited, replacing the original expression
with an UninhabitedUpcastExpr. Finally, at SILGen time, treat this
UninhabitedUpcastExpr as a ForcedCheckedCastExpr.
Eliminates the bare ConstraintSystem usage from
typeCheckFunctionBodyUntil, ensuring that the same code path is followed
for all function bodies.
Optimized for the common case where a single expression in a function
body is an implicit return and attempt to solve the constraint system
featuring that assumption. If that fails, attempt to solve a second
constraint system where no conversion type is provided. If that
succeeds and the expression's type is uninhabited, then remove the
return and proceed. If that fails, show the diagnostics from the
failure to solve the first constraint system.
- preferred dyn_cast to is and get
- restored insertion of () on bare return statements
- used dyn_cast not dyn_cast_or_null when the argument is non-null
- used getSingleExpressionBody accessor during second AST modification
- eliminated erroneous access through null reference
When the property delegate type overrides the delegate value by providing
a delegateValue property, name the backing storage $$foo and make it private.
If an IBOutlet property is public private(set), it's interface only has a
getter. Consuming this interface was triggering a diagnostic that IBOutlet
properties must be mutable. This patch bypasses this check for module
interfaces.
Resolves rdar://problem/49856177
When a custom attribute is given a direct initializer, save and re-use
the initializer context we create so that it can be associated with the
enclosing pattern binding. Fixes assertions involving explicit closures
in property delegates.
The initialization of an instance property that has an attached
property delegate involves the initial value written on the property
declaration, the implicit memberwise initializer, and the default
arguments to the implicit memberwise initializer. Implement SILGen
support for each of these cases.
There is a small semantic change to the creation of the implicit
memberwise initializer due to SE-0242 (default arguments for the
memberwise initializer). Specifically, the memberwise initializer will
use the original property type for the parameter to memberwise
initializer when either of the following is true:
- The corresponding property has an initial value specified with the
`=` syntax, e.g., `@Lazy var i = 17`, or
- The corresponding property has no initial value, but the property
delegate type has an `init(initialValue:)`.
The specific case that changed is when a property has an initial value
specified as a direct initialization of the delegate *and* the
property delegate type has an `init(initialValue:)`, e.g.,
```swift
struct X {
@Lazy(closure: { ... })
var i: Int
}
```
Previously, this would have synthesized an initializer:
```swift
init(i: Int = ???) { ... }
```
However, there is no way for the initialization specified within the
declaration of i to be expressed via the default argument. Now, it
synthesizes an initializer:
```swift
init(i: Lazy<Int> = Lazy(closure: { ... }))
```
When a property has an attached property delegate, a backing storage
property of the corresponding delegate type will be
synthesized. Perform this synthesis, and also synthesize the
getter/setter for the original property to reference the backing
storage property.
The initializer associated with a lazy property should not be executed
directly, because it is subsumed by code synthesized into the
getter. Generalize the terminology here so we can re-use this path for
property delegate initialization.
A property with an attached delegate can be initialized in one of two ways:
* By directly specifying initialization arguments on the attribute,
e.g., "@SomeDelegate(x: 17, y: 42) var a".
* By initializing the original property itself, which goes through the
delegate type's init(initialValue:) initializer, e.g.,
"@Lazy var x = 17".
Implement support for both forms of initialization, including type
inference and checking for inconsistencies (e.g., if the annotation on
the property type doesn't match what the delegate type would
provide).
A custom attribute can be resolved to a property delegate type. Allow
this for property declarations (only), and diagnose the various places
where properties cannot have property delegates.
Referencing (instance or static) methods in the key path is not
currently allowed, solver should be responsible for early detection
and diagnosis of both standalone e.g. `\.foo` and chained
e.g. `\.foo.bar` (where foo is a method) references in key path
components.
```swift
struct S {
func foo() -> Int { return 42 }
}
let _: KeyPath<S, Int> = \.foo
```
Resolves: rdar://problem/49413561
