Fix SchedulerTypeTime distance(to:) #104
Merged
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.
The new versions of
RunLoop
andOperationQueue
(copied from the Apple implementations) have incorrect implementations ofSchedulerTimeType::distance(to:)
.The original Apple implementations rely on
Date::distance(to:)
, which is only available on the 2019 and later systems. So CombineX replaces the use ofDate::distance(to:)
withDate::timeIntervalSince(_:)
.The problem is that the calls to
timeIntervalSince
havedate
andother.date
in the wrong places, so each call todistance(to:)
returns aStride
with a flipped sign.This pull request contains two commits.
The first commit adds a test case demonstrating the incorrect behavior. The test case succeeds when compiled with Combine and fails when compiled with CombineX. The test case is a little tricky because I was unable to make it compile with Combine using the
RunLoop.CX.SchedulerTimeType
type. I worked around it with type inference, so that it usesRunLoop.SchedulerTimeType
when compiled with Combine andRunLoop.CX.SchedulerTimeType
when compiled with CombineX.The second commit fixes the two implementations of
distance(to:)
.