Rollup of 12 pull requests #140581
Merged
Rollup of 12 pull requests #140581
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
…_exit` Getting the address of `errno` should be just as cheap as `pthread_self()` and avoids having to use the expensive `Mutex` logic because it always results in a pointer.
The Za64rs extension (reservation set -- a primitive memory unit of LR/SC atomic operations -- is naturally aligned and *at most* 64 bytes) is a superset of the Za128rs extension (*at most* 128 bytes; note that smaller the reservation set is, more fine grained control over atomics). This commit handles this as a feature implication.
This commit adds a part of RISC-V extensions that are mandatory part of the RVA23U64 profile (application-class processor profile) and related to memory/atomic constraints. The Zic64b extension constrains the cache line to naturally-aligned 64 bytes that would make certain memory operations (like zeroing the memory using the Zicboz extension) easier. The Zicbom and Zicbop extensions enable managing cache block-based operations (the Zicbop contains hints that will work as a NOP when this extension is absent and the Zicbom contains control instructions). Of which, the Zicbom extension is going to be discoverable from the Linux kernel (as of the version 6.15-rc4) and this commit prepares for corresponding stdarch changes. The Zicc* extensions add certain constraints to "the main memory" (usually true on the user mode application on the application-class processor but those extensions make sure such constraints exist).
This commit adds three ratified unprivileged RISC-V extensions related to BFloat16 (BF16) handling. Although that they are far from stabilization due to ABI issues, they are optional extensions of the RVA23U64 profile (application-class processor profile) and going to be discoverable from the Linux kernel (as of version 6.15-rc4). This commit mainly prepares runtime detection of those extensions.
Because RISC-V Calling Conventions note that:
> This means code targeting the Zfinx extension always uses the ILP32,
> ILP32E or LP64 integer calling-convention only ABIs as there is no
> dedicated hardware floating-point register file.
{ILP32,LP64}[FD] ABIs with hardware floating-point calling conventions
are incompatible with the "Zfinx" extension.
This commit adds "zfinx" to the incompatible feature list to those ABIs
and tests whether trying to add "zdinx" (that is analogous to "zfinx" but
in double-precision) on a LP64D ABI configuration results in an error
(it also tests extension implication; "Zdinx" requires "Zfinx" extension).
Link: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
Communicate the safety invariants of these methods with `unsafe fn` rather than privacy.
Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and `add_extension`, where joining WTF-8 surrogate halves is impossible. Don't convert the `str` to `OsStr`, because `OsString::push` specializes to skip the joining when given strings.
We have coverage for `Foo` and `Foo<T>` but not for `Foo<>`. This commit adds it. Note that the output has bogus syntax: `impl Foo'a, >`
Delegate from `std::env::ArgsOs` to the methods of the inner platform-specific iterators, when it would be more efficient than just using the default methods of its own impl. Most platforms use `vec::IntoIter` as the inner type, so prioritize delegating to the methods it provides. `std::env::Args` is implemented atop `std::env::ArgsOs` and performs UTF-8 validation with a panic for invalid data. This is a visible effect which users certainly rely on, so we can't skip any arguments. Any further iterator methods would skip some elements, so no change is needed for that type. Add `#[inline]` for any methods which simply wrap the inner iterator.
`Path<>` needs to be distinguished from `Path<T>`. This commit does that, improving some error messages.
By taking the existing `expanded-exhaustive.rs` test and running it with both `Zunpretty=expanded` *and* `Zunpretty=hir`. Also rename some files, and split the asm parts out so they only run on x86-64.
handle paren in macro expand for let-init-else expr Fixes rust-lang#131655 This PR modifies the codegen logic of the macro expansion within `let-init-else` expression: - Before: The expression `let xxx = (mac! {}) else {}` expands to `let xxx = (expanded_ast) else {}`. - After: The same expression expands to `let xxx = expanded_ast else {}`. An alternative solution to this issue could involve handling the source code directly when encountering unused parentheses in `let-init-else` expressions. However, this approach might be more cumbersome due to the absence of the necessary data structure. r? `@petrochenkov`
…ywiser pretty-print: Print shebang at the top of the output Shebang should stay at the top of the file, even after pretty-printing. Closes rust-lang#134643
…inx, r=workingjubilee
rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs
Because RISC-V Calling Conventions note that:
> This means code targeting the `Zfinx` extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.
`{ILP32,LP64}[FD]` ABIs with hardware floating-point calling conventions are incompatible with the `Zfinx` extension.
This commit adds `"zfinx"` to the incompatible feature list to those ABIs and tests whether trying to add `"zdinx"` (that is analogous to `"zfinx"` but in double-precision) on a LP64D ABI configuration results in an error (it also tests extension implication; `Zdinx` requires `Zfinx` extension).
Links: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/v1.0/riscv-cc.adoc#named-abis>
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
…=lcnr Improve `Lifetime::suggestion` r? ``@lcnr``
…heemdev std: use the address of `errno` to identify threads in `unique_thread_exit` Getting the address of `errno` should be just as cheap as `pthread_self()` and avoids having to use the expensive `Mutex` logic because it always results in a pointer.
…s, r=ibraheemdev Clarify `async` block behaviour Adds some documentation for control flow behaviour pertaining to `return` and `?` within `async` blocks. Fixes (or at least improves) rust-lang#101444. r? rust-lang/docs
…workingjubilee Delegate to inner `vec::IntoIter` from `env::ArgsOs` Delegate from `std::env::ArgsOs` to the methods of the inner platform-specific iterators, when it would be more efficient than just using the default methods of its own impl. Most platforms use `vec::IntoIter` as the inner type, so prioritize delegating to the methods it provides. `std::env::Args` is implemented atop `std::env::ArgsOs` and performs UTF-8 validation with a panic for invalid data. This is a visible effect which users certainly rely on, so we can't skip any arguments. Any further iterator methods would skip some elements, so no change is needed for that type. Add `#[inline]` for any methods which simply wrap the inner iterator.
…orkingjubilee Avoid redundant WTF-8 checks in `PathBuf` Eliminate checks for WTF-8 boundaries in `PathBuf::set_extension` and `add_extension`, where joining WTF-8 surrogate halves is impossible. Don't convert the `str` to `OsStr`, because `OsString::push` specializes to skip the joining when given strings. To assist in this, mark the internal methods `OsString::truncate` and `extend_from_slice` as `unsafe` to communicate their safety invariants better than with module privacy. Similar to rust-lang#137777. cc `@joboet` `@ChrisDenton`
Document breaking out of a named code block Closes rust-lang#110758.
Remove `avx512dq` and `avx512vl` implication for `avx512fp16` According to Intel, `avx512fp16` requires only `avx512bw`, but LLVM also enables `avx512vl` and `avx512dq` when `avx512fp16` is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512 Related: - llvm/llvm-project#136209 - rust-lang#138940 - rust-lang/stdarch#1781 - rust-lang#111137 ``@rustbot`` label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs r? ``@Amanieu`` **Update: the LLVM fix has been merged** cc ``@rust-lang/wg-llvm`` will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
Improve test coverage of HIR pretty printing. Details in individual commits. r? `@dtolnay` try-job: test-various
…3, r=Amanieu
rustc_target: RISC-V: feature addition batch 3
This is the last batch (3 of 3) for RISC-V feature enhancements intended for the version 1.88 cycle.
The author's primary criteria are:
1. The extension is ratified and unprivileged one.
2. The extension is in the RVA23U64 profile (to be a baseline of the application-class RISC-V software ecosystem in the near future), either mandatory or optional.
3. Either:
1. To be discoverable through a `riscv_hwprobe` system call on (currently unreleased) Linux 6.15 (as of rc4) or
2. Helps memory/atomics-related operations more efficient and/or more robust.
This is based on the specifications:
* [The latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications)
* [RVA23/RVB23 profiles](https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified)
* [RISC-V BF16 extensions](https://github.com/riscv/riscv-bfloat16/releases/tag/v183a3dac863d7c18187a739eb52b0c8f0d16854d)
LLVM Definitions:
* [`Zicbop`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L82-87)
* [`Zicbom`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L75-L80)
* [`Zic64b`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L71-L73)
* [`Ziccamoa`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L97-L99)
* [`Ziccif`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L101-L103)
* [`Zicclsm`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L105-L107)
* [`Ziccrse`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L109-L111)
* [`Zfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L320-L325)
* [`Zvfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L697-L702)
* [`Zvfbfwma`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L704-L710)
The `Zicbop` extension (mandatory in RVA23U64) adds prefetch hints to prepare for subsequent memory operations (will be executed as no-op if the hardware does not support this extension).
The `Zicbom` extension (mandatory in RVA23U64) adds cache block-management instructions. The author did not include this in the batch 2 (because of limited use cases compared to the `Zicboz` extension) but added because it will be discoverable from Linux (as of version 6.15-rc4). Along with `Zicbop`, Rust now supports all CMO extensions.
The `Zic64b` extension (mandatory in RVA23U64) constraints the cache block to be naturally-aligned and exactly 64 bytes. Along with CMO instructions, it can improve efficiency handling with memory (e.g. efficient memory zeroing using `Zicboz` + `Zic64b`).
The `Zicc*` extensions (mandatory in RVA23U64) add constraints to the main memory properties. They are normally satisfied in the application environment with regular OSes but profiles like RVA23U64 ensures such properties are satisfied (through those *constraint* extensions).
The `Zfbf*` and `Zvfbf*` extensions (optional in RVA23U64) add instructions to handle BF16 (BFloat16) data. Although stabilization of FP-related extensions are relatively far due to ABI-related issues, they are included in this batch because they will be discoverable from Linux (as of version 6.15-rc4).
The author also adds the extension implication: `Za64rs` → `Za128rs` (superset) which the author missed to include in rust-lang#140139.
rustbot
added
O-unix
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 19c9b76 with merge 7c96085b64580af5c5f619384f0e3f082138ff13... |
|
☀️ Test successful - checks-actions |
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 f97b3c6 (parent) -> 7c96085 (this PR) Test differencesShow 33647 test diffsStage 1
Stage 2
(and 16470 additional test diffs) Additionally, 17077 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 7c96085b64580af5c5f619384f0e3f082138ff13 --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 |
|
📌 Perf builds for each rolled up PR:
previous master: f97b3c6044 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced May 2, 2025
|
Finished benchmarking commit (7c96085): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@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.7%, secondary 0.7%)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.5%)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 sizeResults (primary 0.0%, secondary -0.1%)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.
Bootstrap: 766.288s -> 769.081s (0.36%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Zfinxis incompatible with{ILP32,LP64}[FD]ABIs #138872 (rustc_target: RISC-VZfinxis incompatible with{ILP32,LP64}[FD]ABIs)Lifetime::suggestion#139046 (ImproveLifetime::suggestion)errnoto identify threads inunique_thread_exit#139206 (std: use the address oferrnoto identify threads inunique_thread_exit)asyncblock behaviour #139608 (Clarifyasyncblock behaviour)vec::IntoIterfromenv::ArgsOs#139847 (Delegate to innervec::IntoIterfromenv::ArgsOs)PathBuf#140159 (Avoid redundant WTF-8 checks inPathBuf)avx512dqandavx512vlimplication foravx512fp16#140389 (Removeavx512dqandavx512vlimplication foravx512fp16)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup