Rollup of 9 pull requests#155960
Open
jhpratt wants to merge 25 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>
For now, this is a 1-to-1 copy of `LayoutData`, but this will change.
It was always set to `Variants::Single`.
Enum variants always have `Arbitrary` layout, so the enum isn't needed.
This field is only used during layout calculations, so re-synthetized `LayoutData`s for enum variants can use a dummy value instead.
Reusing the alignment of the enclosing enum in `LayoutData::for_variant` doesn't appear to cause any issues.
…ts, allowing to use `FnOnce` instead of `Fn`
Because the memory safety of `FlatMapInPlace::flat_map_in_place` depends on `FlatMapInPlaceVec` impls behaving correctly.
Remove redundant information in `rustc_abi::Variants` Follow-up to rust-lang#151040; partially addresses rust-lang#113988. Replaces the nested `LayoutData` in `Variants::Multiple` by a new, smaller `VariantLayout` struct, and adjust `LayoutData::for_variant`and the layout algorithm in consequence. This PR is best reviewed commit-by-commit.
…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.
…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-run-make
rustbot
added
T-libs
Member
Author
|
@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.
rust-bors Bot
pushed a commit
that referenced
this pull request
Apr 29, 2026
Rollup of 9 pull requests Successful merges: - #151742 (Remove redundant information in `rustc_abi::Variants`) - #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) - #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.)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for a3933d9 failed: CI. Failed job:
|
Contributor
|
Is that spurious? |
Contributor
|
⌛ Trying commit 143227f with merge f61ee4b… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/25108999157 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Apr 29, 2026
Rollup of 9 pull requests try-job: x86_64-gnu-llvm-21-1
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
13 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:
rustc_abi::Variants#151742 (Remove redundant information inrustc_abi::Variants)[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