Uh oh!
There was an error while loading. Please reload this page.
Rollup of 8 pull requests - #158676
Merged
Merged
Conversation
Clarify that GuardBack initializes arrays from the end. Restore performance note for iter_next_chunk_erased regarding optimization issues.
I copied the impl block from Guard without noticing that Destruct was only there for const contexts. Consumed the suggestion, thanks. Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
…troduced next_chunk_back implementation in IntoIter, updated documentation, and added test cases for DoubleEndedIterator::next_chunk_back
Add support for LoongArch LSX and LASX registers in inline assembly by introducing the `vreg` and `xreg` register classes, along with their associated vector types and operand modifiers. The new register classes are gated behind the `asm_experimental_reg` feature. Also model the overlap between FPU, LSX, and LASX registers so register conflict checking works correctly for aliased registers.
Add UI tests for LoongArch LSX/LASX inline asm registers, including target-feature gating and overlap diagnostics between `fN`, `vrN`, and `xrN` registers.
Add assembly tests for LoongArch inline asm register modifiers. Verify that the `w` and `u` modifiers correctly select LSX and LASX register views for `freg`, `vreg`, and `xreg` operands and produce the expected register names in the generated assembly.
Change HirId to its parent item LocalDefId.
We don't need any features from `twox-hash`, and in particular this removes the last use of `rand v0.8` in our lock file.
## Fix struct links There are several structs (`ExitStatus` and `ExitStatusError`) that could be linked, but aren't. Fixed. All links show their struct now instead of previously some showed `process::ExitStatus` when rendered. ## Add `wait` links The docs distinguish `wait` as code, but do not link to **what** wait they're referring to. As this is Unix extension documentation, adding a link to the POSIX standard for `wait`. Showing a construction of an `ExitStatus` for both a signal and an exit code helps to highlight and internalize what **wait status, not an exit status** means. ## Example for `from_raw` Current documentation calls out "The value should be a **wait status, not an exit status**." but it's unclear what exactly that means without a reference or an example. I added a doctest that shows you need to shift by 8 to get the desired result and annotated it with information about how that's derived based on the linked `wait` documentation. ## Example to `ExitStatus::signal` Called out that a signaled process does not also produce an exit code. Added an example. Called out that just because a process reports that it was not terminated via a signal doesn't mean it never got one (it could be handled). Also added a note correlating shell behavior to exit codes: GNU Bash manual: https://web.archive.org/web/20260625050034/https://www.gnu.org/software/bash/manual/bash.html#Exit-Status-1 > [...] a fatal signal whose number is N, Bash uses the value 128+N as the exit status. FreeBSD bash(1) man page: https://man.freebsd.org/bash/1 > The return value [...] 128+n if the command is terminated by signal n. ## Panic scope on `from_raw` This change is based on preference/experience: When I originally read this documentation, it was because I clicked through `Output` -> `ExitStatus`. While the text "Creates a new `ExitStatus` or `ExitStatusError`" is present at the top, I didn't internalize what that meant exactly. Therefore, when I got to the panic section, I was mildly confused. This edit makes the behavior more explicitly attached to the type. While the original format had all of the same information available, it was left for the reader to bridge that "making an ExitStatusError" is referring to `ExitStatus::from_raw` as that's the only constructor (for now). Making this bridge more explicit also future-proofs us for future constructors (if they're ever added) that may or may not panic. While the context of the panic documentation is directly attached to `from_raw`, it's slightly (pedantically) more correct to not imply that ANY way of creating an ExitStatusError` from a `wait` of `0` will panic (a different constructor could perhaps return an option instead). Technically, the syntax isn't correct, as it should be `<ExitStatusError as ExitStatusExt>::from_raw`, but I think this conveys intent without being overly verbose. Co-authored-by: Colin Casey <casey.colin@gmail.com>
…xt_chunk_back, r=aapoalas Implement `DoubleEndedIterator::next_chunk_back` This PR builds off on @vinDelphini's [PR](rust-lang#151668) on introducing `DoubleEndedIterator::next_chunk_back` (which will be used in a follow up PR to optimize `ArrayChunks::try_rfold` once merged). This was in the works since late Jan and I thought to pick it up and get this over the finish line as vinDelphini has been away from the PR for a couple of months. I've made sure to pull from vinDelphini's branch to keep him authored on the commits he made. Other things introduced from this PR is specialization like done for `Iterator::next_chunk`, constifying some stuff, making a custom `DoubleEndedIterator::next_chunk_back` for `IntoIter` (since it also has a custom impl of `Iterator::next_chunk`), and a bunch of tests mirroring that of `Iterator::next_chunk`. There's no tracking issue for this yet, but the ACP for this introduction is [here](rust-lang/libs-team#734). I'll create the tracking issue for this soon. ---- Actually, can we have `DoubleEndedIterator::next_chunk_back` underneath [`Iterator::next_chunk` tracking issue](rust-lang#98326)?
std: use `OnceLock` for SGX environment variable storage The SGX environment code predates the existence of `OnceLock` and `AtomicPtr` and consequently violates strict provenance. By using `OnceLock` we can remove all the `unsafe` code (except for the `unsafe` in the function signatures, that's required by other platforms). CC @jethrogb@raoulstrackx@aditijannu
…d, r=aapoalas
Implement `ptr::{read,write}_unaligned` via `repr(packed)`
We already support doing unaligned reads & writes via `repr(packed)` fields, so this just uses that support from the backend rather than needing to thinks about `memcpy` and `intrinsics::forget` and such.
Turns out in codegen this ends up essentially identical because the packed type read gets `BackendRepr::Memory` and thus the read/write of the packed type *is* an `align 1` memcpy, just like the library code before this PR. But doing this gives much simpler MIR and rust-lang#158291 will make it better than the previous version by not needing to emit the `memcpy` at all for things like `read_unaligned::<u32>`.
First commit are some tests that pass on master; Second commit changes the implementation and shows the corresponding test changes.
r? libs…esleywiser Change `adjust_ident_and_get_scope` arg to `LocalDefId` Addresses a FIXME. Change a HirId to its owner LocalDefId.
…atus-ext, r=Darksonn Clarify ExitStatusExt documentation ## Fix struct links There are several structs (`ExitStatus` and `ExitStatusError`) that could be linked, but aren't. Fixed. All links show their struct now instead of previously some showed `process::ExitStatus` when rendered. ## Add `wait` links The docs distinguish `wait` as code, but do not link to **what** wait they're referring to. As this is Unix extension documentation, adding a link to the POSIX standard for `wait`. Showing a construction of an `ExitStatus` for both a signal and an exit code helps to highlight and internalize what **wait status, not an exit status** means. ## Example for `from_raw` Current documentation calls out "The value should be a **wait status, not an exit status**." but it's unclear what exactly that means without a reference or an example. I added a doctest that shows you need to shift by 8 to get the desired result and annotated it with information about how that's derived based on the linked `wait` documentation. ## Example to `ExitStatus::signal` Called out that a signaled process does not also produce an exit code. Added an example. Called out that just because a process reports that it was not terminated via a signal doesn't mean it never got one (it could be handled). Also added a note correlating shell behavior to exit codes: GNU Bash manual: https://web.archive.org/web/20260625050034/https://www.gnu.org/software/bash/manual/bash.html#Exit-Status-1 > [...] a fatal signal whose number is N, Bash uses the value 128+N as the exit status. FreeBSD bash(1) man page: https://man.freebsd.org/bash/1 > The return value [...] 128+n if the command is terminated by signal n. ## Panic scope on `from_raw` This change is based on preference/experience: When I originally read this documentation, it was because I clicked through `Output` -> `ExitStatus`. While the text "Creates a new `ExitStatus` or `ExitStatusError`" is present at the top, I didn't internalize what that meant exactly. Therefore, when I got to the panic section, I was mildly confused. This edit makes the behavior more explicitly attached to the type. While the original format had all of the same information available, it was left for the reader to bridge that "making an ExitStatusError" is referring to `ExitStatus::from_raw` as that's the only constructor (for now). Making this bridge more explicit also future-proofs us for future constructors (if they're ever added) that may or may not panic. While the context of the panic documentation is directly attached to `from_raw`, it's slightly (pedantically) more correct to not imply that ANY way of creating an ExitStatusError` from a `wait` of `0` will panic (a different constructor could perhaps return an option instead). Technically, the syntax isn't correct, as it should be `<ExitStatusError as ExitStatusExt>::from_raw`, but I think this conveys intent without being overly verbose.
…camelid rustdoc: Show use-site paths for unevaluated const array lengths After rust-lang#158171, I noticed a few additional issues with the rendering of consts in rustdoc. This PR fixes them. When rendering array lengths, avoid inlining the full definition of unevaluated constants via `print_inlined_const`. Instead, fall back to `Const::to_string()` for use-site rendering, matching the behavior already used for projections without bodies. r? camelid
rustc_target/asm: add LoongArch LSX/LASX inline asm register support Add support for LoongArch LSX and LASX registers in inline assembly by introducing the `vreg` and `xreg` register classes, along with their associated vector types and operand modifiers. The new register classes are gated behind the `asm_experimental_reg` feature. Also model the overlap between FPU, LSX, and LASX registers so register conflict checking works correctly for aliased registers.
rustc_sanitizers: use twox-hash without default features We don't need any features from `twox-hash`, and in particular this removes the last use of `rand v0.8` in our lock file.
jhpratt
commented
Jul 1, 2026
MemberAuthor
@bors r+ rollup=never p=5 |
Contributor
This comment has been minimized.
This comment has been minimized.
Contributor
rust-timer
commented
Jul 2, 2026
Collaborator
📌 Perf builds for each rolled up PR:
previous master: 4c9d2bfe4a In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 4c9d2bf (parent) -> 2371d69 (this PR) Test differencesShow 192 test diffsStage 1
Stage 2
Additionally, 169 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 2371d697abddba53be85137d5a68064066b4ae10 --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 |
rust-timer
commented
Jul 2, 2026
Collaborator
Finished benchmarking commit (2371d69): comparison URL. Overall result: ✅ improvements - 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 -2.8%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.2%, secondary -0.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 488.059s -> 486.119s (-0.40%) |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
12 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:
DoubleEndedIterator::next_chunk_back#156737 (ImplementDoubleEndedIterator::next_chunk_back)OnceLockfor SGX environment variable storage #158180 (std: useOnceLockfor SGX environment variable storage)ptr::{read,write}_unalignedviarepr(packed)#158427 (Implementptr::{read,write}_unalignedviarepr(packed))adjust_ident_and_get_scopearg toLocalDefId#158531 (Changeadjust_ident_and_get_scopearg toLocalDefId)r? @ghost
Create a similar rollup