Skip to content

[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

Merged
merged 1 commit into from
Nov 1, 2017

Conversation

xedin
Copy link
Contributor

@xedin xedin commented Oct 24, 2017

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

@xedin xedin requested a review from rudkx October 24, 2017 05:03
@xedin
Copy link
Contributor Author

xedin commented Oct 24, 2017

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Oct 24, 2017

@swift-ci please smoke test

@xedin
Copy link
Contributor Author

xedin commented Oct 24, 2017

@swift-ci please test source compatibility

@xedin
Copy link
Contributor Author

xedin commented Oct 27, 2017

@rudkx WDYT?

Copy link
Contributor

@rudkx rudkx left a 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.

}

let result = foo({ (a: Int) -> Int in a + 1 })
assert(result == 42)
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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?).

Copy link
Contributor Author

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.

Copy link
Contributor

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
@xedin
Copy link
Contributor Author

xedin commented Nov 1, 2017

@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 })
Copy link
Contributor Author

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?

@rudkx
Copy link
Contributor

rudkx commented Nov 1, 2017

LGTM!

@xedin
Copy link
Contributor Author

xedin commented Nov 1, 2017

@swift-ci please test source compatibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants