- Remove whole disjunction favoring which has no effect;
- Avoid creating separate disjunction for "inner" choices,
which is going to be flattened later anyway.
Instead of passing all of the information available in the diagnostic
to static functions, let's bring "default value" and "force unwrap"
fix-it logic under "missing optional unwrap diagnostic" umbrella.
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 overload-favoring code had a couple of different ways in which it
tried to figure out the parameter lists of a given declaration. Have
those all depend on ConstraintSystem::getEffectiveOverloadType(),
which deals with the various member/non-member cases uniformly.
When favoring particular constraints in a disjunction, don't remove
the old disjunction and create a new one---it's just churn in the
constraint system. Instead, favor the constraints that need it.
This technically flips the SR-139 test case from "too complex" to
being fast enough, but it's still fairly slow.
The disjunction partitioning logic was only used for the experimental
designated-types feature, but is generally useful. Unify the code
paths so we always do the partitioning, with only the designated-types
part being enabled/disabled by the flag.
The call-favoring code was creating a two-level disjunction, when would
then immediately get flattened into a single level. Instead, create a
single-level disjunction directly.
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.
Detect and fix closure parameter destructuring where
it's not currently allowed e.g. free standing closures
with contextual type `let _: ((Int, Int)) -> Void = { $0 + $1 }`
Implement support for querying the effective overload type for constructors
and fix a semi-related bug for methods returning dynamic Self, which I
had not accounted for.
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.
A declaration with an implicitly-unwrapped optional essentially has two
effective overload types, because the result might be optional or it might
have been forced. Disable computation of the effective overload type in this
case.
