Add a case to getCalleeLocator to return the
appropriate locator for a call to an implicit
callAsFunction member reference.
Resolves SR-11386 & SR-11778.
Locator builders keep a pointer to their underlying
locator, so it's not generally sound to extend an
rvalue locator builder.
This commit enforces that withPathElement is called
on an lvalue, and adds a couple more overloads of
getConstraintLocator to make it more convenient to
extend locators with multiple elements.
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.
Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.
To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.
Resolves: rdar://problem/57201781
Rework the interface to ConstraintSystem::salvage() to (a) not require
an existing set of solutions, which it overwrites anyway, (b) not
depend on having a single expression as input, and (c) be clear with
its client about whether the operation has already emitted a
diagnostic vs. the client being expected to produce a diagnostic.
Rather than setting up the constraint solver with a single expression
(that gets recorded for parents/depths), record each expression that
goes through constraint generation.
When realizing a type like Foo<A>.Bar, we have to account for the
possibility that Bar is defined in a constrained extension of Foo,
and has generic requirements beyond those that Foo itself places
on 'A'.
Previously we only handled this for types referenced from the
constraint system as part of openUnboundGenericType(), so we were
allowing invalid types through in type context.
Add the right checking to applyGenericArguments() to close the
hole. Note that the old code path still exists in the constraint
solver; it is used for member accesses on metatype bases only.
Fixes <https://bugs.swift.org/browse/SR-10466>.
An awful pattern we use throughout the compiler is to save and restore global flags just for little things. In this case, it was just to turn on some extra options in AST printing for type variables. The kicker is that the ASTDumper doesn't even respect this flag. Add this as a PrintOption and remove the offending save-and-restores.
This doesn't quite get them all: we appear to have productized this pattern in the REPL.
solve() is a bit too overloaded, so rename the version that does the
core "evaluate all of the steps to produce a set of solutions"
functionality to solveImpl().
automatically.
This commit also renames `ConstraintSystem::recordHole/isHole` to
`recordPotentialHole` and `isPotentialHole` to make it clear that
we don't know for sure whether a type variable is a hole until it's
bound to unresolved.
