Add integer truncation and extension methods
Tracking issue: https://github.com/rust-lang/rust/issues/154330
This provides `.truncate()`, `.saturating_truncate()`, `.checked_truncate()`, and `.extend()`.
These only work within the same signedness (use `.cast_signed()` and `.cast_unsigned()` to change sign).
The truncation methods only work to smaller (or equal) types. `.extend()` only works to larger (or equal) types.
For the purposes of truncation and extending, `u128` is considered larger than or equal to the size of `usize`, and `usize` is considered larger than `u16` or `u8`. We might, in the future, want to consider ways to expand this.
Much of this was pair-programmed with @Amanieu.
In order to seal the new traits, this PR also adds a `core::sealed::Sealed`, like the one in `std`. I didn't modify `std` to re-export the same one, since by definition it isn't nameable, and since doing that would require that it be nameable (even if it was `#[unstable]`).
fix pin docs
This PR fixes a small grammatical error in the projection section of the pin docs. There is probably more than one answer for the fix, but I felt that this correction was the *smallest*.
std::net: clamp linger timeout value to prevent silent truncation.
Duration::as_secs() returns u64 but l_linger field type is narrower, c_int on most unix platforms, c_ushort on cygwin and windows. clamping before the cast, consistent with how set_timeout handles this.
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#154249 (Mention on which items the `missing_doc_code_examples` is not emitted)
- rust-lang/rust#154266 (UdpSocket: document `recv/recv_from` differences)
UdpSocket: document `recv/recv_from` differences
Per libs-api consensus, fixesrust-lang/rust#149392 by documenting possible platform-specific behavior in `UdpSocket`.
r? libs
This provides `.truncate()`, `.saturating_truncate()`,
`.checked_truncate()`, and `.extend()`.
These only work within the same signedness (use `.cast_signed()` and
`.cast_unsigned()` to change sign).
The truncation methods only work to smaller (or equal) types.
`.extend()` only works to larger (or equal) types.
For the purposes of truncation and extending, `usize` is considered
larger than `u16` or `u8`. This is consistent with `From`/`Into`
conversions.
Adding these methods results in needing to update the output of one test
that gets a new method-name similarity result.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Update libc to v0.2.183
Follow-up of https://github.com/rust-lang/rust/pull/150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
stabilizes `core::range::Range`
stabilizes `core::range::RangeIter`
stabilizes `std::range` which was missed in prior PRs
Updates docs to reflect stabilization (removed "experimental")
`RangeIter::remainder` is excluded from stabilization
Remove the `compiler-builtins` feature from default because it prevents
testing via the default `cargo test` command. It made more sense as a
default when `compiler-builtins` was a dependency that some crates added
via crates.io, but is no longer needed.
The `rustc-dep-of-std` feature is also removed since it doesn't do
anything beyond what the `compiler-builtins` feature already does.
update zulip link in `std` documentation
#docs doesn't seem to exist anymore, so point people to `t-libs`. Also include direct link to topic since Zulip is world-viewable now.
Add `IoSplit` diagnostic item for `std::io::Split`
Similar to the existing `IoLines` item. It will be used in Clippy to detect uses of `Split` leading to infinite loops similar to the existing lint for `Lines`.
feat: reimplement `hash_map!` macro
originally implemented in rust-lang/rust#144070, this had to be reverted in rust-lang/rust#148049 due to name ambiguity, as the macro was automatically put into the prelude. now, that rust-lang/rust#139493 has landed, it is possible to have a top-level macro, that is not exported by default, which should make it possible to reland this again.
implements rust-lang/rust#144032
implementation from rust-lang/rust#144070, original author has been added as co-author
effectively reverts rust-lang/rust#148049
Add doc links to `ExtractIf` of `BTree{Set,Map}` and `LinkedList`
There were links for `Hash{Set,Map}` and `Vec{,Deque}` versions, but not these three.
Don't fuse in `MapWindows`
cc https://github.com/rust-lang/rust/issues/87155
Fusing makes the iterator larger, slower, more complicated, and less useful. Users who need fusing behavior can always use `.fuse()`, but there is no way to get non-fusing behavior from the fused version.
@rustbot label A-iterators
simd_fmin/fmax: make semantics and name consistent with scalar intrinsics
This is the SIMD version of https://github.com/rust-lang/rust/pull/153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.
In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.
In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (https://github.com/rust-lang/stdarch/issues/2056).
Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?
Also see https://github.com/rust-lang/rust/issues/153395.
Merge `fabsf16/32/64/128` into `fabs::<F>`
Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :)
This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target.
Notes:
- I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs.
- Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs
- `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`.
- I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!
stabilizes `core::range::RangeFrom`
stabilizes `core::range::RangeFromIter`
add examples for `remainder` method on range iterators
`RangeFromIter::remainder` was not stabilized (see issue 154458)
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#152880 (Tweak incorrect assoc item note)
- rust-lang/rust#153526 (Fix LegacyKeyValueFormat report from docker build: i686)
- rust-lang/rust#153613 (interpreter error reporting: remove arguments that are always the same)
- rust-lang/rust#154029 (Replace `truncate(0)` with `clear()`)
- rust-lang/rust#154125 (Inline and remove `DepGraphData::try_mark_parent_green`.)
- rust-lang/rust#154185 (Prevent no_threads RwLock's write() impl from setting mode to -1 when it is locked for reading)
- rust-lang/rust#154394 (Normalize rustc path prefix when testing `-Z track-diagnostics`)
- rust-lang/rust#154450 (Use the normal arg-parsing machinery for `-Zassert-incr-state`)
- rust-lang/rust#154475 (Emit a pre-expansion feature gate warning for `box`'ed struct field patterns)
- rust-lang/rust#154500 (EnumSizeOpt: use Allocation::write_scalar instead of manual endianess logic)
- rust-lang/rust#154502 (interpret: ensure that untupled arguments are actually tuples)
Prevent no_threads RwLock's write() impl from setting mode to -1 when it is locked for reading
In my time updating the docs to `std::sync::RwLock` and adding a test verifying that max reader count is reachable in rust-lang/rust#153555, I noticed that the no_threads RwLock's `write()` implementation always sets the `mode` to `-1` (denoting writer locked) even though it could be reader locked. I feel like that's logically incorrect and that it should only be setting the `mode` to `-1` when we know that the mode is unlocked (`0`); `write()` should mirror the code that `read()` and `try_read()` has with `try_write()`.
For reference on read/try_read and write/try_write current implementations:
```rust
#[inline]
pub fn read(&self) {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
} else {
rtabort!("rwlock locked for writing");
}
}
#[inline]
pub fn try_read(&self) -> bool {
let m = self.mode.get();
if m >= 0 {
self.mode.set(m + 1);
true
} else {
false
}
}
#[inline]
pub fn write(&self) {
if self.mode.replace(-1) != 0 { // <-- This behavior logically does something different than what `try_write` does
rtabort!("rwlock locked for reading")
}
}
#[inline]
pub fn try_write(&self) -> bool {
if self.mode.get() == 0 {
self.mode.set(-1);
true
} else {
false
}
}
```
r? @jhpratt
Use common Timestamp impl in Hermit (attempt 2)
The goal is to have less code to maintain, so to be able to make changes easier.
Previous attempt https://github.com/rust-lang/rust/pull/148847 was asked to postpone because there was restructure of code, which is complete now.
r? joboet
bors