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.
