Rollup of 7 pull requests #151710
Closed
Rollup of 7 pull requests #151710
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
Do not mention `-Zmacro-backtrace` for std macros that are a wrapper around a compiler intrinsic
resolve: Mark items under exported ambiguous imports as exported After rust-lang#147984 one of the imports in an ambiguous import set becomes accessible under a deny-by-default deprecation lint. So if it points to something, that something needs to be marked as exported, so its MIR is encoded into metadata, its symbol is not lost from object files, etc. The added test shows an example. This fixes around 10-20 crater regressions found in rust-lang#149195 (comment). Unblocks rust-lang#149195.
…-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
…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.
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. ```
Contributor
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
bot
added
the
S-waiting-on-bors
rustbot
added
A-run-make
rustbot
added
T-rustdoc
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 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)r? @ghost
Create a similar rollup