While resolving closure use contextual locator information to
determine whether given contextual type comes from a "function builder"
parameter and if so, use special `applyFunctionBuilder` to open
closure body instead of regular constraint generation.
This constraint connects type variable representing a closure
expression to its inferred type and behaves just like regular
`Defaultable` constraint expect for type inference where it's
used only if there are no contextual bindings available.
In preparation to change the way closures are handled in constraint system
let's introduce a special method which is responsible for generation of
constraints for closure body and connecting it to the rest of the
constraint system when contextual type becomes available.
In preparation to change type-checking behavior of closures
we need to introduce a special mapping from closure expressions
to their inferred types (based on parameters/result and body).
Separate closure from top-level constraint generation because
its body shouldn't be considered when it comes to parent/weight
computation, otherwise top expression in body is going to get
disconnected from the closure.
This is necessary for ambiguity diagnostics because none of the
solutions are applied back to the constraint system which means
that `getCalleeLocator` needs an ability to query information
from different sources e.g. constraint system and/or solution.
When type checking the body of a function declaration that has a function
builder on it (e.g., `@ViewBuilder var body: some View { ... }`), create a
constraint system that is responsible for constraint generation and
application, sending function declarations through the same code paths
used by closures.
Chip away at the expression-centric nature of the constraint system by
generalizing the "target" of solution application from a single
expression to a a "SolutionApplicationTarget", which can be an
expression or a function body. The latter will be used for applying
function builders to an entire function body.
Introduce a new kind of constraint, the "value witness" constraint,
which captures a reference to a witness for a specific protocol
conformance. It otherwise acts like a more restricted form of a "value
member" constraint, where the specific member is known (as a
ValueDecl*) in advance.
The constraint is effectively dependent on the protocol
conformance itself; if that conformance fails, mark the type variables
in the resolved member type as "holes", so that the conformance
failure does not cascade.
Note that the resolved overload for this constraint always refers to
the requirement, rather than the witness, so we will end up recording
witness-method references in the AST rather than concrete references,
and leave it up to the optimizers to perform devirtualization. This is
demonstrated by the SIL changes needed in tests, and is part of the
wider resilience issue with conformances described by
rdar://problem/22708391.
Previously we had a request for this in
IDETypeChecking, but this wasn't used for queries
made from Sema. Move the request into Sema, and
move `hasDynamicMemberLookupAttribute` onto
TypeBase.
There was a single place where it was used to determine whether
a binding comes from an argument conversion constraint. Since
constraint locator is part of the binding now it's possible to
use it instead and remove unused accessor.
Unify all of the fields of `PotentialBinding` which have to do with
location information into a single field with is either a constraint
(for regular bindings) or constraint locator (for "holes").
This helps to reduce the amount of space used by `PotentialBinding`
as well as propagate more contextual information when binding gets
attempted.
Rather than adjusting the opened types for choices
referring to `subscript(dynamicMember:)` down to
the result type, only use the result type to
bind the overload type variable. This avoids the
need for a couple of special cases in CSApply.
To facilitate this change, add
`ConstraintSystem::bindOverload`, which deals with
adding the necessary constraints to bind the
overload's type variable. The eventual goal here
is to remove `adjustTypeOfOverloadReference`, with
adjustments to the opened type being moved to
`getTypeOfMemberReference`, and the adding of
constraints being moved to `bindOverloadType`.
Rather than maintaining a linked list of overload
choices, which must be linearly searched each time
we need to lookup an overload at a given callee
locator, use a MapVector which can be rolled back
at the end of a scope.
Remove ResolvedOverloadSetListItem in favor of
using SelectedOverload, which avoids the need to
convert between them when moving from
ConstraintSystem to Solution.
Solutions passed to `diagnoseAmbiguityWithFixes` aren't filtered
so we need to remove all of the solutions with the score worse
than overall "best". Also logic has to account for some fixes being
"warnings".
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.
In anticipation of eliminating this solution-application logic, centralize
to application of solutions back to the constraint system for the purpose
of applying the solution to update ASTs.
When applying the set of fixes introduced by a solution, don't rely on
a walk from the "root" expression of the constraint system to
attribute the fixes to expressions. Rather, collect the fixes and emit
diagnostics in source order of the expressions that pertain to.
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.
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.
