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.
Is the same argument is out-of-order in multiple solutions, let's
diagnose it as if there was no ambiguity.
Resolves: SR-14093
Resolves: rdar://73600328
It's possible that different overload choices could have the same
conformance requirement, so diagnostics should be able to emit an
error in situations where multiple solutions point to the missing
conformance at the same location (both in AST and requirement list).
Resolves: rdar://74447308
Look through specifier (inout, l-value) and optional types while
checking for presence of dependent member types to avoid inferring
incorrect bindings (which could lead to infinite recursion in the
solver).
Resolves: SR-13856
Resolves: rdar://problem/71383770
It's possible that covariant result type is wrapped in l-value.
Just like currently preserved optionality, transformation should
maintain l-valueness of a result type as well.
Resolves: rdar://problem/71167129
If one of the statements in the result builder body fails to
apply solution, let's fail entire rewrite attempt, otherwise
type-checker would end up with AST that has null pointers for
some child nodes.
Resolves: rdar://problem/70256351
Instead of failing constraint generation upon encountering
an invalid declaration, let's turn that declaration into a
potential hole and keep going. Doing so enables the solver
to reach a solution and diagnose any other issue with
expression.
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Start visiting transitive fixed bindings for type
variables, and stop visiting adjacencies for
`gatherConstraint`'s `AllMentions` mode.
This improves performance and fixes a correctness
issue with the old implementation where we could
fail to re-activate a coercion constraint, and
then let invalid code get past Sema, causing
either miscompiles or crashes later down the
pipeline.
Unfortunately this change requires us to
temporarily drop the non-ephemeral fix for a couple
of fairly obscure cases where the overload hasn't
yet been resolved. The logic was previously relying
on stale adjacency state in order to re-activate
the fix when the overload is bound, but it's not
connected on the constraint graph. We need to find
a way to connect constraints to unresolved
overloads they depend on.
Resolves SR-12369.
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
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
The previous code expects output like this:
```
define hidden swiftcc i8* @"$s6SR82094test10ObjectiveC8SelectorVyF"() #0 {
```
But in certain build modes, we get extra debug information that looks like this:
```
define hidden swiftcc i8* @"$s6SR82094test10ObjectiveC8SelectorVyF"() #0 !dbg !47 {
```
I stumbled over this while running tests with a variety of different
options.
Can't use `ConstraintSystem::addImplicitLoadExpr` because that would
only cache types in constraint system and wouldn't propagate them to AST,
since that happens in `ExprRewritter::finalize` during regular solution
application. `TypeChecker::addImplicitLoadExpr` should be used directly
in cases like that.
Resolves: rdar://problem/58972627
It used to be "fast" before because `selectDisjunction` used to pick
inner `==`s before outer one (which compares arrays) but now, since
constraint generation for the closure body is delayed, it looks
like the opposite is happening which makes this test-case go exponential.
This test-case has been improved by changes in closure expression
handling in constraint system, because the bodies are going to be
opened in order, the nesting yields linear performance.
