Implicit conversion used to erase path for contextual type conversions
but it does so no longer, this means that invalid initializer reference
check needs to know about existence of implicit conversions that are
not reflected in the AST until solution is applied.
Resolves: rdar://99352676
Implicit conversion used to erase path for contextual type conversions
but it does so no longer, this means that invalid partial application
check needs to know about existence of implicit conversions that are
not reflected in the AST until solution is applied.
Resolves: rdar://99282932
Previously locator for value-to-value conversion would just drop
all the contextual information if the conversion occurred while
converting expression to a contextual type. This is incorrect for
i.e. `return` statements and other targets because because they
are solved separately and using the same locator would result in
a clash when solutions are merged.
Drop `TupleType` element which is only used for diagnostics and
cannot be re-created by `ExprRewriter` during solution application.
Resolves: rdar://97389698
Constraint generator records conversion between chain result expression
and contextual type as anchored on an implicit unresolved chain result,
which means that coercion has to do the same in case restrictions
(like Double<->CGFloat conversion) depend on locators to retrieve
information for the solution.
Resolves: rdar://97261826
The locator needs to much what was produced by constraint generator
otherwise Double<->CGFloat implicit coercion wouldn't be able to
find the overload choice.
Constraint generator records conversion between source and destination
types as anchored on an assignment, which means that coercion has to do
the same in case restrictions (like Double<->CGFloat conversion) depend
on locators to retrieve information for the solution.
Just like in case of array elements, the locator needs to much what
was produced by constraint generator otherwise Double<->CGFloat implicit
coercion wouldn't be able to find the overload choice.
Unfortunately current approach of making a conversion independent of location
doesn't work when conversion is required for multiple arguments to the
same call because solver expects that either there are no Double<->CGFloat
conversions, or one of them has already been applied which is not the case.
The reason why locations weren't preserved in the first place is due to
how a solution is applied to AST - AST is mutated first and then, if there
are any conversions, they are applied to the already mutated version of
original AST. This creates a problem for Double<->CGFloat which depends
on an overload choice of injected call and it's impossible to find it based
on the mutated AST. But it turns out that this is only an issue in two
specific cases - conversions against contextual type and after optional injection.
This situations could be mitigated by dropping parts of the locator which are
unimportant for the Double<->CGFloat conversion - anchor in case of contextual
and `OptionalPayload` element(s) in case of optional injection.
Resolves: https://github.com/apple/swift/issues/59374
Literal closures are only ever directly referenced in the context of the expression they're written in,
so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if
they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context
before emitting the closure, and then lowering its main entry point's calling convention at that
level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns
to the correct representation for a different abstraction level.
Literal closures are only ever directly referenced in the context of the expression they're written in,
so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if
they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context
before emitting the closure, and then lowering its main entry point's calling convention at that
level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns
to the correct representation for a different abstraction level.
Literal closures are only ever directly referenced in the context of the expression they're written in,
so it's wasteful to emit them at their fully-substituted calling convention and then reabstract them if
they're passed directly to a generic function. Avoid this by saving the abstraction pattern of the context
before emitting the closure, and then lowering its main entry point's calling convention at that
level of abstraction. Generalize some of the prolog/epilog code to handle converting arguments and returns
to the correct representation for a different abstraction level.
Change the conversion rule to favor any number of widenings (CGFloat -> Double)
over even a single narrowing conversion and if there is no way to avoid narrowing
(due to contextual requirements) attempt it as late as possible (the deeper in
the AST that conversion is located the higher its score).
This is a generally better rule when it comes to rounding and information
loss that would result from narrowing conversions.
This wasn't a problem before since locator wasn't really used by
`ExprRewritter:coerceToType` but with Double<->CGFloat conversion
it needs the locator to be anchored at a rewritten expression instead
of the original one to form a correct implicit initializer call.
