Fix generic bound of `str::SplitInclusive`'s `DoubleEndedIterator` impl
`str::SplitInclusive`'s `DoubleEndedIterator` implementation currently uses a `ReverseSearcher` bound for the corresponding searcher. A `DoubleEndedSearcher` bound should have been used instead.
`DoubleEndedIterator` requires that repeated `next_back` calls produce the same items as repeated `next` calls, in opposite order. `ReverseSearcher` lets you search starting from the back of a string, but it makes no guarantees about how its matches correspond to the matches found by a forward search. `DoubleEndedSearcher` is a subtrait of `ReverseSearcher` and does require that the same matches are found in both directions.
This bug fix is a breaking change. Calling `next_back` on `"a+++b".split_inclusive("++")` is currently accepted with repeated calls producing `"b"` and `"a+++"`, while forward iteration yields `"a++"` and `"+b"`. Also see https://github.com/rust-lang/rust/issues/100756#issuecomment-1221307166 for more details.
I believe that this is the only iterator that uses this bound incorrectly — other related iterators such as `str::Split` do have a `DoubleEndedSearcher` bound for their `DoubleEndedIterator` implementation. And `slice::SplitInclusive` doesn't face this problem at all because it doesn't use patterns, only a predicate.
cc `@SkiFire13`
Rollup of 4 pull requests
Successful merges:
- #116277 (dont call mir.post_mono_checks in codegen)
- #116400 (Detect missing `=>` after match guard during parsing)
- #116458 (Properly export function defined in test which uses global_asm!())
- #116500 (Add tvOS to target_os for register_dtor)
r? `@ghost`
`@rustbot` modify labels: rollup
Reuse existing `Some`s in `Option::(x)or`
LLVM still has trouble re-using discriminants sometimes when rebuilding a two-variant enum, so when we have the correct variant already built, just use it.
That's shorter in the Rust code, as well as simpler in MIR and the optimized LLVM, so might as well: <https://rust.godbolt.org/z/KhdE8eToW>
Thanks to `@veber-alex` for pointing out this opportunity in https://github.com/rust-lang/rust/issues/101210#issuecomment-1732470941
Rollup of 6 pull requests
Successful merges:
- #115454 (Clarify example in docs of str::char_slice)
- #115522 (Clarify ManuallyDrop bit validity)
- #115588 (Fix a comment in std::iter::successors)
- #116198 (Add more diagnostic items for clippy)
- #116329 (update some comments around swap())
- #116475 (rustdoc-search: fix bug with multi-item impl trait)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a comment in std::iter::successors
The `unfold` function have since #58062 been renamed to `from_fn`.
(I'm not sure if this whole comment is still useful—it's not like there are many iterators that *can't* be based on `from_fn`. Anyway, in its current form this comment is not correct, and it sent me into a half-hour research of what happened to `unfold` function, so I want to do *something* with it 🙃 deleting these three lines is a perfectly fine alternative, in my opinion.)
Clarify example in docs of str::char_slice
Just a one word improvement.
“Last” can be misread as meaning the last (third) instead of the previous (first).
`waitqueue` clarifications for SGX platform
The documentation of `waitqueue` functions on the `x86_64-fortanix-unknown-sgx` platform is incorrect at some places and on others missing. This PR improves upon this.
cc: `@jethrogb`
LLVM still has trouble re-using discriminants sometimes when rebuilding a two-variant enum, so when we have the correct variant already built, just use it.
That's simpler in LLVM *and* in MIR, so might as well: <https://rust.godbolt.org/z/KhdE8eToW>
docs: Correct terminology in std::cmp
This PR is the result of some discussions on URLO:
* [Traits in `std::cmp` and mathematical terminology](https://users.rust-lang.org/t/traits-in-std-cmp-and-mathematical-terminology/69887)
* [Are poker hands `Ord` or `PartialOrd`?](https://users.rust-lang.org/t/are-poker-hands-ord-or-partialord/82644)
Arguably, the documentation currently isn't very precise regarding mathematical terminology. This can lead to misunderstandings of what `PartialEq`, `Eq`, `PartialOrd`, and `Ord` actually do.
While I believe this PR doesn't give any new API guarantees, it expliclitly mentions that `PartialEq::eq(a, b)` may return `true` for two distinct values `a` and `b` (i.e. where `a` and `b` are not equal in the mathematical sense). This leads to the consequence that `Ord` may describe a weak ordering instead of a total ordering.
In either case, I believe this PR should be thoroughly reviewed, ideally by someone with mathematical background to make sure the terminology is correct now, and also to ensure that no unwanted new API guarantees are made.
In particular, the following problems are addressed:
* Some clarifications regarding used (mathematical) terminology:
* Avoid using the terms "total equality" and "partial equality" in favor of "equivalence relation" and "partial equivalence relation", which are well-defined and unambiguous.
* Clarify that `Ordering` is an ordering between two values (and not an order in the mathematical sense).
* Avoid saying that `PartialEq` and `Eq` are "equality comparisons" because the terminology "equality comparison" could be misleading: it's possible to implement `PartialEq` and `Eq` for other (partial) equivalence relations, in particular for relations where `a == b` for some `a` and `b` even when `a` and `b` are not the same value.
* Added a section "Strict and non-strict partial orders" to document that the `<=` and `>=` operators do not correspond to non-strict partial orders.
* Corrected section "Corollaries" in documenation of `Ord` in regard to `<` only describing a strict total order in cases where `==` conforms to mathematical equality.
* ~~Added a section "Weak orders" to explain that `Ord` may also describe a weak order or total preorder, depending on how `PartialEq::eq` has been implemented.~~ (Removed, see [comment](https://github.com/rust-lang/rust/pull/103046#issuecomment-1279929676))
* Made documentation easier to understand:
* Explicitly state at the beginning of `PartialEq`'s documentation comment that implementing the trait will provide the `==` and `!=` operators.
* Added an easier to understand rule when to implement `Eq` in addition to `PartialEq`: "if it’s guaranteed that `PartialEq::eq(a, a)` always returns `true`."
* Explicitly mention in documentation of `Eq` that the properties "symmetric" and "transitive" are already required by `PartialEq`.
core library: Disable fpmath tests for i586 ...
This patch disables the floating-point epsilon test for i586 since x87 registers are too imprecise and can't produce the expected results.
Some clarifications regarding used (mathematical) terminology:
* Avoid using the terms "total equality" and "partial equality" in favor
of "equivalence relation" and "partial equivalence relation", which
are well-defined and unambiguous.
* Clarify that `Ordering` is an ordering between two values (and not an
order in the mathematical sense).
* Avoid saying that `PartialEq` and `Eq` are "equality comparisons"
because the terminology "equality comparison" could be misleading:
it's possible to implement `PartialEq` and `Eq` for other (partial)
equivalence relations, in particular for relations where `a == b` for
some `a` and `b` even when `a` and `b` are not the same value.
* Added a section "Strict and non-strict partial orders" to document
that the `<=` and `>=` operators do not correspond to non-strict
partial orders.
* Corrected section "Corollaries" in documenation of Ord in regard to
`<` only describing a strict total order in cases where `==` conforms
to mathematical equality.
Made documentation easier to understand:
* Explicitly state at the beginning of `PartialEq`'s documentation
comment that implementing the trait will provide the `==` and `!=`
operators.
* Added an easier to understand rule when to implement `Eq` in addition
to `PartialEq`: "if it’s guaranteed that `PartialEq::eq(a, a)` always
returns `true`."
* Explicitly mention in documentation of `Eq` that the properties
"symmetric" and "transitive" are already required by `PartialEq`.
Works around #115199 by temporarily disabling CFI for core and std CFI
violations to allow the user rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
Adapt `todo!` documentation to mention displaying custom values
Resolves#116130.
I copied from the [existing documentation](https://doc.rust-lang.org/std/macro.unimplemented.html) for `unimplemented!` more or less directly, down to the example trait used. I also took the liberty of fixing some formatting and typographical errors that I noticed.
Replace 'mutex' with 'lock' in RwLock documentation
When copying the documentation for `clear_poison` from Mutex, not every occurence of 'mutex' was replaced with 'lock'.
Improve UdpSocket documentation
I tried working with `UdpSocket` and ran into `EINVAL` errors with no clear indication of what causes the error. Also, it was uncharacteristically hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize` This one is just clarity. Usually, returned `usize`s indicate that the buffer might have only been sent partially. This is not the case with UDP. Since that `usize` must always be `buffer.len()`, I have documented that.
2. `bind` limits `connect` and `send_to` When you bind to a limited address space like localhost, you can only `connect` to addresses in that same address space. Error kind: `AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
For debugging the third one, it was really hard to find someone else who already had that problem. I only managed to find this thread: https://www.mail-archive.com/netdev@vger.kernel.org/msg159519.html
Add `must_use` on pointer equality functions
`ptr == ptr` (like all use of `==`) has a similar warning, and these functions are simple convenience wrappers over that.
Add missing #[inline] on AsFd impl for sys::unix::fs::File
This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
Correct misleading std::fmt::Binary example (#116165)
Nothing too crazy...
- Add two to the width specifier (so all 32 bits are correctly displayed)
- Pad out the compared string so the assert passes
- Add `// Note` comment highlighting the need for the extra width when using the `#` flag.
The exact contents (and placement?) of the note are, of course, highly bikesheddable.
Add track_caller attribute to Result::unwrap_or_else
Fixes issue where panics in unwrap_or_else callbacks marked with the `track_caller` attribute appear as errors in core.
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Partially outline code inside the panic! macro
This outlines code inside the panic! macro in some cases. This is split out from https://github.com/rust-lang/rust/pull/115562 to exclude changes to rustc.
Document that Instant may or may not include system-suspend time
Since people are still occasionally surprised by this let's make it more explicit. This doesn't add any new guarantees, only documents the status quo.
Related issues: #87906#79462
This operation should be extremely cheap, at most the mov of the underlying
file descriptor, but due to this missing #[inline] it is currently a function
call.
Add "integer square root" method to integer primitive types
For every suffix `N` among `8`, `16`, `32`, `64`, `128` and `size`, this PR adds the methods
```rust
const fn uN::isqrt() -> uN;
const fn iN::isqrt() -> iN;
const fn iN::checked_isqrt() -> Option<iN>;
```
to compute the [integer square root](https://en.wikipedia.org/wiki/Integer_square_root), addressing issue #89273.
The implementation is based on the [base 2 digit-by-digit algorithm](https://en.wikipedia.org/wiki/Methods_of_computing_square_roots#Binary_numeral_system_(base_2)) on Wikipedia, which after some benchmarking has proved to be faster than both binary search and Heron's/Newton's method. I haven't had the time to understand and port [this code](http://atoms.alife.co.uk/sqrt/SquareRoot.java) based on lookup tables instead, but I'm not sure whether it's worth complicating such a function this much for relatively little benefit.
Update windows ffi bindings
Bump `windows-bindgen` to version 0.51.1. This brings with it some changes to the generated FFI bindings, but little that affects the code.
One change that does have more of an impact is `SOCKET` being `usize` instead of either `u64` or `u32` (as is used in std's public `SOCKET` type). However, it's now easy enough to abstract over that difference.
Finally I added a few new bindings that are likely to be used in pending PRs, mostly to make sure they're ok with the new metadata.
r? libs
Convert `Into<ExitStatus> for ExitStatusError` to `From<ExitStatusError> for ExitStatus` in `std::process`
Implementing suggestion from https://github.com/rust-lang/rust/issues/84908#issuecomment-912352902:
> I believe the impl on ExitStatusError should be
>
> ```rust
> impl From<ExitStatusError> for ExitStatus
> ```
>
> rather than
>
> ```rust
> impl Into<ExitStatus> for ExitStatusError
> ```
>
> (there is generally never anything implemented as `Into` first, because implementing `From` reflexively provides `Into`)
Implement From<OwnedFd/Handle> for ChildStdin/out/err object
## Summary
Comments in `library/std/src/process.rs` ( ab08639e59 ) indicates that `ChildStdin`, `ChildStdout`, `ChildStderr` implements some traits that are not actually implemented: `FromRawFd`, `FromRawHandle`, and the `From<OwnedFd>/From<OwnedHandle>` from the io_safety feature.
In this PR I implement `FromRawHandle` and `FromRawFd` for those 3 objects.
## Usecase
I have a usecase where those implementations are basically needed. I want to customize
in the `Command::spawn` API how the pipes for the parent/child communications are created (mainly to strengthen the security attributes on them). I can properly setup the pipes,
and the "child" handles can be provided to `Child::spawn` easily using `Stdio::from_raw_handle`. However, there is no way to generate the `ChildStd*` objects from the raw handle of the created name pipe, which would be very useful to still expose the same API
than in other OS (basically a `spawn(...) -> (Child, ChildStdin, ChildStdout, ChildSterr)`, where on windows this is customized), and to for example use `tokio::ChildStdin::from_std` afterwards.
## Questions
* Are those impls OK to add? I have searched to see if those impls were missing on purpose, or if it was just never implemented because never needed. I haven't found any indication on why they couldn't be added, although the user clearly has to be very careful that the handle provided makes sense (i think, mainly that it is in overlapped mode for windows).
* If this change is ok, adding the impls for the io_safety feature would probably be best, or should it be done in another PR?
* I just copy-pasted the `#[stable(...)]` attributes, but the `since` value has to be updated, I'm not sure to which value.
