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.
It's possible to construct subscript member responsible for key path
dynamic member lookup in a way which is going to be self-recursive
and an attempt to lookup any non-existent member is going to trigger
infine recursion.
Let's guard against that by making sure that the base type of the
member lookup is different from root type of the key path.
Resolves: rdar://problem/50420029
Resolves: rdar://problem/57410798
Some constraint transformations require knowledge about what state
constraint system is currently in e.g. `constraint generation`,
`solving` or `diagnostics` to make a decision whether simplication
is possible. Notable example is `keypath dynamic member lookup`
which requires a presence of `applicable fn` constraint to retrieve
some contextual information.
Currently presence or absence of solver state is used to determine
whether constraint system is in `constraint generation` or `solving`
phase, but it's incorrect in case of `diagnoseFailureForExpr` which
tries to simplify leftover "active" constraints before it can attempt
type-check based diagnostics.
To make this more robust let's introduce (maybe temporarily until
type-check based diagnostics are completely obsoleted) a proper
notion of "phase" to constraint system so it is always clear what
transitions are allowed and what state constraint system is
currently in.
Resolves: rdar://problem/57201781
Also, add `-solver-expression-time-threshold=1` to a few tests.
This forces sr139, rdar25866240, and rdar23327871 to be moved from the
"fast" directory to the "slow" directory.
The non-gyb type checker performance tests tend to require non-assert
and release builds. This makes two tests consistent with the others.
This also fixes sr139.swift, which was needlessly running the type checker twice.
It's likely that these were listed as "REQUIRES: OS=macosx" to not
redundantly run them for iOS et al, but they don't take that long and
so it's more useful for Linux devs to be able to run them locally if
need be. Or to catch something that really is different on non-macOS.
The scale test says the behavior is exponential, but it should be
linear, given that (1) we provide a contextual type outside and
(2) there is precisely 1 type which has the corresponding cases.
