When requesting information about the contextual type of a constraint
system, do so using a given expression rather than treating it like
the global state that it is.
We used to get this contextualization "for free" because closures that
had function builders applied to them would get translated into
single-expression closures. Now, we need to check for this explicitly.
`getCalleeLocator` has to be able to:
- Retrieve type for given expression via `getType`;
- Simplify given type via `simplifyType`; and
- Retrieve a selected overload choice for a given locator via `getOverloadFor`.
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 `ImplicitCallAsFunction` locator path
element to represent an implicit member reference
to `callAsFunction`. Then adjust CSApply a little
to check whether it's finishing an apply for a
callable type, and if so build the implicit member
access.
Have callers resolve the SelectedOverload instead of the callee. Then make the error paths more apparent, and flush Optional<SelectedOverload> wherever it can be found.
Constraint application was rewriting conditional casts (as?) and
forced casts (as!) into coercions (as) at the AST level when it
determined that there was a coercion. Stop doing that: it's the
optimizer's job to remove such casts.
Rather than spinning up a new constraint system when performing an "as"
coercion, perform the coercion with the known solution, because we
already did all of the work to figure out how to perform the coercion.
In this case we would "devirtualize" the protocol requirement call
by building the AST to model a direct reference to the witness.
Previously this was done by recursively calling typeCheckExpression(),
but the only thing this did was recover the correct substitutions
for the call.
Instead, we can just build the right SubstitutionMap directly.
Unfortunately, while we serialize enough information in the AST
to devirtualize calls at the SIL level, we do not for AST Exprs.
This is because SIL devirtualization builds a reference to the
witness thunk signature, which is an intermediate step between
the protocol requirement and the witness. I get around this by
deriving the substitutions from walking in parallel over the
interface type of the witness, together with the inferred type
of the call expression.
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`.
Apply the same checks as ApplyExprs to
UnresolvedMemberExprs in getCalleeLocator to
resolve callees in cases where they're used with
`callAsFunction` in addition to a weird edge case
where we currently allow them with constructor
calls, e.g:
```
struct S {
static let s = S.self
}
let x: S = .s()
```
Arguably we should be representing ".member()"
expressions with an UnresolvedMemberExpr + CallExpr,
which would avoid the need to apply these special
cases, and reject the above syntax for not using
an explicit ".init". Doing so will likely require
a bit of hacking in CSGen though.
Resolves SR-11909.
Previously we missed caching component types in
one case, and cached the wrong type in another.
Make both cases use cacheExprTypes to cache the
correct component types.
Previously we were only handling IUO unwrapping in
visitKeyPathExpr, but not for callers that were
building their own property and subscript
components such as dynamic member lookup.
Move the IUO unwrapping logic into
buildKeyPath[Property/Subscript]Component,
and adjust their signatures to allow them to
append multiple components. Also add
buildKeyPathOptionalForceComponent to allow more
convenient adding of an optional force component.
Resolves SR-11893.
Rather than setting `baseTy` for each component,
just set it for the last component in the
iteration. In addition, remove the `component`
variable, which no longer serves a purpose.
Finally, cache all the component types at the end
of the loop.
When originally implemented (a5ca6ccd61),
we used to append the set `component` to
`resolvedComponents`, however that appears to have
been refactored away at some point, leaving a couple
of dead assignments. Restore the old behaviour by
just appending the components.
Rather than coercing the call arguments ourselves,
just build the finished member reference for the
callAsFunction method, and let finishApply do the
rest. This allows us to deal with transformations
such as IUO unwraps.
Resolves SR-11881.
Move `buildDynamicMemberLookupIndexExpr` into
ExprRewriter, and pass the string literal through
`handleStringLiteralExpr` to properly handle its
coercion to the parameter type.
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.
