Currently we check that the fixes share the same anchor, however this
doesn't account for the case where, given an ApplyExpr, one fix is
anchored on its function expr, and another is anchored on the apply
itself (because the former fix might be looking at the callee's
requirements, and the latter fix might be looking at an argument of
the call).
This commit changes the logic such that we check that fixes share the
same callee locator, which covers the above case. In addition, now
that we have the callee locator, we can use this to find the overload
directly.
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a
locator that describes the callee of a given expression. This function
is then used to replace various places where this logic is duplicated.
This commit also changes the conditions under which a ConstructorMember
callee locator is formed. Previously it was formed for a CallExpr with a
TypeExpr function expr. However, now such a locator is formed if the
function expr is of AnyMetatypeType. This allows it to be more lenient
with invalid code, as well as work with DotSelfExpr.
Resolves SR-10694.
Introduce an attribute @_disfavoredOverload that can be used to state
that a particular declaration should be avoided if there is a
successful type-check for a non-@_disfavoredOverload. It's a way to
nudge overload resolution away from particular solutions.
The ConstraintSystem class is on the order of 1000s of bytes in size on
the stacka nd is causing issues with dispatch's 64k stack limit.
This changes most Small data types which store data on the stack to non
small heap based data types.
Instead of always requiring a call to be made to pass argument
to `@autoclosure` parameter, it should be allowed to pass argument
by value to `@autoclosure` parameter which can return a function
type.
```swift
func foo<T>(_ fn: @autoclosure () -> T) {}
func bar(_ fn: @autoclosure @escaping () -> Int) { foo(fn) }
```
Enhance call-argument matching to reject trailing closures that match up
with parameters that cannot accept closures at all.
Fixes rdar://problem/50362170.
Detect situations where key path doesn't have capability required
by the context e.g. read-only vs. writable, or either root or value
types are incorrect e.g.
```swift
struct S { let foo: Int }
let _: WritableKeyPath<S, Int> = \.foo
```
Here context requires a writable key path but `foo` property is
read-only.
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
We have a systemic class of issues where noescape types end up bound to
type variables in places that should not. The existing diagnostic for
this is ad-hoc and duplicated in several places but it doesn't actually
address the root cause of the problem.
For now, I've changed all call sites of createTypeVariable() to set the
new flag. I plan on removing enough occurrences of the flag to replicate
the old diagnostics. Then we can continue to refine this over time.
Implicit argument expression was necessary to generate keypath
constraint which is used to validate a choice picked for the member.
But since read-only check has been factored out it's now possible
to validate choice directly in combination with new 'keypath dynamic lookup'
locator associated with member type variable which represents result
of the dynamic lookup.
Instead of waiting until the overload is attempted, let's figure out
if there is anything wrong with it beforehand and attach a fix to the
"bind overload" constraint representing it.
Further simplify `addOverloadSet` and move "outer" candidate handling
to the only place where it comes up - `simplifyMemberConstraint`.
Also move constraint generation for choices into a separate method.
This is a stepping stone on the path to enable attaching fixes to
the overload choices.
- Remove whole disjunction favoring which has no effect;
- Avoid creating separate disjunction for "inner" choices,
which is going to be flattened later anyway.
When we’re trying to find the overload set corresponding to a particular
type variable, look through “optional object of” constraints that represent
the use of ? binding or ! forcing. This allows us to find overload sets
when referring to, e.g., @objc optional protocol requirements.
This narrow favoring rule makes more sense as part of disjunction
partitioning, because it is not dependent on the use site at all and
should only kick in when other options fail.
The "common type" optimization isn't really buying us anything at this
point, because we're not able to make much use of the common structure
often enough. Revert the "common type" optimization for now... I'll
bring it back when there's enough optimization infrastructure around
it to make it compelling.
The walker that was setting argument labels was looking through ! and ?
postfix expressions, but the lookup code itself was not, leading to missed
opportunities for filtering based on argument labels. Generalize the
transformation that maps from the function expression down to the locator
for which we will retrieve argument labels.
When simplifying a function application constraint, check the argument
labels for that application against the disjunction containing the overload
set, disabling any overloads with mis-matching labels. This is staging for
several different directions:
* Eliminating the argument label matching from performMemberLookup, where it
does not belong
* More aggressively filtering the overload set when we have some concrete
information about argument types
* Identifying favored constraints when we have some concrete information
about argument types
At present, the only easily-visible effect of this change is that
we now properly handle argument label matching for non-member functions.
Constraint generation for function application expressions contains a simple
hack to try to find the common result type for an overload set containing
callable things. Instead, perform this “common result type” computation
when simplifying an applicable function constraint, so it is more
widely applicable.
Given an overload set, attempt to compute a "common type" that
abstracts over all entries in the overload set, providing more
structure for the constraint solver.
