for arithmetic operators.
Only sort overloads that are related, e.g. Sequence
overloads. Further, choose which generic overloads
to attempt first based on whether any known argument types
conform to one of the standard arithmetic protocols.
attempt the most specific choices first. Then, if the solver finds
a solution with one choice, it can skip any subsequent choices that
can be unconditionally used in place of the successful chioce and produce
the same solution.
Doing so streamlines access to the information associated with literal
protocol requirements and allows to add more helpers.
Also cache default type in the struct itself for easy access.
As a step towards making binding inference more incremental, let's
make producer responsible for adding hole type binding instead of
doing so in `finalize`.
Replaces `InvolvesTypeVariables` flag with a set of adjacent type
variables found during binding inference.
This approach is more suitable for incremental binding computation
because it allows to maintain a list of type variables that affect
ranking and check whether something has been resolved without having
to re-evaluate constraints associated with the given type variable.
Instead of exposing archetypes during solution generation, let's
do that based on solution data when a type of code completion
expression is requested by code completion callback.
This fallback to `typeCheckExpression` is triggered when it's
determined that code completion expression is located inside
of a multi-statement closure and its body is going going to
participate in type-check.
Using `SolutionApplicationTarget` make it easier to propage
contextual information and avoid mistakes of using incorrect
accessors for constraint generation.
If an expression fails pre-check or constraint generation,
code completion should be performed directly on the
`CodeCompletionExpr` as a fallback. Let's factor that logic
out from `solveForCodeCompletion` and put it directly into
`typeCheckForCodeCompletion` because it's easier to establish
fault conditions there.
To aid code completion, we need to attempt to convert type holes
back into underlying generic parameters if possible, since type
of the code completion expression is used as "expected" (or contextual)
type so it's helpful to know what requirements it has to filter
the list of possible member candidates e.g.
```swift
func test<T: P>(_: [T]) {}
test(42.#^MEMBERS^#)
```
It's impossible to resolve `T` in this case but code completion
expression should still have a type of `[T]` instead of `[<<hole>>]`
because it helps to produce correct contextual member list based on
a conformance requirement associated with generic parameter `T`.
If there was an invalid reference which was caught by pre-check,
let's remove all context besides code completion itself and use
it to produce code completion results.
Add a flag to `ConstraintSystem::preCheckExpression` and subsequently
to `TypeChecker::resolveDeclRefExpr` to indicate whether it's allowed
to replace invalid member refs with `ErrorExpr`.
It is useful for diagnostics and code completion to preserve AST
in it's original state otherwise it's impossible to diagnose errors
post factum or extract `CodeCompletionExpr` when it's a child of an
invalid reference.
To better preserve source compatibility, teach the constraint
solver to try both the new forward scanning rule as well as the
backward scanning rule when matching a single, unlabeled trailing
closure. In the extreme case, where the unlabeled trailing closure
matches different parameters with the different rules, and yet both
produce a potential match, introduce a disjunction to explore both
possibilities.
Prefer solutions that involve forward scans to those that involve
backward scans, so we only use the backward scan as a fallback.
Since bindings now require finalization we need a new endpoint
which perform all of the required actions before returning complete
`PotentialBindings` object when they are requested for a particular
type variable without any other context.
