`test/Constraints/interpolation_segments.swift` has been removed
because interpolations are now type-checked together with their
context, so the separate type-checking test no longer applies.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
SE-0110 allows tuple slat between function types. The solver needs to
account for that when trying to infer parameter types from context
while resolving a closure in order to propagate types and speed up
type-checking.
Resolves: https://github.com/apple/swift/issues/62390
If all solutions point to the same overload choice that needs
re-labeling it's safe to diagnose it as if there was no ambiguity
because the call site is static.
Warnings cannot lead to failures or ambiguity so let's remove
them from consideration when attempting to diagnose ambiguity
potentially caused by the same fix appearing in different
solutions.
Resolves: rdar://81228501
When inference is determining bindings of a type variable that represents
an overload set (e.g. member or operator reference), let's not consider
it as delayed due to presence of `ApplicableFunction` constraint since
argument/result type inference depends on overload set but not vice versa.
Resolves: rdar://78917861
Currently ambiguity notes attached to a candidate only mention
expected type and its position. To improve clarify of such notes
it's useful to print argument type as well since it's not always
clear what it is at the first glance at the code.
Resolves: SR-14634
Resolves: rdar://78224323
A type representing a closure expression is always bound to its
"inferred" type based on the body, so contextual bindings just
serve as a trigger to "resolve" a closure. Let's not attempt any
subtype/supertype inference for a type variable representing a
closure since if "direct" bindings have failed, it wouldn't be bound
to such types regardless.
Resolves: rdar://problem/77022842
If left-hand side of a conversion that requires l-value is a placeholder type,
let's fix that by propagating placeholder to the order side (to allow it to
infer a placeholder if needed) without recording a fix since placeholder can
be converted to `inout` and/or l-value and already indicates existence of a
problem at some other spot in the expression.
Resolves: rdar://76250381
If there is a contextual mismatch associated with a closure body,
make sure that the diagnostic is attached to the closure even
if the body is empty or implicit.
Resolves: rdar://52204608
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
Detect that direct callee couldn't be resolved e.g. due to an
invalid reference or a missing member and fail instead of
triggering an assert.
Resolves: rdar://problem/71525503
The change to the forward-scanning rule regressed some diagnostics,
because we no longer generated the special "trailing closure mismatch"
diagnostic. Reinstate the special-case "trailing closure mismatch"
diagnostic, but this time do so as part of the normal argument
mismatch diagnostics so it is based on type information.
While here, clean up the handling of missing-argument diagnostics to
deal with (multiple) trailing closures properly, so that we can (e.g)
suggest adding a new labeled trailing closure at the end, rather than
producing nonsensical Fix-Its.
And, note that SR-12291 is broken (again) by the forward-scan matching
rules.
Detect situation when it's impossible to determine types for
closure parameters used in the body from the context. E.g.
when a call closure is associated with refers to a missing
member.
```swift
struct S {
}
S.foo { a, b in } // `S` doesn't have static member `foo`
let _ = { v in } // not enough context to infer type of `v`
_ = .foo { v in } // base type for `.foo` couldn't be determined
```
Resolves: [SR-12815](https://bugs.swift.org/browse/SR-12815)
Resolves: rdar://problem/63230293
Accept trailing closures in following form:
```swift
foo {
<label-1>: { ... }
<label-2>: { ... }
...
<label-N>: { ... }
}
```
Consider each labeled block to be a regular argument to a call or subscript,
so the result of parser looks like this:
```swift
foo(<label-1>: { ... }, ..., <label-N>: { ... })
```
Note that in this example parens surrounding parameter list are implicit
and for the cases when they are given by the user e.g.
```swift
foo(bar) {
<label-1>: { ... }
...
}
```
location of `)` is changed to a location of `}` to make sure that call
"covers" all of the transformed arguments and parser result would look
like this:
```swift
foo(bar,
<label-1>: { ... }
)
```
Resolves: rdar://problem/59203764
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
