Previously, retractFromInference() was the last step in
unbindTypeVariable(). This doesn't really make sense,
because bindTypeVariable() doesn't call introduceToInference();
its two callers do it later.
Start untangling this by splitting off introduceToInference()
into its own Change, but for now, record this change at the
incorrect place to maintain the same behavior as before.
Previously, the constraint solver would first attempt member lookup that
excluded members from transitively imported modules. If there were no viable
candidates, it would perform a second lookup that included the previously
excluded members, treating any candidates as unviable. This meant that if the
member reference did resolve to one of the unviable candidates the resulting
AST would be broken, which could cause unwanted knock-on diagnostics.
Now, members from transitively imported modules are always returned in the set
of viable candidates. However, scoring will always prioritize candidates from
directly imported modules over members from transitive imports. This solves the
ambiguities that `MemberImportVisibility` is designed to prevent. If the only
viable candidates are from transitively imported modules, though, then the
reference will be resolved successfully and diagnosed later in
`MiscDiagnostics.cpp`. The resulting AST will not contain any errors, which
ensures that necessary access levels can be computed correctly for the imports
suggested by `MemberImportVisibility` fix-its.
Resolves rdar://126637855.
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.
In situations like:
```
class A {
func test() {}
}
```
Fully uncurried function type should be @Sendable but inner method
cannot be because it captures a non-Sendable type `A` when applied.
We used to detect partial applications based on member locators
and parent expressions, but using function reference kind +
check to see if self is applied is such simpler and hits both
uses of `isPartialApplication`.
Both of these functions are single-apply instance members,
even though their names could be compound the application
is still a regular call with like `next(isolation: ...)`
vs. `next(isolation:)(...)` it would have to be for a "compound"
application.
Operator references don't have a base type and could be found via
unqualified lookup, `adjustFunctionTypeForConcurrency` should handle
them specifically.
Resolves: rdar://131321053
