Rollup of 12 pull requests #151716
Merged
Rollup of 12 pull requests #151716
+815
−685
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
Enum variant layouts don't need to store a full `LayoutShape`; just storing
the fields offsets is enough and all other information can be inferred from
the parent layout:
- size, align and ABI don't make much sense for individual variants and
should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and
`variant: VariantShape::Single { .. }`.
…8r-unknown-none-softfloat`. The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode. The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it. This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
…around a compiler intrinsic
Switch to parsing float literals for overflow checks using `rustc_apfloat` rather than host floats. This avoids small variations in platform support and makes it possible to start checking `f16` and `f128` as well. Using APFloat matches what we try to do elsewhere to avoid platform inconsistencies.
… r=Amanieu Stabilize ppc inline assembly This stabilizes inline assembly for PowerPC and PowerPC64. Corresponding reference PR: rust-lang/reference#2056 --- From the requirements of stabilization mentioned in rust-lang#93335 > Each architecture needs to be reviewed before stabilization: > * It must have clobber_abi. Done in rust-lang#146949. > * It must be possible to clobber every register that is normally clobbered by a function call. Done in rust-lang#131341 Similarly, `preserves_flags` is also implemented by this PR. Likewise, there is a non-code change to `preserve_flags` expectations that floating point and vector status and sticky bits are preserved. The reference manual update has more details. > * Generally review that the exposed register classes make sense. The followings can be used as input/output: * reg (`r0`, `r[3-12]`, `r[14-r28]`): Any usable general-purpose register * reg_nonzero (`r[3-12]`, `r[14-r28]`): General-purpose registers, but excludes `r0`. This is needed for instructions which define `r0` to be the value 0, such as register + immediate memory operations. * reg/reg_nonzero `r29` on PowerPC64 targets. * freg (`f[0-31]`): 64 bit floating pointer registers The following are clobber-only: * `ctr`, `lr`, `xer`: commonly clobbered special-purpose registers used in inline asm * `cr` (`cr[0-7]`, `cr`): the condition register fields, or the entire condition register. * `vreg` (`v[0-31]`): altivec/vmx register * `vsreg` (`vs[0-63]`): vector-scalar register * `spe_acc`: SPE accumulator, only available for PowerPC SPE targets. The vreg and vsreg registers technically accept `#[repr(simd)]` types, but require the experimental `altivec` or `vsx` target features to be enabled. That work seems to be tracked here, rust-lang#42743. The following cannot be used as operands for inline asm: * `r2`: the TOC pointer, required for most PIC code. * `r13`: the TLS pointer * `r[29]`: Reserved for internal usage by LLVM on PowerPC * `r[30]`: Reserved for internal usage by LLVM on PowerPC and PowerPC64 * `r31`: the frame pointer * `vrsave`: this is effectively an unused special-purpose register. The `preserves_flags` behavior is updated with the following behavior (Note, this is not enforceable today due to LLVM restrictions): * All status and sticky bits of `fpscr`, `spefscr`, and `vscr` are preserved. The following registers are unavailable: * `mma[0-7]`: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. If needed, users can mark such clobbers as vsN*4, vsN*4+1,...,vsN*4+3. * `ap`: This is actually a pseudo-register in gcc/llvm. * `mq`: This register is only available on Power1 and Power2, and is not supported by llvm. --- cc @taiki-e r? @Amanieu @rustbot label +A-inline-assembly
Do not mention `-Zmacro-backtrace` for std macros that are a wrapper around a compiler intrinsic
…-binary-files, r=jdonszelmann checksum-freshness: Fix invalid checksum calculation for binary files Admittedly this is not the cleanest way to achieve this, but SourceMap is quite intertwined with source files being represented as Strings. Tracking issue: rust-lang/cargo#14136 Closes: rust-lang#151090
Update backtrace and windows-bindgen Supersedes the backtrace bump in rust-lang#151659 This is mostly just renaming `windows_targets` to `windows_link` but it needs to be done in tandem with the backtrace submodule update. The reason for doing this is that backtrace is both copy/pasted into std (via being a submodule) and published as an independent crate.
…r=wesleywiser
Adds two new Tier 3 targets - `aarch64v8r-unknown-none{,-softfloat}`
## New Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`
This PR adds two new Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test `aarch64-unknown-none` to a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
## Tier 3 Policy Notes
To cover off the Tier 3 requirements:
> A tier 3 target must have a designated developer or developers
Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.
> Targets must use naming consistent with any existing targets
We prefix this target with `aarch64` because it generates A64 machine code (like `arm*` generates A32 and `thumb*` generates T32). In an ideal world I'd get to rename the existing target `aarch64v8a-unknown-none` but that's basically impossible at this point. You can assume `v6` for any `arm*` target where unspecified, and you can assume `v8a` for any `aarch64*` target where not specified.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
It works just like the existing AArch64 bare-metal target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate.
It's a bare-metal target, offering libcore and liballoc.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Done
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
It's AArch64 and so works with LLVM.
…akai410
Don't expose redundant information in `rustc_public`'s `LayoutShape`
Enum variant layouts don't need to store a full `LayoutShape`; just storing the fields offsets is enough and all other information can be inferred from the parent layout:
- size, align and ABI don't make much sense for individual variants and should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and `variant: VariantShape::Single { .. }`.
In principle, the same refactor could be done on `rustc_abi::Layout` (see [this comment](rust-lang#113988 (comment))) but I prefer starting with this smaller change first.
…=scottmcm remove `#[deprecated]` from unstable & internal `SipHasher13` and `24` types These types are unstable and `doc(hidden)` (under the internal feature `hashmap_internals`). Deprecating them only adds noise (`#[allow(deprecated)]`) to all places where they are used, so this PR removes the deprecation attributes from them. It also includes a few other small cleanups in separate commits, including one I overlooked in rust-lang#151228.
lint: Use rustc_apfloat for `overflowing_literals`, add f16 and f128 Switch to parsing float literals for overflow checks using `rustc_apfloat` rather than host floats. This avoids small variations in platform support and makes it possible to start checking `f16` and `f128` as well. Using APFloat matches what we try to do elsewhere to avoid platform inconsistencies.
…ts, r=scottmcm
rename uN::{gather,scatter}_bits to uN::{extract,deposit}_bits
Feature gate: `#![feature(uint_gather_scatter_bits)]`
Tracking issue: rust-lang#149069
Rename the methods as requested in rust-lang#149069 (comment)
- `gather_bits` -> `extract_bits`
- `scatter_bits` -> `deposit_bits`
…eyouxu Fix broken Xtensa installation link ### Location (URL) https://doc.rust-lang.org/rustc/platform-support/xtensa.html <img width="800" alt="image" src="https://github.com/user-attachments/assets/dbf1fea5-e65f-4bb2-beea-bf3267b12aff" /> ### Summary The Xtensa platform documentation currently links to an outdated Rust on ESP Book installation page that no longer exists. The Rust on ESP Book has been reorganized, and the installation instructions previously referenced under `/book/installation/` are now located under the Getting Started section. The link is updated to reference the current Toolchain Installation page, which contains the up-to-date instructions for building Xtensa targets.
Update books ## rust-lang/reference 5 commits in 28b5a54419985f03db5294de5eede71b6665b594..990819b86c22bbf538c0526f0287670f3dc1a67a 2026-01-20 20:46:59 UTC to 2026-01-14 01:48:22 UTC - Rename the ".general" rules (rust-lang/reference#2133) - Unwrap more chapters (rust-lang/reference#2134) - Add missing semicolon to ambiguity.glob-vs-glob (rust-lang/reference#2132) - Fix spacing with ordered lists (rust-lang/reference#2131) - Reflect explicit macro import in reference (rust-lang/reference#2077) ## rust-lang/rust-by-example 6 commits in 8de6ff811315ac3a96ebe01d74057382e42ffdee..bac931ef1673af63fb60c3d691633034713cca20 2026-01-25 21:02:15 UTC to 2026-01-14 19:45:27 UTC - Update supertraits.md (rust-lang/rust-by-example#1988) - Update question_mark.md (rust-lang/rust-by-example#1990) - Update deprecated functions in `Box::leak` example (rust-lang/rust-by-example#1992) - Improve Clone and Copy traits documentation (rust-lang/rust-by-example#1993) - Fix typo (rust-lang/rust-by-example#1986) - Korean translation! (rust-lang/rust-by-example#1985)
…ross35 os allow missing_docs Resolves rustc build faliure. Discovered in NixOS/nixpkgs#470993 ``` rustc> Documenting core v0.0.0 (/nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src/library/core) rustc> error: missing documentation for a module rustc> --> library/core/src/os/mod.rs:13:1 rustc> | rustc> 13 | pub mod darwin {} rustc> | ^^^^^^^^^^^^^^ rustc> | rustc> = note: `-D missing-docs` implied by `-D warnings` rustc> = help: to override `-D warnings` add `#[allow(missing_docs)]` rustc> rustc> Checking compiler_builtins v0.1.160 (/nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src/library/compiler-builtins/compiler-builtins) rustc> error: could not document `core` rustc> warning: build failed, waiting for other jobs to finish... rustc> Command `/nix/store/h499wcc6pl9whxa2kznjm76wy4f3lcm0-cargo-bootstrap-1.92.0/bin/cargo doc --target wasm32-unknown-unknown -Zbinary-dep-depinfo -j 10 -Zroot-dir=/nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src --frozen --release -p alloc -p compiler_builtins -p core -p panic_abort -p panic_unwind -p proc_macro -p rustc-std-workspace-core -p std -p std_detect -p sysroot -p test -p unwind --features 'backtrace panic-unwind' --manifest-path /nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src/library/sysroot/Cargo.toml --no-deps --target-dir /nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src/build/aarch64-apple-darwin/stage1-std/wasm32-unknown-unknown/doc -Zskip-rustdoc-fingerprint -Zrustdoc-map [workdir=/nix/var/nix/builds/nix-78118-1377149852/rustc-1.92.0-src]` failed with exit code 101 rustc> Created at: src/bootstrap/src/core/build_steps/doc.rs:781:21 rustc> Executed at: src/bootstrap/src/core/build_steps/doc.rs:814:22 rustc> rustc> Command has failed. Rerun with -v to see more details. ```
rustbot
added
T-libs
Member
Author
|
Rollup of everything. @bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
This was referenced Jan 27, 2026
rust-bors
bot
added
merged-by-bors
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 b3cda16 (parent) -> ebf13cc (this PR) Test differencesShow 346 test diffsStage 1
Stage 2
(and 124 additional test diffs) Additionally, 122 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 ebf13cca58b551b83133d4895e123f7d1e795111 --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: b3cda168c8 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 27, 2026
Collaborator
|
Finished benchmarking commit (ebf13cc): 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 0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 4.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.4%, secondary -0.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 472.506s -> 472.178s (-0.07%) |
Member
Author
This comment has been minimized.
This comment has been minimized.
Collaborator
|
Finished benchmarking commit (a3fd550): comparison URL. Overall result: ❌ regressions - please read the text belowInstruction 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.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -2.3%)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: 472.506s -> 473.424s (0.19%) |
Member
rustbot
added
the
perf-regression-triaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 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:
-Zmacro-backtracefor std macros that are a wrapper around a compiler intrinsic #148718 (Do not mention-Zmacro-backtracefor std macros that are a wrapper around a compiler intrinsic)aarch64v8r-unknown-none{,-softfloat}#150863 (Adds two new Tier 3 targets -aarch64v8r-unknown-none{,-softfloat})rustc_public'sLayoutShape#151040 (Don't expose redundant information inrustc_public'sLayoutShape)#[deprecated]from unstable & internalSipHasher13and24types #151383 (remove#[deprecated]from unstable & internalSipHasher13and24types)overflowing_literals, add f16 and f128 #151529 (lint: Use rustc_apfloat foroverflowing_literals, add f16 and f128)r? @ghost
Create a similar rollup