-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 5 pull requests #140083
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #140083
Conversation
It was only temporarily used by pin!(), which no longer needs it.
Put them all on the same line with just their GitHub handles to make it very easy to copy and paste (with ctrl-shift-v!!!) the names. We have no use for email, so I removed all the emails, we don't care about people's full names either. Co-authored-by: Thalia Archibald <thalia@archibald.dev>
Add target-specific NaN payloads for the missing tier 2 targets This PR adds target-specific NaN payloads for the remaining tier 2 targets: - `arm64ec`: This target is a mix of `x86_64` and `aarch64`, meaning as they both have no extra payloads `arm64ec` also has no extra payloads. - `loongarch64`: Per [LoongArch Reference Manual - Volume 1: Basic Architecture](https://github.com/loongson/LoongArch-Documentation/releases/download/2023.04.20/LoongArch-Vol1-v1.10-EN.pdf) section 3.1.1.3, LoongArch does quieting NaN propagation with the Rust preferred NaN as its default NaN, meaning it has no extra payloads. - `nvptx64`: Per [PTX ISA documentation](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions) section 9.7.3 (and section 9.7.4 for `f16`), all payloads are possible. The documentation explicitly states that `f16` and `f32` operations result in an unspecified NaN payload, while for `f64` it states "NaN payloads are supported" without specifying how or what payload will be generated if there are no input NaNs. - `powerpc` and `powerpc64`: Per [Power Instruction Set Architecture](https://files.openpower.foundation/s/9izgC5Rogi5Ywmm/download/OPF_PowerISA_v3.1C.pdf) Book I section 4.3.2, PowerPC does quieting NaN propagation with the Rust preferred NaN being generated if no there are no input NaNs, meaning it has no extra payloads. - `s390x`: Per [IBM z/Architecture Principles of Operation](https://www.vm.ibm.com/library/other/22783213.pdf#page=965) page 9-3, s390x does quieting NaN propagation with the Rust's preferred NaN as its default NaN, meaning it has no extra payloads. Tracking issue: rust-lang#128288 cc ``@RalfJung`` ``@rustbot`` label +T-lang Also cc relevant target maintainers of tier 2 targets: - `arm64ec`: ``@dpaoliello`` - `loongarch64`: ``@heiher`` ``@xiangzhai`` ``@zhaixiaojuan`` ``@xen0n`` - `nvptx64`: ``@RDambrosio016`` ``@kjetilkjeka`` - `powerpc`: the only documented maintainer is ``@BKPepe`` for the tier 3 `powerpc-unknown-linux-muslspe`. - `powerpc64`: ``@daltenty`` ``@gilamn5tr`` ``@Gelbpunkt`` ``@famfo`` ``@neuschaefer`` - `s390x`: ``@uweigand`` ``@cuviper``
Make target maintainers more easily pingable Put them all on the same line with just their GitHub handles to make it very easy to copy and paste (with ctrl-shift-v!!!) the names. We have no use for email, so I removed all the emails, we don't care about people's full names either. This is a pretty big PR with lots of changes. I may have gotten one or two wrong, who knows. I went over it fairly aggressively, removing all information I deemed unnecessary. > [!Caution] > When copying these usernames, use **ctrl-shift-v** to avoid pasting them as links r? RalfJung you indirectly asked for this :) (anyone is welcome to review)
…eyouxu Remove stray newline from post-merge report [Oops](rust-lang#140043 (comment)) :) r? jieyouxu
…Urgau Remove (now unused) #[rustc_macro_edition_2021] attribute Now that rust-lang#139114 has been merged, we no longer need the temporary hack (`#[rustc_macro_edition_2021]`) that we introduced in rust-lang#138717. Time to remove it.
replace broken links armv7-rtems-eabihf.md Hi team , i found broken link in `src/doc/rustc/src/platform-support/armv7-rtems-eabihf.md` and replace thanks
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 49e5e4e3a5 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 49e5e4e (parent) -> b8c54d6 (this PR) Test differencesShow 64 test diffs64 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b8c54d6358926028ac2fab1ec2b8665c70edb1c0 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (b8c54d6): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.4%, secondary -3.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.4%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 773.64s -> 775.102s (0.19%) |
Successful merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup