Add checked_add method to Instant time type #56490
Conversation
|
r? @Kimundi (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
I started by writing my code using |
src/libstd/time.rs
Outdated
|
|
||
| // Check that the checked_add_duration implementations seem approximately correct | ||
| let start = Instant::now(); | ||
| thread::sleep(Duration::from_millis(500)); |
There was a problem hiding this comment.
I'm aware that time based tests are incredibly unreliable and usually not a good thing. But I felt that given the fact that the different implementations use time in vastly different scales it would be fairly easy to accidentally treat nanos as millis or similar. As such I thought something like this might help catch errors on the magnitude scale.
There was a problem hiding this comment.
I wonder if perhaps you could do let end = start + Duration::from_millis(500)? I'm not sure that it's necessary to mix-in Instant::now() testing here perhaps?
There was a problem hiding this comment.
Then the sleep is of no use. The sleep + Instant::now() is the way to create two instants separated in time without using the add functionality of Instant. Or am I missing something?
The a +year test just a few lines above make sure the normal add and the checked add produce the same results.
There was a problem hiding this comment.
Ah ok I think I see what you want to test, in that case I think it's fine to omit this test itself. It's true that Instant::now is notoriously hard to test correctly, so it's ok to just avoid it on this one!
There was a problem hiding this comment.
I removed that part of the test completely 👍
faern
force-pushed
the
add-checked-add-to-instant
branch
from
a16f8e4
to
daf2aab
Compare
|
r? @eddyb |
|
@Dylan-DPC I wish we had a better categorized list of reviewers. For example, I'm not a libs person, so I'm only really useful for some parts of the compiler + r? @alexcrichton or @sfackler |
|
This looks great to me, thanks! Could the |
faern
force-pushed
the
add-checked-add-to-instant
branch
from
daf2aab
to
6641501
Compare
|
Moving some stuff out of |
|
Also while you're at it, want to add a |
|
I feel it would be the most consistent to do the exact same thing for subtraction. Add |
|
Either way's fine by me, but given how our queue time isn't always the greatest adding them here seems fine by me |
faern
force-pushed
the
add-checked-add-to-instant
branch
from
6641501
to
5a6146f
Compare
|
Done. Added |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
faern
force-pushed
the
add-checked-add-to-instant
branch
from
5a6146f
to
3358de3
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
faern
force-pushed
the
add-checked-add-to-instant
branch
from
3358de3
to
442abbc
Compare
|
@bors: r+ 👍 |
|
📌 Commit 442abbc has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 442abbc with merge e4b6d8d03250adf354e0896e4abbdda1166dfbe4... |
|
📌 Commit 59496a99761e94f9633ac6997fe8b671f917a85b has been approved by |
bors
added
S-waiting-on-bors
faern
force-pushed
the
add-checked-add-to-instant
branch
from
59496a9
to
9e5e89a
Compare
|
This PR screwed the rollup. I have fixed the error from the log now. But I have not verified it will build on cloudabi, not sure how to do a cross platform check from my Linux machine. |
|
@faern You can use |
|
Thank you. This changes everything! :) I was going to dig into the travis config to figure out how to do that. But now I don't have to. I now also realize it's actually in the rustc guide if you just look hard enough, so I was apparently not RTFM:ing enough :) Well, what's in this PR right now passes the EDIT: |
|
Great :) Let's give this another try... @bors r=alexcrichton |
|
📌 Commit 9e5e89a has been approved by |
…=alexcrichton Add checked_add method to Instant time type Appending functionality to the already opened topic of `checked_add` on time types over at rust-lang#55940. Doing checked addition between an `Instant` and a `Duration` is important to reliably determine a future instant. We could use this in the `parking_lot` crate to compute an instant when in the future to wake a thread up without risking a panic.
Add checked_add method to Instant time type Appending functionality to the already opened topic of `checked_add` on time types over at #55940. Doing checked addition between an `Instant` and a `Duration` is important to reliably determine a future instant. We could use this in the `parking_lot` crate to compute an instant when in the future to wake a thread up without risking a panic.
|
☀️ Test successful - status-appveyor, status-travis |
Eliminate Receiver::recv_timeout panic Fixes #54552. This panic is because `recv_timeout` uses `Instant::now() + timeout` internally. This possible panic is not mentioned in the documentation for this method. Very recently we merged (still unstable) support for checked addition (#56490) of `Instant + Duration`, so it's now finally possible to add these together without risking a panic.
…ce, r=shepmaster Simplify checked_duration_since This follows the same design as we updated to in rust-lang#56490. Internally, all the system specific time implementations are checked, no panics. Then the panicking publicly exported API can just call the checked version of itself and make do with a single panic (`expect`) at the top. Since the internal sys implementations are now checked, this gets rid of the extra `if self >= &earlier` check in `checked_duration_since`. Except likely making the generated machine code simpler, it also reduces the algorithm from "Check panic condition -> call possibly panicking method" to just "call non panicking method". Added two test cases: * Edge case: Make sure `checked_duration_since` on two equal `Instant`s produce a zero duration, not a `None`. * Most common/intended usage: Make sure `later.checked_duration_since(earlier)`, returns an expected value.
…ce, r=shepmaster Simplify checked_duration_since This follows the same design as we updated to in rust-lang#56490. Internally, all the system specific time implementations are checked, no panics. Then the panicking publicly exported API can just call the checked version of itself and make do with a single panic (`expect`) at the top. Since the internal sys implementations are now checked, this gets rid of the extra `if self >= &earlier` check in `checked_duration_since`. Except likely making the generated machine code simpler, it also reduces the algorithm from "Check panic condition -> call possibly panicking method" to just "call non panicking method". Added two test cases: * Edge case: Make sure `checked_duration_since` on two equal `Instant`s produce a zero duration, not a `None`. * Most common/intended usage: Make sure `later.checked_duration_since(earlier)`, returns an expected value.
…ce, r=shepmaster Simplify checked_duration_since This follows the same design as we updated to in rust-lang#56490. Internally, all the system specific time implementations are checked, no panics. Then the panicking publicly exported API can just call the checked version of itself and make do with a single panic (`expect`) at the top. Since the internal sys implementations are now checked, this gets rid of the extra `if self >= &earlier` check in `checked_duration_since`. Except likely making the generated machine code simpler, it also reduces the algorithm from "Check panic condition -> call possibly panicking method" to just "call non panicking method". Added two test cases: * Edge case: Make sure `checked_duration_since` on two equal `Instant`s produce a zero duration, not a `None`. * Most common/intended usage: Make sure `later.checked_duration_since(earlier)`, returns an expected value.
Appending functionality to the already opened topic of
checked_addon time types over at #55940.Doing checked addition between an
Instantand aDurationis important to reliably determine a future instant. We could use this in theparking_lotcrate to compute an instant when in the future to wake a thread up without risking a panic.