Additional restrictions on when protocol inference could be considered
viable. If the chain is connected directly to a contextual type there
cannot be any other inference sources for the base type.
Resolves: rdar://148256978
Member chains with leading-dot syntax can infer the base type
only from context, so optionality mismatch with the contextual
type should propagate object type down the chain.
If subtyping is allowed for a result type of an implicit member chain,
let's delay binding it to an optional until its object type resolved too or
it has been determined that there is no possibility to resolve it.
Otherwise we might end up missing solutions since it's allowed to
implicitly unwrap base type but it can't be done early - type variable
representing chain's result type has a different l-valueness comparing
to generic parameter of an optional.
This used to work before due to a hack in constraint generator where
unresolved member with arguments would return base type (which
doesn't allow l-value) instead of a result type.
Resolves: rdar://problem/68094328
We previously were not properly handling the diagnostics for using an rvalue implicit member on the left hand side of an assignment. This adds the proper handling and extends it for member chains.
Instead of creating the type variable for the unresolved member chain at the location of the last member, we now create it at the associated UnresolvedMemberChainResultExpr.
Previously, when the final element of a chain was a ForceValueExpr, the chain result type got caught up in the logic used to allow ForceValueExprs to properly infer lvalue types. By separating the result type variable from the last member of the chain, we make sure to keep that logic focused only on ForceValueExpr.
