Currently we only produce a fix if function type doesn't have any
parameters, but it should also account for function having defaults
for all of its parameters which would still allow for nullary call.
Don't attempt disjunction optimization in "diagnostic mode"
because in such mode we'd like to attempt all of the available
overloads regardless of of problems related to missing or
extraneous labels and/or arguments.
If we're referencing AnyObject and we have argument labels, put
the argument labels into the name: we don't want to look for
anything else, because the cost of the general search is so high.
The rule is that if there is a label it's evidence that the
intent is to reference a particular overload where that label
would match, so let's try to de-prioritize fixes for overloads
where labels didn't line up correctly and suggestion is to
remove certain labels vs. fixes when labels did line up but
types or requirements didn't.
Since `areConservativelyCompatibleArgumentLabels` is only used by
`simplifyAppliedOverloads` now, it's easy to pass arguments directly
instead of trying to form them from list of labels.
This helps with:
- Diagnostics because solver would get more choices to work with
in diagnostic mode;
- Avoid adding the same overload multiple times
(retry after label mismatch and no viable candidates);
- Unify overload handling/filtering in `simplfyAppliedOverloads`.
Simplify the interface to gatherConstraints() by performing the
uniquing within the function itself and returning only the resulting
(uniqued) vector of constraints.
If `subscript(dynamicMember:)` is unviable because it's either
an instance method referenced on type or static method
referenced on an instance of type, attempting dynamic
member lookup would be incorrect since it's unclear
what is intended.
Resolves: rdar://problem/48994658
Currently if there is a conditional conformance to a type marked
as `@dynamicMemberLookup` with member that shadows one accessible
through dynamic lookup we'd report an error if that conformance
has not been satisfied.
Better behavior would be to consider dynamic member lookup and
if that fits let the expression type-check.
Resolves: rdar://problem/52779809
Currently only valid way to form keypath subscript is to use `keyPath:`
label in subscript invocation, so let's avoid adding keypath overload
choice to every subscript lookup and instead only add it when it could
potentially match.
This among other things greatly helps diagnostics because sometimes
`keypath application` becomes the only choice even although it's
not really viable, which impedes member reference diagnostics.
While trying to figure out whether there is a missing or extraneous
property wrapper reference, let's not try to fix any generic argument
mismatches associated with wrapper or wrapped types, otherwise the
fix is going to be incorrect.
Additionally, refactor some of the logic for the original add $ diagnostic
so that a lot of logic can be shared between the two. Also rename the
original fix and diagnostic to better reflect their purpose.
Extend use of "instance member on type" fix to cover potentially
invalid partial applications, references to instance members on
metatypes, and remove related and now obsolete code from `CSDiag`.
Resolves: [SR-9415](https://bugs.swift.org/browse/SR-9415)
We would previously fail to match something like (C<$T1> & P) against
(C<Int> & P) when the constraint kind was <= Subtype, because we would
fall back to a type equality test in that case.
However, this was only valid for protocol compositions without superclass
constraints since the superclass could contain a type variable on one
side of the constraint.
Fix this by adding support for protocol composition types to
matchDeepEqualityTypes().
