rust/src/libstd/sys/redox/time.rs, branch 1.35.0

libstd: deny(elided_lifetimes_in_paths)

2019-03-31T10:56:51+00:00

Update sys::time impls to have checked_sub_instant

2019-03-22T22:56:40+00:00

libstd => 2018

2019-02-27T19:06:15+00:00

std: Force `Instant::now()` to be monotonic

2019-01-07T16:00:47+00:00

This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940

Remove licenses

2018-12-26T04:08:33+00:00

Add checked_sub for Instant and SystemTime

2018-12-13T14:25:14+00:00

Add checked_add method to Instant time type

2018-12-13T14:25:14+00:00

Auto merge of #55527 - sgeisler:time-checked-add, r=sfackler

2018-11-25T19:01:35+00:00

Implement checked_add_duration for SystemTime [Original discussion on the rust user forum](https://users.rust-lang.org/t/std-systemtime-misses-a-checked-add-function/21785) Since `SystemTime` is opaque there is no way to check if the result of an addition will be in bounds. That makes the `Add` trait completely unusable with untrusted data. This is a big problem because adding a `Duration` to `UNIX_EPOCH` is the standard way of constructing a `SystemTime` from a unix timestamp. This PR implements `checked_add_duration(&self, &Duration) -> Option` for `std::time::SystemTime` and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many `add_duration(&self, &Duration) -> SystemTime` functions to avoid redundancy (they now unwrap the result of `checked_add_duration`). Some basic unit tests for the newly introduced function were added too. I wasn't sure which stabilization attribute to add to the newly introduced function, so I just chose `#[stable(feature = "time_checked_add", since = "1.32.0")]` for now to make it compile. Please let me know how I should change it or if I violated any other conventions. P.S.: I could only test on Linux so far, so I don't necessarily expect it to compile for all platforms.

use ? operator instead of match

2018-11-16T06:56:07+00:00

Implement checked_add_duration for SystemTime

2018-11-16T06:55:24+00:00

Since SystemTime is opaque there is no way to check if the result of an addition will be in bounds. That makes the Add trait completely unusable with untrusted data. This is a big problem because adding a Duration to UNIX_EPOCH is the standard way of constructing a SystemTime from a unix timestamp. This commit implements checked_add_duration(&self, &Duration) -> Option for std::time::SystemTime and as a prerequisite also for all platform specific time structs. This also led to the refactoring of many add_duration(&self, &Duration) -> SystemTime functions to avoid redundancy (they now unwrap the result of checked_add_duration). Some basic unit tests for the newly introduced function were added too.