Instead of setting empty closure (`{}`) result type to be `Void`
while generating constraints, let's allocate a new type variable
instead and let it be bound to `Void` once the body is opened.
This way we can support an interaction with function builders which
would return a type different from `Void` even when applied to empty closure.
Resolves: rdar://problem/61347993
Previously we could skip default literal or
supertype bindings if we had already found a solution
with fixes, which could lead us to miss bindings
that produce better diagnostics.
Tweak the logic such that we continue exploring if
we're in diagnostic mode.
Resolves SR-12399.
It's allowed to convert a single statement closure from `(...) -> T` to `(...) -> Void`
_only_ if there is no explicit `return` in the body.
Resolves: [SR-12277](https://bugs.swift.org/browse/SR-12277)
Resolves: rdar://problem/52204414
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
parseClosureSignatureIfPresent.
Otherwise, closure parameters that were parsed as "potentially destructured"
will fail constraint generation, even after the parser has decided
they are not destructured.
Let's delay attempting any bindings for type variables representing
parameters or result type of the closure until the body is "opened"
because it's impossible to infer a full set of bindings until all
constraints related to a closure have been generated.
Resolves: rdar://problem/59741308
Fix a case where favoring didn't account for "bound" type variable
being wrapped into optional(s) (disjunctions like that are used for
optional conversions). Doing so makes sure that closure result type
is not bound before the body of the closure is "opened", that's
important because body could provide additional context required
to bind result type e.g. `{ $0 as? <Type> }`.
Resolve: rdar://problem/59208419
Delayed constraint generation for the body of the single-statement
closures regressed variadic parameter handling. Fix it by using
`FunctionType::Param::getParameterType` for "internal" version of
the parameter type which translates variadic/inout correctly.
Resolved: rdar://problem/58647769
Instead of trying to hold a "global" set of type variable differences
let's use pair-wise comparison instead because in presence of generic
overloads such would be more precise.
If there are N solutions for a single generic overload we currently
relied on "local" comparison to detect the difference, but it's not
always possible to split the system to do one. Which means higher
level comparisons have to account for "local" (per overload choice)
differences as well otherwise ranking would loose precision.
* WIP implementation
* Cleanup implementation
* Install backedge rather than storing array reference
* Add diagnostics
* Add missing parameter to ResultFinderForTypeContext constructor
* Fix tests for correct fix-it language
* Change to solution without backedge, change lookup behavior
* Improve diagnostics for weak captures and captures under different names
* Remove ghosts of implementations past
* Address review comments
* Reorder member variable initialization
* Fix typos
* Exclude value types from explicit self requirements
* Add tests
* Add implementation for AST lookup
* Add tests
* Begin addressing review comments
* Re-enable AST scope lookup
* Add fixme
* Pull fix-its into a separate function
* Remove capturedSelfContext tracking from type property initializers
* Add const specifiers to arguments
* Address review comments
* Fix string literals
* Refactor implicit self diagnostics
* Add comment
* Remove trailing whitespace
* Add tests for capture list across multiple lines
* Add additional test
* Fix typo
* Remove use of ?: to fix linux build
* Remove second use of ?:
* Rework logic for finding nested self contexts
If return type is a function, it's possible to return a closure
which can have some of its arguments unused in the body e.g.
`let _: () -> ((Int) -> Void) = { return { } }`
In this case resulting closure has to use its only parameter or
explictly ignore it by declaring `_ in`.
Solutions passed to `diagnoseAmbiguityWithFixes` aren't filtered
so we need to remove all of the solutions with the score worse
than overall "best". Also logic has to account for some fixes being
"warnings".
Detect and diagnose a problem when explicitly specified closure
result type doesn't match what is expected by the context:
Example:
```swift
func foo(_: () -> Int) {}
foo { () -> String in "" } // `Int` vs. `String`
```
all cases of missing generic parameters.
In `ComponentStep::take` when there are no bindings or disjunctions, use hole
propagation to default remaining free type variables that aren't for generic
parameters and continue solving. Rather than using a defaultable constraint for
holes, assign a fixed type directly when we have no bindings to try.
If the last parameter is defaulted, there might be
an attempt to use a trailing closure with previous
parameter that accepts a function type e.g.
```swift
func foo(_: () -> Int, _ x: Int = 0) {}
foo { 42 }
```
Resolves: rdar://problem/55102498
Number the parameters starting at 1 in order to
match other diagnostics such as
diag::missing_argument_positional, and change the
text to make it explicit that we're referring to
the parameter position (rather than argument
position).
Introduce a fix/diagnostic when there is a contextual mismatch
between source and destination types of the assignment e.g.:
```swift
var x: Int = 0
x = 4.0 // destination expects an `Int`, but source is a `Double`
```
mismatches in function types.
This improves the diagnostic in cases where we have argument-to-parameter
conversion failures or contextual type mismatches due to inout attribute
mismatches.
This helps us to filter out cases like operator overloads where
`Self` type comes from e.g. default for collection element -
`[1, "hello"].map { $0 + 1 }`. Main problem here is that
collection type couldn't be determined without unification to
`Any` and `+` failing for all numeric overloads is just a consequence.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
Now covers following new areas (alongside simple assignments):
- Contextual type coercions:
- In assignment e.g. `let _: X = foo`
- In return type positions e.g. `func foo() -> A { return bar }`
- Argument-to-parameter applications (including @autoclosure)
