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.
Note: The change in ASTBuilder::createFunctionType is functionally minor,
but we need the FunctionType::Params computed _before_ the ExtInfo, so we
need to shuffle a bunch of code around.
Callers were either just passing
choice.getKind() == OverloadChoiceKind::DeclViaDynamic
or passing false. Inline the check into the function
and assert for callers that don't expect a decl
from dynamic lookup.
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.
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
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.
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.
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.
diagnosing failures in applySolutionFixes, coalesce fixes and
diagnose failures in one method on ConstraintFix.
This eliminates the need for the `DefaultGenericArgument` fix (which
was renamed from `ExplicitlySpecifyGenericArguments`) to have an
array of missing parameters, which was only used when the fixes were
coalesced. Instead, the coalesced arguments are used to create the
`MissingGenericArgumentsFailure` diagnostic directly.
