Add Extend::{extend_one,extend_reserve}
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
This adds new optional methods on `Extend`: `extend_one` add a single
element to the collection, and `extend_reserve` pre-allocates space for
the predicted number of incoming elements. These are used in `Iterator`
for `partition` and `unzip` as they shuffle elements one-at-a-time into
their respective collections.
Various minor improvements to Ipv6Addr::Display
Cleaned up `Ipv6Addr::Display`, especially with an eye towards simplifying and reducing duplicated logic. Also added a fast-path optimization, similar to #72399 and #72398.
- Defer to `Ipv4Addr::fmt` when printing an Ipv4 address
- Fast path: write directly to `f` without an intermediary buffer when there are no alignment options
- Simplify finding the inner zeroes-span
Implement total_cmp for f32, f64
# Overview
* Implements method `total_cmp` on `f32` and `f64`. This method implements a float comparison that, unlike the standard `partial_cmp`, is total (defined on all values) in accordance to the IEEE 754 (rev 2008) §5.10 `totalOrder` predicate.
* The method has an API similar to `cmp`: `pub fn total_cmp(&self, other: &Self) -> crate::cmp::Ordering { ... }`.
* Implements tests.
* Has documentation.
# Justification for the API
* Total ordering for `f32` and `f64` has been discussed many time before:
* https://internals.rust-lang.org/t/pre-pre-rfc-range-restricting-wrappers-for-floating-point-types/6701
* https://github.com/rust-lang/rfcs/issues/1249
* https://github.com/rust-lang/rust/pull/53938
* https://github.com/rust-lang/rust/issues/5585
* The lack of total ordering leads to frequent complaints, especially from people new to Rust.
* This is an ergonomics issue that needs to be addressed.
* However, the default behaviour of implementing only `PartialOrd` is intentional, as relaxing it might lead to correctness issues.
* Most earlier implementations and discussions have been focusing on a wrapper type that implements trait `Ord`. Such a wrapper type is, however not easy to add because of the large API surface added.
* As a minimal step that hopefully proves uncontroversial, we can implement a stand-alone method `total_cmp` on floating point types.
* I expect adding such methods should be uncontroversial because...
* Similar methods on `f32` and `f64` would be warranted even in case stdlib would provide a wrapper type that implements `Ord` some day.
* It implements functionality that is standardised. (IEEE 754, 2008 rev. §5.10 Note, that the 2019 revision relaxes the ordering. The way we do ordering in this method conforms to the stricter 2008 standard.)
* With stdlib APIs such as `slice::sort_by` and `slice::binary_search_by` that allow users to provide a custom ordering criterion, providing additional helper methods is a minimal way of adding ordering functionality.
* Not also does it allow easily using aforementioned APIs, it also provides an easy and well-tested primitive for the users and library authors to implement an `Ord`-implementing wrapper, if needed.
SocketAddr and friends now correctly pad its content
Currently, `IpAddr` and friends correctly respect formatting parameters when printing via `Display`. This PR makes SocketAddr and friends do the same thing.
Implement PartialOrd and Ord for SocketAddr*
The implementation is mostly the same as the one found in `IpAddr` (other than adding comparison for ports, of course).
Continues #53788 and #53863Fixes#53710
Add core::future::IntoFuture
This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!
cc/ @rust-lang/wg-async-foundations
## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
This patch adds `core::future::IntoFuture`. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering. That integration should be done in a follow-up PR.
- Defer to Ipv4Addr::fmt when printing an Ipv4 address
- Fast path: write directly to f without an intermediary buffer when
there are no alignment options
- Simplify finding the inner zeroes-span
impl From<Cow> for Box, Rc, and Arc
These forward `Borrowed`/`Owned` values to existing `From` impls.
- `Box<T>` is a fundamental type, so it would be a breaking change to add a blanket impl. Therefore, `From<Cow>` is only implemented for `[T]`, `str`, `CStr`, `OsStr`, and `Path`.
- For `Rc<T>` and `Arc<T>`, `From<Cow>` is implemented for everything that implements `From` the borrowed and owned types separately.
abort_internal is safe
`sys::abort_internal` is stably exposed as a safe function. Forward that assumption "inwards" to the `sys` module by making the function itself safe, too.
This corresponds to what https://github.com/rust-lang/rust/pull/72204 did for the intrinsic. We should probably wait until that lands because some of the intrinsic calls in this PR might then need adjustments.
use the new interface to initialize conditional variables
HermitCore introduce a new interface to intialize conditional variables.
Consequently, minor changes are required to support this interface.
make abort intrinsic safe, and correct its documentation
Turns out `std::process::abort` is not the same as the intrinsic, the comment was just wrong. Quoting from the unix implementation:
```
// On Unix-like platforms, libc::abort will unregister signal handlers
// including the SIGABRT handler, preventing the abort from being blocked, and
// fclose streams, with the side effect of flushing them so libc buffered
// output will be printed. Additionally the shell will generally print a more
// understandable error message like "Abort trap" rather than "Illegal
// instruction" that intrinsics::abort would cause, as intrinsics::abort is
// implemented as an illegal instruction.
```
Alexis Bourget