One can convert from a function value without a global actor to a
similar function type that does have a global actor, but one cannot
remove or change a global actor on a function type.
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.
Allow Double <-> CGFloat conversion if the associated locator is
simplifiable down to a AST node (e.g. expression) this limits
applications of such conversions to e.g. argument-to-parameter,
contextual conversions and forbids conversions in generic arguments,
function result, collection elements etc.
Consider conversion with context to be worse by default
because it means that expression as a whole couldn't get
to the expected type.
This also helps to disambiguate situations with
multiple solutions where one of them has a contextual
mismatch that requires implicit conversion and
another produces correct contextual type but requires
implicit conversion inside to get there.
- Prefer CGFloat -> Double over the other way around to avoid
ambiguities;
- Every new conversion impacts the score by factor of number of
previously applied conversions to make it possible to select
solutions that require the least such conversions.
- Prefer concrete overloads with Double <-> CGFloat conversion
over generic ones.
Add logic to `matchTypes` to insert an implicit conversion to/from
CGFloat type when two nominal types are matched and one of them is
of `CGFloat` type.
To support implicit conversion to/from CGFloat type we need to:
- Reference an `init` member on the right-hand side type (either
CGFloat if we are converting to it, or compatible type if from).
- Add a `ApplicableFunction` constraint to model an implicit
call to previously referenced initializer with an argument
of left-hand side type.
Currently `getFunctionArgApplyInfo` expects a locator with `ApplyArgToParam`
element to identify location of the argument. `InOutExpr` could only be used
in argument positions but it doesn't have the same locator format as non-inout
arguments, so `getFunctionArgApplyInfo` needs to do some digging in the AST
to retrieve that information.
Resolves: rdar://75146811
A lot of operators (and most likely regular functions a well) have
overloads that accept i.e. a generic parameter that conforms to
`StringProtocol`, so the best fix in situations when argument is
a raw representable type would be to check whether `.rawValue`
conforms to the expected protocol and use it if so.
Resolves rdar://problem/75367157
If member has been bound before the base and the base was
incorrect at that (e.g. fallback to default `Any` type),
then we need to re-activate all of the constraints
associated with this member reference otherwise some of
the constraints could be left unchecked in inactive state.
This is especially important for key path expressions because
`key path` constraint can't be retired until all components
are simplified.
Resolves: SR-13364
Resolves: rdar://66706980
Resolves: rdar://74711236
New name is `isInKeyPathComponent` since it's implemeneted as a
check for presence of `KeyPathComponent` element in the locator
that covers every sub-element contained in a key path component
as well.
Instead of assuming that there is a mismatch between context and
result of the optional chain, let's actually verify that optional
evaluation expression does have a type before recording a fix.
Resolves: rdar://74696023
`simplifyAppliedOverloads(Constraint *, ...)` wouldn't filter choices
based on labels unless it finds recorded labels in the constraint system
based on the provided locator. `addOverloadSet` used incorrect locator
when calling `simplifyAppliedOverloads` which means that this call was
effectively a no-op.
Since labels are considered part of the name, mismatches in labeling
should be invalidate overload choices. Let's prefer an overload with
correct labels but incorrect types over the one with incorrect labels.
This also means that it's possible to restore performance optimizations
related to early filtering in diagnostic mode, which is important for
deeply nested code i.e. SwiftUI views.
The existing overloading rules strongly prefer async functions within
async contexts, and synchronous functions in synchronous contexts.
However, when there are other differences in the
signature, particularly parameters of function type that differ in
async vs. synchronous, the overloading rule would force the use of the
synchronous function even in cases where the synchronous function
would be better. An example:
func f(_: (Int) -> Int) { }
func f(_: (Int) async -> Int) async { }
func g(_ x: Int) -> Int { -x }
func h() async {
f(g) // currently selects async f, want to select synchronous f
}
Effect the semantics change by splitting the "sync/async mismatch"
score in the constraint system into an "async in sync mismatch" score
that is mostly disqualifying (because the call will always fail) and a
less-important score for "sync used in an async context", which also
includes conversion from a synchronous function to an asynchronous
one. This way, only synchronous functions are still considered within
a synchronous context, but we get more natural overloading behavior
within an asynchronous context. The end result is intended to be
equivalent to what one would get with reasync:
func f(_: (Int) async -> Int) async { ... }
Addresses rdar://74289867.
Currently bindings where inferred on every `bindTypeVariable` call,
but that's wasteful because not all binds are always correct. To
avoid unnecessary inference traffic let's wait until re-activated
constraints are simplified and notify binding inference about new
fixed type only if all of them are successful.
when it has property wrapper parameters.
The property wrapper type will be replaced with either the wrapped-value
or projected-value type, depending on the argument label/parameter name,
and CSApply will build a thunk to construct the property wrapper and call
the function.
