-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ConstraintSolver] Avoid unnecessarily increasing score when matching function types #12593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci please smoke test |
@swift-ci please smoke test |
@swift-ci please test source compatibility |
@rudkx WDYT? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM, but I think we want to avoid the execution test here and make sure the performance differences are real.
test/Constraints/rdar35142121.swift
Outdated
} | ||
|
||
let result = foo({ (a: Int) -> Int in a + 1 }) | ||
assert(result == 42) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really need to be an executable test. You could do -emit-sil
and match by mangled name on the actual function that's getting called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion! I'll try that right away.
@@ -1,4 +1,4 @@ | |||
// RUN: %scale-test --invert-result --begin 2 --end 7 --step 1 --select incrementScopeCounter %s | |||
// RUN: %scale-test --begin 2 --end 10 --step 1 --select incrementScopeCounter %s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit surprising that this would have a real effect on whether this is fast or slow. Are you confident this is a real improvement, or was this perhaps not really slow before (e.g. it was slow over that range but wasn't truly exponential?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a real improvement because this triggers logic in the solveSimplified
where solver is not going to look at generic overloads if it could find non-generic one with the same score, since we are not increasing the score here some of the cases are going to behave better than before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense.
… function types Remove function-to-function type match score increase, which should only happen contextually in presence of other restrictions, this used to fix the case related to matching of arrays of functions with and w/e `throws` as function parameters which used to be ambigious, and now handled by collection-upcast conversion score. Resolves: rdar://problem/35142121
@swift-ci please smoke test |
} | ||
|
||
// CHECK: function_ref @_T012rdar351421213fooS3icF : $@convention(thin) (@owned @noescape @callee_owned (Int) -> Int) -> Int | ||
let _ = foo({ (a: Int) -> Int in a + 1 }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rudkx Does this look better?
LGTM! |
@swift-ci please test source compatibility |
Remove function-to-function type match score increase, which should only
happen contextually in presence of other restrictions, this used to fix
the case related to matching of arrays of functions with and w/e
throws
as function parameters which used to be ambigious, and now handled by
collection-upcast conversion score.
Resolves: rdar://problem/35142121