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.
Each candidate with incorrect labels (but everything else lined up)
gets a note on its declarationm which says what is expected and what
has been given.
For multiple solutions with fixes for the same call, replace
`ambiguous reference` diagnostic with the one that explicitly
mentions that there are no exact matches, and provide partially
matched candidates as notes.
If `subscript(dynamicMember:)` is unviable because it's either
an instance method referenced on type or static method
referenced on an instance of type, attempting dynamic
member lookup would be incorrect since it's unclear
what is intended.
Resolves: rdar://problem/48994658
If closure expression is malformed don't try to suggest a fix-it
about destructuring, because there is no way to figure out where
it would actually go in the source.
Resolves: rdar://problem/51576862
This test is technically scaling linearly in the metrics being
checked, but it was still taking 5+ minutes to type check. Reduce the
upper bound so it finishes in a reasonable amount of time.
When favoring particular constraints in a disjunction, don't remove
the old disjunction and create a new one---it's just churn in the
constraint system. Instead, favor the constraints that need it.
This technically flips the SR-139 test case from "too complex" to
being fast enough, but it's still fairly slow.
Looks like obsoleted initializer has been removed,
and there are no solutions available for 'init(truncatingBitPattern:)'
which leads to performance regression with designated types enabled.
Resolves: rdar://problem/48061151
`selectApplyDisjunction` only makes sense in conjunction with
designated types feature because it's going to prioritize disjunctions
with arguments which are known to conform to literal protocols.
Prioritization like that is harmful without designated types feature
because it doesn't always lead to better constraint system splits,
and could prioritize bigger disjunctions which harms chances to
short-circuit solving.
Resolves: rdar://problem/47492691
Currently if member has been found through same-type constraint
it would only be properly handled when it comes from a class type,
because that's the only time when base type gets replaced with
"concrete" type from equivalence class, but nested types could also
come from structs, enums and sometimes protocols (e.g. typealias)
which `resolveDependentMemberType` has to handle.
Resolves: rdar://problem/47334176
