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
Currently absence of `subtyping` is the only problem detected and diagnosed specifically
for `inout` parameters, but there could be type mismatches in `inout` positions as well
and we can use `argument-to-parameter mismatch fix to detect and diagnose them.
When it comes to `@autoclosure` parameters we only detect and diagnose
mismatches related to invalid implicit conversions to pointer types. But
`@autoclosure` parameters just like regular ones can have type mismatches
as well which can be handled via recently introduced
`argument-to-parameter mismatch` fix.
In some situations where both the KeyPath and closure solutions for an expression with a keypath literal were valid, the type checker could not choose between them and Swift would emit an “ambiguous use” error. This change increase the typechecking score of the closure solution so that the typechecker will favor the KeyPath solution, preserving source compatibility for existing APIs.
Fixes rdar://problem/56131416.
This commit changes `getArgumentExprFor` to take
a ConstraintLocator argument from which to find
the argument list. This lets us properly handle
the case where we have a key path subscript
locator. In addition, this commit renames the
member to `getArgumentListExprFor` to make it
clear we're returning the argument list expression
rather than a single argument.
Resolves SR-11562.
Instead of materializing locator twice from the same builder per
missing argument, do it only once and use result to create argument
type variable and its "defaults to Any" constraint.
