Rollup of 9 pull requests#154525
Conversation
Add `bounds::FloatPrimitive` Exhaustive float pattern match Fix GCC use span bugs
stabilizes `core::range::RangeFrom` stabilizes `core::range::RangeFromIter` add examples for `remainder` method on range iterators `RangeFromIter::remainder` was not stabilized (see issue 154458)
…, r=tgross35
stabilize new RangeFrom type and iterator
```rust
// in core and std
pub mod range;
// in core::range
pub struct RangeFrom<Idx> {
pub start: Idx,
}
impl<Idx: fmt::Debug> fmt::Debug for RangeFrom<Idx> { /* ... */ }
impl<Idx: PartialOrd<Idx>> RangeFrom<Idx> {
pub const fn contains<U>(&self, item: &U) -> bool
where
Idx: [const] PartialOrd<U>,
U: ?Sized + [const] PartialOrd<Idx>;
}
impl<Idx: Step> RangeFrom<Idx> {
pub fn iter(&self) -> RangeFromIter<Idx>;
}
impl<T> const RangeBounds<T> for RangeFrom<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeFrom<&T> { /* ... */ }
impl<T> const From<RangeFrom<T>> for legacy::RangeFrom<T> { /* ... */ }
impl<T> const From<legacy::RangeFrom<T>> for RangeFrom<T> { /* ... */ }
pub struct RangeFromIter<A>(/* ... */);
// `RangeFromIter::remainder` left unstable
impl<A: Step> Iterator for RangeFromIter<A> {
type Item = A;
/* ... */
}
impl<A: Step> FusedIterator for RangeFromIter<A> { }
impl<A: Step> IntoIterator for RangeFrom<A> {
type Item = A;
type IntoIter = RangeFromIter<A>;
/* ... */
}
unsafe impl<T> const SliceIndex<[T]> for range::RangeFrom<usize> {
type Output = [T];
/* ... */
}
unsafe impl const SliceIndex<str> for range::RangeFrom<usize> {
type Output = str;
/* ... */
}
impl ops::Index<range::RangeFrom<usize>> for CStr {
type Output = CStr;
/* ... */
}
```
Tracking issue: rust-lang#125687
…tgross35,RalfJung 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!
…alebzulawski,antoyo simd_fmin/fmax: make semantics and name consistent with scalar intrinsics This is the SIMD version of rust-lang#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 (rust-lang/stdarch#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 rust-lang#153395.
…ark-Simulacrum triagebot: add reminder for bumping CI LLVM stamp I'm not sure what else can be done automatically to help us not forget this, but at least this gives a chance for the PR author/reviewer to be reminded (e.g. myself).
…alueFormat-dist-x86_64, r=marcoieni Fix LegacyKeyValueFormat report from docker build: dist-x86_64 Part of rust-lang#152305 r? @marcoieni
…s, r=Mark-Simulacrum `trim_prefix` for paths under rust-lang#142312? its a useful method.
…triddle Fix ice in rustdoc of private reexport Fixes rust-lang#154383 The root cause is rustdoc could still try to resolve links for source docs that resolver did not cache in `ResolveDocLinks::Exported` mode. The test case will not crash with `--document-private-items` option, which will use `ResolveDocLinks::All`. The fix makes rustdoc skip link resolution based on the source `DefId` of each doc fragment, so its behavior stays aligned with resolver's logic here: https://github.com/chenyukang/rust/blob/dc5cb1719eed6ac9275fe93d914d32141606b2ac/compiler/rustc_resolve/src/late.rs#L685
move many tests from `structs-enums` to `structs` or `enum` This PR moves most of the tests in `ui/structs-enums` that are only about structs or only about enums to their respective directory, as a step towards removing `ui/structs-enums`. Followup to rust-lang#154131. r? @Kivooeo
Notify stdarch maintainers on changes in std_detect cc @Amanieu @folkertdev @Kobzol It would be nice to be notified when std_detect changes, as it is spiritually a part of stdarch. Also assign @rust-lang/libs to std_detect
|
@bors r+ p=5 rollup=never |
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: 3f3c6f45dc In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 3f3c6f4 (parent) -> 148adf2 (this PR) Test differencesShow 437 test diffsStage 1
Stage 2
(and 78 additional test diffs) Additionally, 259 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 148adf223edb0444eb1f99753919dd2080c2a534 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (148adf2): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.2%, secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 485.867s -> 492.806s (1.43%) |
Successful merges:
fabsf16/32/64/128intofabs::<F>#153834 (Mergefabsf16/32/64/128intofabs::<F>)trim_prefixfor paths #154320 (trim_prefixfor paths)structs-enumstostructsorenum#154504 (move many tests fromstructs-enumstostructsorenum)r? @ghost
Create a similar rollup