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
Make `Ipv6Addr::multicast_scope()` exhaustive
And make `Ipv6MulticastScope` exhaustive, with `repr(u8)` and the proper discriminant values. The variants for the two reserved scopes are gated behind a perma-unstable feature, in order to avoid committing to names for them.
[IETF RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291#section-2.7) and [IETF RFC 7346](https://datatracker.ietf.org/doc/html/rfc7346#section-2) define the list of multicast scopes. The former document says:
> scopes labeled "(unassigned)" are available for administrators to define additional multicast regions.
Tracking issue: https://github.com/rust-lang/rust/issues/27709
@rustbot label A-io
simd_add/sub/mul/neg: document overflow behavior
`simd_neg` had an odd comment about overflow not being UB, without saying what the behavior is instead. Replace that by just saying this uses wrapping arithmetic, and add the same for add/sub/mul. div/rem are already documented to cause UB on div-by-zero and min-div-by-minus-one, and shl/shr cause UB on too large shift amounts.
Link from `assert_matches` to `debug_assert_matches`
This resolves a FIXME which was added in https://github.com/rust-lang/rust/pull/151423.
r? @Amanieu
(Reviewer of rust-lang/rust#151423.)
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`.
Require avxvnni for avx10.2
AVX10.2 supports masked (and 512-bit) versions of some intrinsics available in AVXVNNI, AVXVNNIINT8 and AVXVNNIINT16 (e.g. AVX10.2 introduces `_mm{,256,512}_{mask{z}}_dpbuud_epi32` corresponding to `_mm{,256}_dpbuud_epi32` from AVXVNNIINT8). But Intel (being Intel), didn't (at least not in SDM) enforce that AVX10.2 (or at least AVX10_VNNI_INT, which is a "discrete AVX10 feature", introduced alongside AVX10.2, and expected to house more such instructions) requires AVXVNNI etc.
To make this (admittedly very Intel) situation a bit better, we can just require these features from the Rust frontend
r? @Amanieu
This also corrects a mistake in std-detect which allowed AVX10 to be enabled without AVX512F, in the (odd) case when F16C or FMA are not available (we require these for AVX512F because otherwise the LLVM assembler doesn't work)
Also, delete impls on non-Deref types.
Pin doesn't do anything useful for non-Deref types, so PinCoerceUnsized
on such types makes no sense.
This is a breaking change, since stable code can observe the deleted
`PinCoerceUnsized` impls by uselessly coercing between such types
inside a `Pin`.
There is still some strange behavior, such as `Pin<&mut i32>` being
able to coerce to `Pin<&dyn Send>`, but not being able to coerce to
`Pin<&i32>`. However, I don't think it's possible to fix this.
Fixes https://github.com/rust-lang/rust/issues/145081
Jonathan Brouwer