Rollup of 14 pull requests #150957
Merged
Rollup of 14 pull requests #150957
+332
−188
Conversation
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
…he resulting collection
On FreeBSD 15, the error code returned in this situation changed. It's now ENETUNREACH. I think that error code is reasonable, and it's documented for connect(2), so we should expect that it might be returned.
`cargotest` can only detect the worst offenders (like tests failing, or hard compiler errors / ICEs), but regardless, bumping `diesel` to a way more recent version hopefully contributes slightly towards helping us not break `diesel` if at all possible.
std supports redirecting stdio file descriptors.
- Make flush a noop since it is only for buffered writers. - Also forward fsync to datasync. UEFI does not have anything separate for metadata sync. Signed-off-by: Ayush Singh <[email protected]>
Since yesterday, the LLVM `main` branch should have working `f16` on all platforms that Rust supports; this will be LLVM version 22, so update how `cfg(target_has_reliable_f16)` is set to reflect this. Within the rust-lang organization, this currently has no effect. The goal is to start catching problems as early as possible in external CI that runs top-of-tree rust against top-of-tree LLVM, and once testing for the rust-lang bump to LLVM 22 starts. Hopefully this will mean that we can fix any problems that show up before the bump actually happens, meaning `f16` will be about ready for stabilization at that point (with some considerations for the GCC patch at [1] propagating). References: * llvm/llvm-project@919021b * llvm/llvm-project@054ee2f * llvm/llvm-project@db26ce5 * llvm/llvm-project@549d7c4 * llvm/llvm-project@4903c62 [1]: gcc-mirror/gcc@8b6a18e
- Tested using OVMF on QEMU. Signed-off-by: Ayush Singh <[email protected]>
stabilize `Peekable::next_if_map` (`#![feature(peekable_next_if_map)]`) # Stabilization report ## Summary `#![feature(peekable_next_if_map)]` is a variation of `next_if` on peekable iterators that can transform the peeked item. This creates a way to take ownership of the next item in an iterator when some condition holds, but put the item back when the condition doesn't hold. This pattern would otherwise have needed unwraps in many cases. [Tracking issue](rust-lang#143702) ### What is stabilized ```rust impl<I: Iterator> Peekable<I> { pub fn next_if_map<R>( &mut self, f: impl FnOnce(I::Item) -> Result<R, I::Item>, ) -> Option<R> { .. } pub fn next_if_map_mut<R>( &mut self, f: impl FnOnce(&mut I::Item) -> Option<R>, ) -> Option<R> { .. } } ``` Example usage adapted from the ACP: ```rust let mut it = Peekable::new("123".chars()); while let Some(digit) = it.next_if_map(|c| c.to_digit(10).ok_or(c)) { codepoint = codepoint * 10 + digit; } ``` or with `next_if_map_mut`: ```rust let mut it = Peekable::new("123".chars()); while let Some(digit) = iter.next_if_map_mut(|c| c.to_digit(10)) { line_num = line_num * 10 + digit; } ``` Note that the major difference here is that `next_if_map_mut` does not get owned items from the iterator, but mutable references. With that api, the closure can return an `Option` which avoids an `ok_or`. This may require cloning or copying the iterator elements, so if that is expensive, the owned version, `next_if_map`, may be preferable. ### Nightly use At the moment, this feature is barely used in nightly, though I've found multiple good uses for it in my own projects, hence my pushing for stabilization. It makes the kind of patterns used in recursive descent parsing super concise and maybe with its stabilization it will find more use. ### Test coverage Besides a quite comprehensive doctest, this feature is tested (including panicking in the closure) here: https://github.com/rust-lang/rust/blob/c880acdd3171dfafdb55be8cd9822a857e99348d/library/coretests/tests/iter/adapters/peekable.rs#L275-L359 ## History - ACP: rust-lang/libs-team#613 accepted with rust-lang/libs-team#613 (comment) - implementation: rust-lang#143725 with tests, and no issues reported since july. ## Acknowledgments ACP, implementation and tracking issue for this feature all by @kennytm <3
adding Ordering enum to minicore.rs, importing minicore in "tests/assembly-llvm/rust-abi-arg-attr.rs" test file this adds the `Ordering` enum to `minicore.rs`. consequently, this updates `tests/assembly-llvm/rust-abi-arg-attr.rs` to import `minicore` directly. previously, this test file contained traits like `Copy` `Clone` `PointeeSized`, which were giving a duplicate lang item error, so replace those by importing `minicore` completely.
…Jung Unix implementation for stdio set/take/replace Tracking issue: rust-lang#150667 ACP: rust-lang/libs-team#500
Reword the collect() docs Update the `Iterator::collect` docs so they explain that the return type, not the iterator itself, determines which collection is built. Follow up on rust-lang#121140
…acrum Fix the connect_error test on FreeBSD 15+ On FreeBSD 15, the error code returned in this situation changed. It's now ENETUNREACH. I think that error code is reasonable, and it's documented for connect(2), so we should expect that it might be returned.
…ulacrum Use `rand` crate more idiomatically Small cleanup, found while working on something else. We were using `rand` un-idiomatically in a couple of places, and it was bugging me...
…lacrum Bump `diesel` to the most recent commit in `cargotest` `cargotest` can only detect the worst offenders (like tests failing, or hard compiler errors / ICEs), but regardless, bumping `diesel` to a way more recent version hopefully contributes slightly towards helping us not break `diesel` if at all possible. That is, AFAIUI, this will not help catch [#t-compiler/prioritization/alerts > rust-lang#149845 Diesel stops building with nightly-2025-12-10 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/245100-t-compiler.2Fprioritization.2Falerts/topic/.23149845.20Diesel.20stops.20building.20with.20nightly-2025-12-10/near/566975273) because we cap-lints to `warn` in `cargotest`. Most recent commit as of the time of this PR anyway.
std: sys: fs: uefi: Implement File::flush - Also forward fsync and datasync to flush. UEFI does not have anything separate for metadata sync. @rustbot label +O-UEFI
Reenable GCC CI download Now that we have the `gcc-dev` artifacts on CI. However, I forgot to bump download-ci-gcc-stamp before 🤦 So I will also have to bump it for this PR.
llvm: Update `reliable_f16` configuration for LLVM22 Since yesterday, the LLVM `main` branch should have working `f16` on all platforms that Rust supports; this will be LLVM version 22, so update how `cfg(target_has_reliable_f16)` is set to reflect this. Within the rust-lang organization, this currently has no effect. The goal is to start catching problems as early as possible in external CI that runs top-of-tree rust against top-of-tree LLVM, and once testing for the rust-lang bump to LLVM 22 starts. Hopefully this will mean that we can fix any problems that show up before the bump actually happens, meaning `f16` will be about ready for stabilization at that point (with some considerations for the GCC patch at [1] propagating). References: * llvm/llvm-project@919021b * llvm/llvm-project@054ee2f * llvm/llvm-project@db26ce5 * llvm/llvm-project@549d7c4 * llvm/llvm-project@4903c62 [1]: gcc-mirror/gcc@8b6a18e
std: sys: fs: uefi: Implement File::seek - Tested using OVMF on QEMU. @rustbot label +O-UEFI
Subscribe myself to attr parsing
Remove special case for `AllowedTargets::CrateLevel` r? @jdonszelmann
Member
Author
|
@bors r+ rollup=never p=5 |
rust-bors
bot
added
S-waiting-on-bors
Contributor
Member
Author
|
@bors try jobs=x86_64-mingw-1 |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Jan 11, 2026
Rollup of 14 pull requests try-job: x86_64-mingw-1
This comment has been minimized.
This comment has been minimized.
Contributor
Contributor
Contributor
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 08f833a (parent) -> 1279939 (this PR) Test differencesShow 694 test diffsStage 0
Stage 1
(and 274 additional test diffs) Additionally, 320 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 1279939b38db460bd3844a6ca44e94961a48333d --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 |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 08f833aa17 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 11, 2026
Collaborator
|
Finished benchmarking commit (1279939): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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.6%, secondary 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.2%, secondary -0.0%)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: 474.227s -> 473.69s (-0.11%) |
This was referenced Jan 12, 2026
Member
|
Kicked off two perf runs (#150930 (comment), #150942 (comment)). I doubt there's much to be done about the regression if it is attribute parsing related though. |
Contributor
rustbot
added
the
perf-regression-triaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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:
Peekable::next_if_map(#![feature(peekable_next_if_map)]) #148941 (stabilizePeekable::next_if_map(#![feature(peekable_next_if_map)]))randcrate more idiomatically #150781 (Userandcrate more idiomatically)dieselto the most recent commit incargotest#150812 (Bumpdieselto the most recent commit incargotest)reliable_f16configuration for LLVM22 #150908 (llvm: Updatereliable_f16configuration for LLVM22)AllowedTargets::CrateLevel#150930 (Remove special case forAllowedTargets::CrateLevel)#[rustc_has_incoherent_inherent_impls]to attribute parser #150942 (Port#[rustc_has_incoherent_inherent_impls]to attribute parser)Failed merges:
#[must_not_suspend]to attribute parser #150943 (Port#[must_not_suspend]to attribute parser)r? @ghost
Create a similar rollup