One more step towards incrementality of binding inference. Instead of
trying to determine literal protocol coverage during finalization
of the bindings, let's do that as soon as new bindings and/or literal
protocol requirements are discovered.
Literal protocol requirements are handled differently from other
protocols, they require additional contextual information (such
as coverage, direct/transitive distinction), and participate in
binding inference (could be turned into default bindings).
Let's keep defaults separate from direct and transitive bindings,
that would make it easier to handle them in incremental model.
Instead of generating bindings for defaults and adding to the main
set, let's allow producer to choose what to do with them once type
variable has been picked for attempting.
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`.
Wrapping bindings into optional type based on presence of
an `ExpressibleByNilLiteral` conformance requirement should
be done after type variable has been selected for attempting.
Otherwise such upfront work would be wasteful since it doesn't
affect binding ranking in any way.
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.
- Keep track of all constraints which caused a particular type variable to
be de-prioritized.
- Convert a property to a method which would determine whether
given set of potential bindings is "fully bound" and has to
be delayed until certain constraints are simplified.
Instead of attempting to join only the last recorded supertype
binding, let's attempt to join any previously recorded supertype
binding with an incoming one to make sure that set contains only
the most viable types.
This bool was true only for single-expression closure and function bodies that
do not have an explicit `return` in the source. Rename it and its associated
methods, to avoid confusion with the hasSingleExpressionBody methods on
ClosureExpr and AbstractFuncDecl. Those don't care whether the expression was
explicitly written in the source or not.
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.
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.
successfully finding a solution by favoring operators already bound
elsewhere.
Favoring existing operator bindings often lets the solver find a solution
fast, but it's not necessarily the best solution.
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.
