[ConstraintSystem] Return of the new disjunction favoring/selection algorithm #79461
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
@swift-ci please build toolchain |
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
f785515 to
21a3705
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
xedin
force-pushed
the
solver-perf-frankenstein
branch
2 times, most recently
from
f442ec8 to
6a4b7e7
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
367b059 to
37e3e32
Compare
|
@swift-ci please test |
|
@swift-ci please test source compatibility |
|
Debug source compatibility failure is UPASS on Doggie which is expected. |
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
37e3e32 to
a7ac64a
Compare
xedin
force-pushed
the
solver-perf-frankenstein
branch
3 times, most recently
from
d593771 to
d8608a3
Compare
|
@swift-ci please test |
2 tasks
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
d8608a3 to
d156df4
Compare
|
@swift-ci please clean test |
|
@swift-ci please test source compatibility |
|
@swift-ci please test Windows platform |
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
d156df4 to
a806a05
Compare
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
a806a05 to
cc06572
Compare
xedin
force-pushed
the
solver-perf-frankenstein
branch
2 times, most recently
from
02ab2dd to
a779459
Compare
…s are considered Some of the disjunctions are not supported by the optimizers but could still be a better choice than an operator. Using a non-score based preference mechanism first allows us to make sure that operator disjunctions are not selected too eagerly in some situations when i.e. a member (supported or not) could be a better choice. `isPreferable` currently targets only operators in result builder contexts but it could be expanded to more uses in the future.
…ameters and ternary expressions We need to have a notion of "complete" binding set before we can allow inference from generic parameters and ternary, otherwise we'd make a favoring decision that might not be correct i.e. `v ?? (<<cond>> ? nil : o)` where `o` is `Int`. `getBindingsFor` doesn't currently infer transitive bindings which means that for a ternary we'd only have a single binding - `Int` which could lead to favoring overload of `??` and has non-optional parameter on the right-hand side.
The test was slow with hacks but now it's much faster - takes about 63k scopes to solve, it could be improved by introducing new overloads of prefix `-` to stdlib.
…plyExpr`s The original hack never applied to subscripts.
…tors vs. non-operators The problem this is trying to solve is eager selection of operators over unsupported disjunctions, when matching operators let's take speculative information into account because it helps to make better choices in this case.
…arameter types When matching candidate like `[Int]` against `Array<Element>` we need to conservatively assume that if the nominals match the argument is a viable exact match because otherwise it's possible to skip some of the valid matches when other overload choice have generic parameters at the same parameter position.
…ments or variadic overloads This matches the behavior of the old hack where favoring choices were rolled back if `mustConsider` produced `true` which happened only for protocol requirements and variadic overload choice regardless of their viability.
Instead of checking both protocols, check one that matches best depending on where `String` literal candidate came from.
…ices are failable If all of the viable initializer overloads are failable, the only valid inference choice is an optional candidate type.
…hod which is printed at the end
…rator chains Most of them don't have any children but string interpolation does and that marks whole chain as unsupported.
These choices could be better than some other non-disfavored ones in certain situations i.e. when `async` overload is disfavored but appears in async context it's preferrable to a non-async overload choice. Note that the code that mimic old hacks still needs to filter on `@_disfavoredOverload` in few places to maintain source compatibility.
…ing to `isArray()`
…he call instead of callee `calleeFn` now returns the underlying declaration reference looking through `ConstructorRefCallExpr`, which means the downgrade logic needs to check whether the call is using initializer reference before making a decision.
This is helpful in situations when all of the chained operators have literal arguments because it would make sure that every operator has the same score if there is no contextual type.
… status
If the scores are the same and both disjunctions are operators
they could be ranked purely based on whether the candidates
were speculative or not. The one with more context always wins.
Consider the following situation:
```swift
func test(_: Int) { ... }
func test(_: String) { ... }
test("a" + "b" + "c")
```
In this case we should always prefer ... + "c" over "a" + "b"
because it would fail and prune the other overload if parameter
type (aka contextual type) is `Int`.
…e result type Previously only nominal type and existential where allowed but that's outdated, it's possible to reference a member of an opaque result type as well, the concrete type in this case is going to be deduced by the solver.
- Expand the inference to include prefix and postfix unary operators - Recognize previously resolved declaration and member references in argument positions and record their types. - Expand reconciliation logic from Double<->Int to include other floating-point types and `CGFloat`.
xedin
force-pushed
the
solver-perf-frankenstein
branch
from
798cbfe to
56812e7
Compare
|
@swift-ci please clean test |
|
@swift-ci please test macOS platform |
|
@swift-ci please Windows platform |
|
@swift-ci please test Windows platform |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LinkedExprAnalyzerplaybook_OptionalNilComparisonTypeas candidate fornilwhile analyzing==and!=operatorsInt? -> T