If a type variable has a subtype binding which came from a conversion/subtype/equality
constraint to a struct or enum (expect to `AnyHashable`, `Unsafe{Mutable}RawPointer`),
attempt it early because that type is the only choice which is not going to fail such
constraint.
For example, in cases like `$T argument convertible to Int` type variable could
only be bound to `Int`, `Int!`, or `@lvalue Int` to satisfy that constraint, so
it would make sense to attempt to bind it to `Int` early if it doesn't represent
a result of a member lookup (that's how IUO and/or `@lvalue` could be inferred)`
and doesn't have any direct disjunction associated with it e.g. for coercion or
optional matching.
`init` calls to redeclared types would end up diagnosed as ambiguity,
so locator simplification needs to account for the fact that "base"
of constructor might be overloaded type reference.
Resolves: rdar://84879566
In situations like `_ = ... as! Bool!` the `to` type could either
be represented by an optional (default) or unwrapped. Coercion warnings
cannot assume that `to` (even though its IUO) is always represented
as an optional type.
Resolves: rdar://83072606
This test only happened to be under the constraint system thresholds,
but the performance was not fast. Add a few operands to the + chain,
and disable shrink to push the solver past the performance thresholds.
Detect situations when type of a declaration hasn't been resolved yet
(one-way constraints would use a type variable to represent a type of IUO pattern),
and use additional type variable and a constraint to represent an
object type of a future optional type.
Resolves: SR-14893
Resolves: rdar://80271666
Typed patterns are represented by a name and a fixed contextual
type, let's not use intermediary type variable and one-way constraint
as its type because that variable would be bound right away to
contextual type. Also setting type of a variable declaration
to a type variable when contextual type is IUO doesn't play well
with overload resolution because it expects an optional type for
declarations with IUO attribute.
Resolves: rdar://80271666
If solutions either have no fixes at all or all of the are warnings,
let's use `diagnoseAmbiguity` to diagnose such cases as-if there are
no fixes at all.
Resolves: rdar://79657350
Use `findSelectedOverloadFor` instead of `findResolvedMemberRef`
to cover cases where member is found via base type unwrap, otherwise
conformance constraint would be re-inserted but never re-attempted
which results in a compiler crash.
Resolves: rdar://79268378
While checking whether compiler needs to produce a checked cast warning,
account for the fact that "from" could be less optional than "to" e.g.
`0 as Any?`, so the difference has to be stored as a signed integer
otherwise it's going to underflow and result in a crash or infinite
recursion in the diagnostics.
Resolves: rdar://79523605
Currently all `ComponentSteps` created by `DependentComponentSplitterStep` share the same `Solutions` vector. Because of this, the `ComponentStep`s might modify solutions created by previous `ComponentStep`s. Use different `Solutions` vectors for each `ComponentStep` to avoid sharing information between the `ComponentStep`s.
The concrete manifestation in the added test case is that the `Bar` overload gets added to `Solutions`, it’s score gets reduced by its `ComponentStep` original score, then the `Foo` overload gets added to `Solutions` and both solutions have their score decreased by the `OriginalScore` of `Foo`’s `ComponentStep`, causing `Bar`’s score to underflow.
Fixes rdar://78780840 [SR-14692]
This test has become flaky in different configurations due to a varying
number of available operator overloads, let's use more operators to make
sure that it's "too complex" regardless of configuration.
Resolves: rdar://77656775
Let's make use of a newly added "disable for performance" flag to
allow solver to consider overload choices where the only issue is
missing one or more labels - this makes it for a much better
diagnostic experience without any performance impact for valid code.
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
`PreCheckExpression` already skips calls, make sure that invalid subscripts,
dynamic subscript, ObjC literals preserve paren/tuple for an index/argument.
Resolves: rdar://61749633
Performance optimization to help rule out generic overload choices sooner.
This is based on an observation of the constraint solver behavior,
consider following example:
```swift
func test<U: ExpressibleByStringLiteral>(_: U) {}
test(42)
```
Constraint System for call to `test` is going to look like this:
```
$T_test := ($T_U) -> $T_U
$T_U <conforms to> ExpressibleByStringLiteral
$T_42 <argument conversion> $T_U
$T_42 <literal conforms to> ExpressibleByIntegerLiteral
```
Currently to find out that `test` doesn't match, solver would have
to first find a binding for `$T_42`, then find a binding for `$T_U`
(through `<argument conversion>` constraint) and only later fail
while checking conformance of `Int` to `ExpressibleByStringLiteral`.
Instead of waiting for parameter to be bound, let's transfer conformance
requirements through a conversion constraint directly to an argument type,
since it has to conform to the same set of protocols as parameter to
be convertible (restrictions apply i.e. protocol composition types).
With that change it's possible to verify conformances early and reject
`test<U: ExpressibleByStringLiteral>` overload as soon as type of an
argument has been determined. This especially powerful for chained calls
because solver would only have to check as deep as first invald argument
binding.
Performance optimization.
If there is a concrete contextual type we could use, let's bind
it to the external type right away because internal type has to
be equal to that type anyway (through `BindParam` on external type
i.e. <internal> bind param <external> conv <concrete contextual>).
```swift
func test(_: ([String]) -> Void) {}
test { $0 == ["a", "b"] }
```
Without this optimization for almost all overloads of `==`
expect for one on `Equatable` and one on `Array` solver would
have to repeatedly try the same `[String]` type for `$0` and
fail, which does nothing expect hurts performance.
Resolves: rdar://19836070
Resolves: rdar://19357292
Resolves: rdar://75476311
Type inside of an editor placeholder is more of a hint than anything else,
so if it's incorrect let's diagnose that and use type variable instead to
allow solver to make forward progress.
Resolves: SR-14213
Resolves: rdar://74356736
- 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.
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
