This helps to avoid allocating new type variables (which shouldn't be done regardless)
to store parameter indices when `missing arguments` diagnostic is used by other diagnostics.
Previously we were using `getPlainType` to match
the parameter type against the key path's base
type. This gave us the external parameter type,
which would be the element type for a variadic
parameter. However the code we generate expects
the internal parameter type, which is provided by
`getParameterType`.
Resolves rdar://problem/59445486.
Reverts apple/swift#30006. It caused a regression that we'd like to address before re-landing:
```swift
struct X {
var cgf: CGFloat
}
func test(x: X?) {
let _ = (x?.cgf ?? 0) <= 0.5
}
```
This reverts commit 0a6b444b49.
This reverts commit ed255596a6.
This reverts commit 3e01160a2f.
This reverts commit 96297b7e39.
Resolves: rdar://problem/60185506
Consider following example:
```swift
enum E {
case foo((x: Int, y: Int))
case bar(x: Int, y: Int)
}
func test(e: E) {
if case .foo(let x, let y) = e {}
if case .bar(let tuple) = e {}
}
```
Both of `if case` expressions have to be supported:
1. `case .foo(let x, let y) = e` allows a single tuple
parameter to be "destructured" into multiple arguments.
2. `case .bar(let tuple) = e` allows to match multiple
parameters with a single tuple argument.
Resolves: rdar://problem/60061646
Since constraint system now handles pattern matching it has
to preverse label matching semantics which existed in original
code: if pattern element has a label it has to match the one
in the tuple type it's matched against.
Resolves: rdar://problem/60048356
doesn't conform to the associatedtype's protocol (only in diagnostic mode).
This allows the solver to find solutions for more cases involving requirement
failures for dependent member types without special cases across the solver
that check for dependent member types with no type variables.
If mismatch detected by `repairFailures` is related to a complex
wrapped value of optional type formed from optional-to-optional
or value-to-optional conversion let's not try to fix it directly
but let `simplifyRestrictedConstraintImpl` record a top-level fix
for more context.
Resolves: rdar://problem/59703585
If there are any conversion restrictions present while trying to repair
failures related to contextual type, let's give `simplifyRestrictedConstraintImpl`
a chance to run and fix the problem.
Resolves: rdar://problem/59773317
Instead of always opening argument type represented by a collection
without type variables (to support subtyping when element is a labeled tuple),
let's try original type first and if that fails use a slower path with
indirection which attempts `array upcast`. Doing it this way helps to
propagate contextual information faster which fixes a performance regression.
Resolves: rdar://problem/54580247
We have two similar code paths here that should probably be unified. For
now, make sure the more-specific one for pattern matching kicks in first.
Fixes rdar://problem/59838566.
Fix a crash in dynamic member lookup attempting to recursively
lookup a member on the same base type.
The problem is related to `isSelfRecursiveKeyPathDynamicMemberLookup`
which failed to look through l-value wrapping base type on each side of
the comparison, that's important because it's possible to have l-value
mismatch due to the fact that implicit call always gets l-value base
type but actual subscript which triggered dynamic lookup might be r-value.
Resolves: [SR-11743](https://bugs.swift.org/browse/SR-11743)
Resolves: rdar://problem/57091169
Extend the constraint system’s diagnostics with specific handling for
matching an enum element pattern that has a subpattern (i.e., to capture
associated values) against an enum case that does not have any associated
value. This brings diagnostics for the new code path on par with the existing
diagnostics of coercePatternToType.
Generate a complete set of constraints for EnumElement patterns, e.g.,
case let .something(x, y)
Most of the complication here comes from the implicit injection of optionals,
e.g., this case can be matched to an optional of the enum type of which
`something` is a member. To effect this change, introduce a locator for
pattern matching and use it to permit implicit unwrapping during member
lookup without triggering an error.
Note also labels are dropped completely when performing the match,
because labels can be added or removed when pattern matching. Label
conflict are currently diagnosed as part of coercePatternToType, which
suffices so long as overloading cases based on argument labels is not
permitted.
The primary observable change from this commit is in diagnostics: rather
than diagnostics being triggered by `TypeChecker::coercePatternToType`,
diagnostics for matching failures here go through the diagnostics machinery
of the constraint solver. This is currently a regression, because
there are no custom diagnostics for pattern match failures within the
constraint system. This regression will be addressed in a subsequent
commit; for now, leave those tests failing.
Detect that disjunction is going to be applied to arguments which
don't provide any additional contextual information and allow only
a single choice to be attempted in such case to avoid triggering
exponential behavior in the solver.
The problem is most visible with operators e.g.
```swift
.foo == .bar || 1 == .baz
```
If neither member could be contextually determined and solver was
allowed to attempt all of the overloads for `==` and `||` that
would lead to exponential behavior (because each has 30+ overloads)
and generation of hundreds of partial solutions.
Resolves: rdar://problem/56400265
Currently constraint solver is only capable of detecting universally unavailable
overloads but that's insufficient because it's still possible to pick a contextually
unavailable overload choice which could be better than e.g. generic overload, or
one with defaulted arguments, marked as disfavored etc.
Let's introduce `ConstraintSystem::isDeclUnavailable` which supports both universal
and contextual unavailability and allow constraint solver to rank all unavailable
overload choices lower than any other possible choice(s).
Resolves: rdar://problem/59056638
Identify problems like:
```swift
func foo(_ x: Int, _ y: String) {}
func bar(a: Int, b: String) {
foo(b, a) // Instead of `foo(a, b)`
}
```
Where arguments are out-of-order and repair it by using OoO fix on the
parent locator.
Just like in cases where both sides are dependent member types
with resolved base that can't be simplified to a concrete type
let's ignore this mismatch and mark affected type variable as a hole
because something else has to be fixed already for this to happen.
When there is a conversion from e.g. `(A) -> Void` to `(B) -> Void`
matching between `A` and `B` is going to have a special locator which
doesn't end in `TupleElement`, so `repairFailures` has to account
for that and fix it just like regular argument mismatch.
Resolves: rdar://problem/59066040
Prioritize type mismatches over conformance failures when stdlib
types are involved because it wouldn't be appropriate to suggest
to add such a conformance, so the problem is most likely related
to something else e.g. other overload choice has a better fix.
Consider following example:
```swift
struct S {
init(_: Double) {}
init<T: BinaryInteger>(_: T) {}
}
_ = S(Double("0"))
```
In cases like that it's better to prefer failable initializer
which takes a `String` and returns `Double?` and diagnose a
problem related to missing optional unwrap instead of missing
conformances related to a `String` argument of other `Double`
initializer just because it returns a concrete type.
Since `simplifyRestrictedConstraintImpl` has both parent types and
does nested type matching it's a good place to diagnose top-level
contextual problems like mismatches in underlying types of optionals.
