This is because we already emit a diagostic to tell the user that the property's type does not match the wrappedValue type, so this diagnostic can be a bit confusing especially because the initializer is synthesized
If the last parameter is defaulted, there might be
an attempt to use a trailing closure with previous
parameter that accepts a function type e.g.
```swift
func foo(_: () -> Int, _ x: Int = 0) {}
foo { 42 }
```
Resolves: rdar://problem/55102498
ProtocolConformanceRef already has an invalid state. Drop all of the
uses of Optional<ProtocolConformanceRef> and just use
ProtocolConformanceRef::forInvalid() to represent it. Mechanically
translate all of the callers and callsites to use this new
representation.
Resolve a cycle caused by overload resolution considering recursive
static candidates where before it would silently reject them. In
a world before the InterfaceTypeRequest, the overload resolution
machinery would attempt to validate the declaration and would recieve
a bad answer. This caused circular candidates to be ignored as a side
effect. This behavior was partially restored by the fixes in #27725 and #27668
but that isn't enough for recursive static variables. Even if it were,
the constraint fix kind doesn't make sense.
Luckily, the right answer is to just reject recursive static VarDecl
candidates entirely.
Addresses rdar://56410015
Key path components can reference an invalid or missing member
just like regular expressions, so we need to account for that
while trying to simplify key path constraint.
It's possible to find a suitable overload choice for
key path application through keypath dynamic member
lookup and assertion inside `addKeyPathApplicationRootConstraint`
should account for that.
Resolves: rdar://problem/56350060
If there are more arguments than parameters, let's fix this by
ignoring (if possible) or removing extraneous arguments. Ignored
arguments could default to `Any` if they don't get any other
contextual type.
This lets us add a constraint to the system with an associated fix.
Unlike `addUnsolvedConstraint`, this will attempt to immediately
simplify the constraint, producing an unsolved constraint if necessary.
Array-to-pointer should only be used for such conversions. This isn't
currently an issue as we short-circuit disjunctions upon successfully
solving an array-to-pointer conversion. However this would become an
issue if only inout-to-pointer was viable.
We would previously consider the VarDecls bound by a particular pattern
binding initializer context when performing overload resolution. This
would lead to circular validation. Validation was tacitly breaking the
cycle by returning an error type (but, crucially, not setting that
interface type). Instead, pre-reject circular candidates.
This greatly improves the diagnostic we emit here in truly circular
cases since we can ride on `UR_InstanceMemberOnType` to yield
struct PatternBindingWithTwoVars2 { var x = y, y = 3 }
// cannot use instance member 'y' within property initializer; property initializers run before 'self' is available
