There is a slight edge case when adding and subtracting a `Duration`
from a `SystemTime`, namely when the duration itself is finer/smaller
than the time precision on the operating systems.
On most (if not all non-Windows) operating systems, the precision of
`Duration` aligns with the `SystemTime`, both being one nanosecond.
However, on Windows, this time precision is 100ns, meaning that adding
or subtracting a `Duration` whose value is `< Duration::new(0, 100)`
will result in that method behaving like an addition/subtracting of
`Duration::ZERO`, due to the `Duration` getting rounded-down to the zero
value.
This commit introduces two new constants to SystemTime: `MIN` and `MAX`,
whose value represent the maximum values for the respective data type,
depending upon the platform.
Technically, this value is already obtainable during runtime with the
following algorithm: Use `SystemTime::UNIX_EPOCH` and call `checked_add`
(or `checked_sub`) repeatedly with `Duration::new(0, 1)` on it, until it
returns None. Mathematically speaking, this algorithm will terminate
after a finite amount of steps, yet it is impractical to run it, as it
takes practically forever.
Besides, this commit also adds a unit test. Concrete implementation
depending upon the platform is done in later commits.
In the future, the hope of the authors lies within the creation of a
`SystemTime::saturating_add` and `SystemTime::saturating_sub`, similar
to the functions already present in `std::time::Duration`. However, for
those, these constants are crucially required, thereby this should be
seen as the initial step towards this direction.
Below are platform specifc notes:
# Hermit
The HermitOS implementation is more or less identitcal to the Unix one.
# sgx
The implementation uses a `Duration` to store the Unix time, thereby
implying `Duration::ZERO` and `Duration::MAX` as the limits.
# solid
The implementation uses a `time_t` to store the system time within a
single value (i.e. no dual secs/nanosecs handling), thereby implying its
`::MIN` and `::MAX` values as the respective boundaries.
# UEFI
UEFI has a weird way to store times, i.e. a very complicated struct.
The standard proclaims "1900-01-01T00:00:00+0000" to be the lowest
possible value and `MAX_UEFI_TIME` is already present for the upper
limit.
# Windows
Windows is weird. The Win32 documentation makes no statement on a
maximum value here. Next to this, there are two conflicting types:
`SYSTEMTIME` and `FILETIME`. Rust's Standard Library uses `FILETIME`,
whose limit will (probably) be `i64::MAX` packed into two integers.
However, `SYSTEMTIME` has a lower-limit.
# xous
It is similar to sgx in the sense of using a `Duration`.
# unsupported
Unsupported platforms store a `SystemTime` in a `Duration`, just like
sgx, thereby implying `Duration::ZERO` and `Duration::MAX` as the
respective limits.
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Setup for writing different tests for the `nonpoison::Condvar` since it
will have a different API.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Stabilize `rwlock_downgrade` library feature
Tracking Issue: https://github.com/rust-lang/rust/issues/128203
Method to be stabilized:
```rust
impl<'a, T: ?Sized> RwLockWriteGuard<'a, T> {
pub fn downgrade(s: Self) -> RwLockReadGuard<'a, T> {}
}
```
~~I would like to point out that my documentation comment is longer than ideal, but at the same time I don't really know how else to show why `downgrade` is actually necessary (instead of just unlocking and relocking). If anyone has ideas for making this more concise that would be great!~~ I have made the documentation a bit more clear.
Stabilization report: https://github.com/rust-lang/rust/issues/128203#issuecomment-3016682463
Support `#[rustc_align_static]` inside `thread_local!`
Tracking issue: rust-lang/rust#146177
```rust
thread_local! {
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = const { 0 };
}
```
This increases the amount of recursion the macro performs (once per attribute in addition to the previous once per item), making it easier to hit the recursion limit. I’ve added workarounds to limit the impact in the case of long doc comments, but this still needs a crater run just in case.
r? libs
``@rustbot`` label A-attributes A-macros A-thread-locals F-static_align T-libs
Add `Path::has_trailing_sep` and related methods
Implements rust-lang/libs-team#335.
Tracking issue: rust-lang/rust#142503
Notable differences from ACP:
* `trim_trailing_sep` was added to `Path` since it felt reasonable to ensure that the inverse operation was available.
* Per suggestion of `@kennytm,` added `push_trailing_sep` and `pop_trailing_sep` to `PathBuf` in addition to `set_trailing_sep`.
This also updates some of the docs on various `Path` methods to use the term "trailing separator" instead of "trailing slash" for consistency.
Miri: non-deterministic floating point operations in foreign_items
Take 2 of rust-lang/rust#143906. The last 2 commits are what changed compared to the original pr.
Verified the tests using (fish shell):
```fish
env MIRIFLAGS="-Zmiri-max-extra-rounding-error -Zmiri-many-seeds" ./x miri --no-fail-fast std core coretests -- f32 f64
```
r? `@RalfJung`
Implementation: `#[feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::condvar`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`.
There are two other changes here. The first is that the `Barrier` implementation is migrated to use the `nonpoison::Condvar` instead of the `poison` variant. The second (which might be subject to some discussion) is that `WaitTimeoutResult` is moved up to `mod.rs`, as both `condvar` variants need that type (and I do not know if there is a better place to put it now).
### Related PRs
- `nonpoison_rwlock` implementation: https://github.com/rust-lang/rust/pull/144648
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
Adds tests for the `nonpoison::Mutex` variant by using a macro to
duplicate the existing `poison` tests.
Note that all of the tests here are adapted from the existing `poison`
tests.
Also steals the `test_mutex_arc_condvar` test from `mutex.rs`.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Fixes an issue where if the underlying `Once` panics because it is
poisoned, the panic displays the wrong message.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
[RTE-513] Ignore sleep_until test on SGX
rust-lang/rust#141829 added a test for `sleep_until`: it checks whether its specification holds:
> Puts the current thread to sleep until the specified deadline has passed.
but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls.
The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
Adds tests for the `nonpoison::RwLock` variant by using a macro to
duplicate the existing `poison` tests.
Note that all of the tests here are adapted from the existing `poison`
tests.
Miri: non-deterministic floating point operations in `foreign_items`
Part of [rust-lang/miri/#3555](https://github.com/rust-lang/miri/issues/3555#issue-2278914000), this pr does the `foreign_items` work.
Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added.
Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`.
I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as:
```
Returns
The sinh functions return sinh x.
```
So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
Clara Engler