Rollup of 9 pull requests#154519
Closed
JonathanBrouwer wants to merge 21 commits intorust-lang:mainfrom
Closed
Conversation
Add `bounds::FloatPrimitive` Exhaustive float pattern match Fix GCC use span bugs
This create conflict if the timespec of a target has additional fields. Use libc::timespec::default() instead
stabilizes `core::range::RangeFrom` stabilizes `core::range::RangeFromIter` add examples for `remainder` method on range iterators `RangeFromIter::remainder` was not stabilized (see issue 154458)
…gross35 Update libc to v0.2.183 Follow-up of rust-lang#150484. This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.
…, 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
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
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
Contributor
Author
|
Trying commonly failed jobs |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 28, 2026
Rollup of 9 pull requests try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Mar 28, 2026
…uwer Rollup of 9 pull requests Successful merges: - #150752 (Update libc to v0.2.183) - #153380 (stabilize new RangeFrom type and iterator) - #153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - #154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - #154494 (triagebot: add reminder for bumping CI LLVM stamp) - #153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - #154320 (`trim_prefix` for paths) - #154453 (Fix ice in rustdoc of private reexport) - #154515 (Notify stdarch maintainers on changes in std_detect)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for babfce8 failed: CI. Failed job:
|
Contributor
|
PR #150752, which is a member of this rollup, was unapproved. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
fabsf16/32/64/128intofabs::<F>#153834 (Mergefabsf16/32/64/128intofabs::<F>)trim_prefixfor paths #154320 (trim_prefixfor paths)r? @ghost
Create a similar rollup