Unresolved member lookup is allowed to perform implicit optional
unwrap of a base type to find members. Previously if there were
any members directly on `Optional`, lookup would stop there. But
since SR-13815 it became possible for solver to attempt members
found on unwrapped type even if there are viable ones on
`Optional` as well.
New score kind has been introduced to guard against possible ambiguities
with new scheme - `SK_UnresolvedMemberViaOptional`. It's used very
time member found via base type unwrap is attempted. Unfortunately,
doing so can lead to behavior changes in existing code because it's
possible that base was wrapped into optional implicitly based on
context e.g. unresolved member passed in as an argument to a parameter
of optional type.
To fix situations like that, `SK_UnresolvedMemberViaOptional` should
only be increased if there is a mix of members to attempt - both directly
on `Optional` and on unwrapped type, in all other cases score should stay
the same because there could be no ambiguity.
Resolves: rdar://73027153
This is a follow-up to https://github.com/apple/swift/pull/35072.
Let's wait until both sides are equally optional before attempting
`.rawValue` fix, otherwise there is a risk that a valid code would
get diagnosed.
Extend test coverage of possible `.rawValue` situations to
contextual and argument positions to make sure that valid
code is accepted.
Resolves: SR-13951
Skip fixing situation where source and destination of assignment are both
nominal types with different optionality until restriction is attempted.
Otherwise fix could be too greedy and diagnose valid code if all of the
types are known in advance.
Resolves: SR-13951
Resolves: rdar://problem/72166791
Following on from updating regular member completion, this hooks up unresolved
member completion (i.e. .<complete here>) to the typeCheckForCodeCompletion API
to generate completions from all solutions the constraint solver produces (even
those requiring fixes), rather than relying on a single solution being applied
to the AST (if any). This lets us produce unresolved member completions even
when the contextual type is ambiguous or involves errors.
Whenever typeCheckExpression is called on an expression containing a code
completion expression and a CompletionCallback has been set, each solution
formed is passed to the callback so the type of the completion expression can
be extracted and used to lookup up the members to return.
In the single-element case, it is treated as the dictionary key.
func takesDict(_ x: [Int: String]) {}
takesDict([]) // diagnose with fixit to add missing ':'
takesDict([1]) // diagnose with fixit to add missing ': <#value#>'
takesDict([foo.<complete>]) // prioritise Int members in completion results -
// the user just hasn't written the value yet.
The above previously failed with a generic mismatch error in normal type
checking (due to the literal being parsed as an array literal) and code
completion could not pick up the expected type from the context.
Let's consider conditional requirement failure to mean that parent
conformance requirement wasn't satisfied and nothing more, that helps
to disambiguate certain situations and avoid filtering out conditional
failures.
Resolves: rdar://problem/64844584
Upon attempt to generate constraints for invalid declaration reference
let's turn that into a hole and record this new fix to diagnose it
once solution has been reached.
If there is a conformance failure related to existential conversion
let's ignore that fact that there could be an implicit value-to-optional
conversion involved, because it's not the main issue in cases like
that.
Resolves: rdar://problem/70814576
It was used for unresolved member and `.dynamicType` references
as well as a couple of other places, but now unresolved member
references no longer need that due to new implicit "chain result"
AST node and other places could use more precise locators
e.g. new `.dynamicType` locator or `sequence element` for `for in`
loops.
func foo(a: Int, b: Int) {}
func foo(a: String) {}
// Int and String should both be valid, despite the missing argument for the
// first overload since the second arg may just have not been written yet.
foo(a: <complete here>
func bar(a: (Int) -> ()) {}
func bar(a: (String, Int) -> ()) {}
// $0 being of type String should be valid, rather than just Int, since $1 may
// just have not been written yet.
bar { $0.<complete here> }
If right-hand side (optional type) has been determined to be a hole,
let's establish that optional object of a hole is a hole and continue
searching for a solution.
Avoid filtering overloads for calls which have code completion
token as an argument, that would always undesired results,
because such calls could be missing arguments before or after
the token.
