This commit introduces initial, unstable support for Unix domain sockets
(UDS) on Windows, behind the `windows_unix_domain_sockets` feature gate
Added types:
- `std::os::windows::net::SocketAddr`: represents a UDS address with support
for pathname addresses (abstract and unnamed are parsed but not yet fully
supported).
- `std::os::windows::net::UnixListener`: server-side UDS listener.
- `std::os::windows::net::UnixStream`: client/server stream for UDS.
Key features:
- Binding and connecting using filesystem paths.
- Basic I/O via `Read`/`Write`.
- Address querying (`local_addr`, `peer_addr`).
- Non-blocking mode, timeouts, and socket duplication.
- Includes basic test coverage for smoke, echo, path length, and bind reuse.
remove `#[deprecated]` from unstable & internal `SipHasher13` and `24` types
These types are unstable and `doc(hidden)` (under the internal feature `hashmap_internals`). Deprecating them only adds noise (`#[allow(deprecated)]`) to all places where they are used, so this PR removes the deprecation attributes from them.
It also includes a few other small cleanups in separate commits, including one I overlooked in rust-lang/rust#151228.
There are a number of instances of `FIXME(f16_f128)` related to target
configuration; either these could use `target_has_reliable_f128`, or the
FIXME is describing such a cfg and is thus redundant (since any
`cfg(target_has_reliable_f*)` needs to be removed before stabilization
anyway).
Switch to using `target_has_reliable_*` where applicable and remove the
redundant FIXMEs.
This commit implements the following methods:
* `SystemTime::saturating_add`
* `SystemTime::saturating_sub`
* `SystemTime::saturating_duration_since`
The implementation of these methods is rather trivial, as the main logic
lies behind the constants `SystemTime::MIN` and `SystemTime::MAX`.
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.
Make Barrier RefUnwindSafe again
This commit manually implements `RefUnwindSafe` for `std::sync::Barrier` to fixrust-lang/rust#146087. This is a fix for a regression indroduced by e95db591a4
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>
