Sort implicits with a proper comparison function #12562
Merged
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
|
test performance please |
|
performance test scheduled: 1 job(s) in queue, 1 running. |
|
@odersky I ended up not adding a tie-break based on names like discussed in #12479 (comment) since that isn't actually necessary for a total ordering and so shouldn't matter here |
|
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/12562/ to see the changes. Benchmarks is based on merging with master (450f8ac) |
Before this commit, we sorted implicits using `prefer` which relied on `compareOwner`, but compareOwner does not induce a total ordering: just because `compareOwner(x, y) == 0` does not mean that `compareOwner(x, z)` and `compareOwner(y, z)` have the same sign, this violates the contract of `java.util.Comparator#compare` and lead to an IllegalArgumentException sometimes being thrown (although I wasn't able to reproduce that, see scala#12479) This commit fixes by this by replacing the usage of `compareOwner` by a new `compareBaseClassesLength` which does induce a total ordering while still hopefully approximating `compareOwner` well enough for our purposes. We also replace `prefer` which returned a Boolean by `compareEligibles` which is directly usable as an Ordering we can pass to `sorted`, this is more efficient than using `sortWith(prefer)` because the latter might end up calling `prefer` twice for a single comparison. Fixes scala#12479 (I hope).
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.
Before this commit, we sorted implicits using
preferwhich relied oncompareOwner, but compareOwner does not induce a total ordering: justbecause
compareOwner(x, y) == 0does not mean thatcompareOwner(x, z)andcompareOwner(y, z)have the same sign, this violates thecontract of
java.util.Comparator#compareand lead to anIllegalArgumentException sometimes being thrown (although I wasn't able
to reproduce that, see #12479)
This commit fixes by this by replacing the usage of
compareOwnerby anew
compareBaseClassesLengthwhich does induce a total ordering whilestill hopefully approximating
compareOwnerwell enough for ourpurposes.
We also replace
preferwhich returned a Boolean bycompareEligibleswhich is directly usable as an Ordering we can pass to
sorted, this ismore efficient than using
sortWith(prefer)because the latter might endup calling
prefertwice for a single comparison.Fixes #12479 (I hope).