Rollup of 12 pull requests#155964
Open
JonathanBrouwer wants to merge 27 commits intorust-lang:mainfrom
Open
Conversation
Wire IsProcessorFeaturePresent for the PF_ARM_* constants exposed in Windows SDK 26100 (Win11 24H2): fp16 PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE (67) i8mm PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE (66) bf16 PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE (68) sha3 PF_ARM_SHA3 (64) AND PF_ARM_SHA512 (65) lse2 PF_ARM_LSE2_AVAILABLE (62) f32mm PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE (58) f64mm PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE (59) Also derive `rdm` from FEAT_DotProd. There is no PF_ARM_RDM_* constant; FEAT_DotProd is an optional v8.2-A feature only present on cores that implement at least v8.1-A, and v8.1-A with AdvSIMD mandates FEAT_RDM (Arm ARM K.a §D17.2.91). AdvSIMD is universal on Windows-on-ARM. See PR description for full rationale and .NET 10 precedent. All eight feature names have been stable in `is_aarch64_feature_detected!` on Linux/Darwin/BSD since Rust 1.60.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
…ts, allowing to use `FnOnce` instead of `Fn`
Because the memory safety of `FlatMapInPlace::flat_map_in_place` depends on `FlatMapInPlaceVec` impls behaving correctly.
…trochenkov simd_reduce_min/max: remove float support LLVM currently doesn't have an intrinsic with the right semantics here (see llvm/llvm-project#185827). The only remaining user of this intrinsic with float types is portable-simd and it's easier to implement a fallback there than here, so I opted for making the intrinsic int-only. I kept around the float support in cranelift and Miri because there it already has the desired semantics (matching scalar min/max). Fixes rust-lang#153395 ~~Blocked on rust-lang/portable-simd#515
…=bjorn3 When archive format is wrong produce an error instead of ICE Fix rust-lang#145624. Fix rust-lang#147094. Fix rust-lang#148217. There are now two-step solutions to replace the original ICE： Step 1: BSD format archive on a GNU/Linux target should emit a format mismatch warning. Step 2: Corrupt archive with member offset exceeding file boundary should produce an error, not an ICE. r? @bjorn3
…ate-init, r=petrochenkov privacy: share effective visibility initialization Address one `FIXME` in `EffectiveVisibilities` by sharing the private effective visibility initialization path between `effective_vis_or_private` and `update`. `update` now mutates the map entry in place instead of copying the effective visibility out and inserting it back at the end. The inserted default value and update logic are unchanged. Validation: - `git diff --check` - `python x.py check compiler/rustc_middle`
…manieu std_detect: support detecting more features on aarch64 Windows Wires `IsProcessorFeaturePresent` calls for the `PF_ARM_*` constants exposed in Windows SDK 26100 (Windows 11 24H2), plus an architectural derivation for `rdm`. All eight feature names have been stable in `is_aarch64_feature_detected!` on Linux/Darwin/BSD since Rust 1.60 — this brings the Windows backend to parity. | Feature | Source on Windows | |---|---| | `fp16` | `PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE` (value 67) | | `i8mm` | `PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE` (value 66) | | `bf16` | `PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE` (value 68) | | `sha3` | `PF_ARM_SHA3` (value 64) **AND** `PF_ARM_SHA512` (value 65) | | `lse2` | `PF_ARM_LSE2_AVAILABLE` (value 62) | | `f32mm` | `PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE` (value 58) | | `f64mm` | `PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE` (value 59) | | `rdm` | derived from `PF_ARM_V82_DP` (see below) | `PF_ARM_SVE_F32MM` / `PF_ARM_SVE_F64MM` (values 58 / 59) were already added as commented-out placeholders in rust-lang/stdarch#1749 — they have direct stable Feature mappings (`f32mm`, `f64mm`), unlike their sibling values 52 / 53 / 57 (`SVE_BF16`, `SVE_EBF16`, `SVE_I8MM`) which have no SVE-specific stdarch Feature name and remain commented for that reason. `sha3` requires both `PF_ARM_SHA3` (FEAT_SHA3) and `PF_ARM_SHA512` (FEAT_SHA512), matching the existing convention from rust-lang/stdarch#1749 where `sve2-aes` is set only when both `PF_ARM_SVE_AES` and `PF_ARM_SVE_PMULL128` are present. ### `rdm` derivation There is no `PF_ARM_RDM_*` constant; Microsoft has never defined one. We derive it from `PF_ARM_V82_DP_INSTRUCTIONS_AVAILABLE` (FEAT_DotProd) via the following architectural chain: 1. FEAT_DotProd is an optional v8.2-A feature, so its presence implies the core implements at least v8.1-A. 2. Per Arm ARM K.a §D17.2.91: *"In an ARMv8.1 implementation, if FEAT_AdvSIMD is implemented, FEAT_RDM is implemented."* 3. AdvSIMD is universally implemented on every Windows-on-ARM SKU. 4. Therefore: DotProd ⇒ v8.1-A baseline + AdvSIMD ⇒ FEAT_RDM. This is the same derivation .NET 10 uses, with comment cited verbatim ([dotnet/runtime PR 109493](dotnet/runtime#109493), shipped in v10.0.0 at [`src/native/minipal/cpufeatures.c`](https://github.com/dotnet/runtime/blob/v10.0.0/src/native/minipal/cpufeatures.c)): > *"IsProcessorFeaturePresent does not have a dedicated flag for RDM, so we enable it by implication. > 1) DP is an optional instruction set for Armv8.2, which may be included only in processors implementing at least Armv8.1. > 2) Armv8.1 requires RDM when AdvSIMD is implemented, and AdvSIMD is a baseline requirement of .NET. > Therefore, by documented standard, DP cannot exist here without RDM. In practice, there is only one CPU supported by Windows that includes RDM without DP, so this implication also has little practical chance of a false negative."* The "one CPU with RDM without DP" trade-off applies equally to us: we accept a possible false negative on that single SKU rather than introducing a more aggressive heuristic. ### Tests Adds `println!` lines to the existing `aarch64_windows()` test in `library/std_detect/tests/cpu-detection.rs` for each newly-detected feature, mirroring the existing single-line pattern. No structural assertions added. ### Scope Stable feature names only. The unstable SME family (`sme`, `sme2`, `sme2p1`, `sme_*`, `ssve_fp8*`) and other unstable additions tracked under rust-lang#127764 are intentionally out of scope here to keep this PR minimal — happy to do a follow-up. ### References - Tracking issue: rust-lang#127764 (`stdarch_aarch64_feature_detection`) - Precedent: rust-lang/stdarch#1749 (taiki-e, merged 2025-03-24) — added the SVE constants this builds on - MS docs: [`IsProcessorFeaturePresent`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent) — full PF_ARM_* table r? @Amanieu cc @taiki-e (author of rust-lang/stdarch#1749, would appreciate your eyes on the `rdm` inference) @rustbot label +T-libs +O-windows +O-ARM
…r=jdonszelmann Suggest `[const] Trait` bounds in more places Right now we have some special logic in the const checker for emitting `[const] Trait` suggestions, but I'm trying to handle that similarly to how it is handled for normal `Trait` clauses. This is just a small step in how it will look on the UX side, which should make my follow-up PRs affect tests less and just be a refactoring
`dlltool`: Set the working directory to workaround `--temp-prefix` bug dlltool's `--temp-prefix` argument incorrectly splits paths that contain spaces. To workaround this, we pass a relative path to `--temp-prefix` and set the working directory. fixes rust-lang#155591
Update with new LLVM 22 target for `wasm32-wali-linux-musl` target This is a reopening of rust-lang#155654, which was closed abruptly due to changed commit SHAs on my end during merge.
…r=Urgau, remap OUT_DIR paths to fix build script path leakage in crate metadata. ### problem: - build script outputs (`OUT_DIR`) leak absolute paths into crate metadata causing non-determinism across identical builds. - bootstrap remaps source paths (`self.build.src`) and registry sources but doesn't not remap `self.build.out` used by `OUT_DIR` ### fix: - adding `--remap-path-prefix` for `self.build.out` , mapping it to a stable virtual prefix, consistent with existing remappings ### result: - removes path-based non-determinism from build script outputs - verified via stage 2 reproducibility testing. r? @Urgau
…henyukang use the new `//@ needs-asm-mnemonic: ret` more Since rust-lang#155692 we have this neat new rule, and a couple of tests should be able to use them.
…d-more, r=Mark-Simulacrum ci(free-disk-space): remove more tools and fix warnings With this PR I remove more space and improve the free-disk-space-linux script. If you prefer me to split this PR into multiple ones, let me know. Discussed in [#t-infra > some jobs running out of disk space](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/some.20jobs.20running.20out.20of.20disk.20space/with/591666099) ## Test I tested this change in marcoieni/actions-test@196ce70. As you can see the workflows run without warnings, which ensures that we can remove all the space possible from the arm runners. I also tested this change in this repository, by commenting out the mechanism to skip disk cleanup in case there is sufficient available disk space. ( see rust-lang@86529fb ) If I don't comment out the code, it can happen that the CI skips the code I edited because there's enough disk space in the runners that this CI is running. Here's the change of that commit: ``` # sufficientSpaceEarlyExit # checkAlternative ``` ## Storage saved In that temporary commit, I measured how much we are saving. It looks like this PR saves ~2GB: * Before this PR, from https://github.com/rust-lang/rust/actions/runs/25082499114/job/73490814240: `Total saved: Saved 35GiB` * In this PR, from https://github.com/rust-lang/rust/actions/runs/25099446145/job/73544774148: `Total saved: Saved 37GiB`
…thanBrouwer,kivooeo Update `opt_ast_lowering_delayed_lints` query to allow "stealing" lints, allowing to use `FnOnce` instead of `Fn` Part of rust-lang#153099. This is needed for https://github.com/rust-lang/rust/compare/main...GuillaumeGomez:rust:diagnostic-instead-of-closure?expand=1 which will allow to pass `Diagnostic` instead of a closure. As asked by @JonathanBrouwer, I make this as a stand-alone PR. :) r? @JonathanBrouwer
…ec, r=kivooeo Make `FlatMapInPlaceVec` an unsafe trait. Because the memory safety of `FlatMapInPlace::flat_map_in_place` depends on `FlatMapInPlaceVec` impls behaving correctly. r? @chenyukang
rustbot
added
A-CI
rustbot
added
A-run-make
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Apr 29, 2026
Rollup of 12 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-2
Contributor
|
⌛ Testing commit 212ddcd with merge fdaba23... Workflow: https://github.com/rust-lang/rust/actions/runs/25122455453 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Apr 29, 2026
…uwer Rollup of 12 pull requests Successful merges: - #155189 (simd_reduce_min/max: remove float support) - #155721 (When archive format is wrong produce an error instead of ICE) - #155794 (privacy: share effective visibility initialization) - #155856 (std_detect: support detecting more features on aarch64 Windows) - #155861 (Suggest `[const] Trait` bounds in more places) - #155899 (`dlltool`: Set the working directory to workaround `--temp-prefix` bug) - #155916 (Update with new LLVM 22 target for `wasm32-wali-linux-musl` target) - #155935 (remap OUT_DIR paths to fix build script path leakage in crate metadata. ) - #155950 (use the new `//@ needs-asm-mnemonic: ret` more) - #155958 (ci(free-disk-space): remove more tools and fix warnings) - #155949 (Update `opt_ast_lowering_delayed_lints` query to allow "stealing" lints, allowing to use `FnOnce` instead of `Fn`) - #155951 (Make `FlatMapInPlaceVec` an unsafe trait.)
Contributor
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 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:
[const] Traitbounds in more places #155861 (Suggest[const] Traitbounds in more places)dlltool: Set the working directory to workaround--temp-prefixbug #155899 (dlltool: Set the working directory to workaround--temp-prefixbug)wasm32-wali-linux-musltarget #155916 (Update with new LLVM 22 target forwasm32-wali-linux-musltarget)//@ needs-asm-mnemonic: retmore #155950 (use the new//@ needs-asm-mnemonic: retmore)opt_ast_lowering_delayed_lintsquery to allow "stealing" lints, allowing to useFnOnceinstead ofFn#155949 (Updateopt_ast_lowering_delayed_lintsquery to allow "stealing" lints, allowing to useFnOnceinstead ofFn)FlatMapInPlaceVecan unsafe trait. #155951 (MakeFlatMapInPlaceVecan unsafe trait.)r? @ghost
Create a similar rollup