Rollup of 6 pull requests#159536
Conversation
The `is::`, `cs::`, and `ls::` prefixes were originally used to clearly
distinguish helper intrinsics from different namespaces at call sites.
However, due to limitations in Rust macro expansion, `prefix::simd_xxx`
cannot always be used. Some macro expansions only accept an identifier,
causing errors such as:
```
($ft:literal, $name:ident, $op:path, $oty:ty, $ity:ident) => {
let r: $ity = $op::<IMM, _>(a);
^^ expected one of `.`, `;`, `?`, `else`, or an operator
```
Instead of relying on namespace prefixes, rename the LoongArch-specific
`simd_xxx` helpers to `simd_ext_xxx` and remove the `is::`, `cs::`, and
`ls::` prefixes from macro invocations. This preserves the distinction
between helper intrinsics while avoiding the macro expansion limitation.
Update itertools to 0.15
loongarch: Rename SIMD helper intrinsics to avoid macro path issues
Port stdarch-gen-loongarch to stdarch-gen-common harness
add better test for `permutexvar`
document differences from pure hardware behavior
loongarch: Use `intrinsics::simd` for vldi
Re-enable ICX run
This function hints at an early commitment to coroutine memory layout. We should not give promises on how upvars are allocated. Signed-off-by: Xiangfei Ding <dingxiangfei2009@protonmail.ch>
This updates the rust-version file to fcbe791.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@fcbe791 Filtered ref: rust-lang/stdarch@4742894 Upstream diff: rust-lang/rust@8e15021...fcbe791 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
loongarch: Use `intrinsics::simd` for vbs{l,r}l
…, r=folkertdev stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@50afa9f. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…ulacrum Simplify the unwind crate Use cfg_select! and unify type definitions.
…s, r=cjgillot Stop using prefix_tys *This is a member of a patch series to replace rust-lang#135527.* This function hints at an early commitment to coroutine memory layout. We should not give promises on how upvars are allocated.
…y, r=Mark-Simulacrum triagebot: cc miri on any special-casing of miri in the standard library --- Blocked until rust-lang/triagebot#2462 is merged and deployed.
…ros, r=mejrs Apply `#[diagnostic::opaque]` to macros expanding to built-in syntax For context, thin wrapper macros expanding to built-in syntax `builtin # SYNTAX(…)` (internal feature `builtin_syntax`) is an alternative to built-in macros (`#[rustc_builtin_macro]`) for introducing new syntax constructs that takes slightly less code to implement in the compiler (since one doesn't need to write boiler-plate expanders, see RUST-122806 for example). However, one disadvantage of that approach is the fact that the thin wrapper macro is a normal macro and is thus considered "interesting" wrt. macro backtraces. The fact that it expands to `builtin # SYNTAX(…)` should be considered an implementation detail and thus these macros should be considered opaque. I've applied `#[diagnostic::opaque]` (rust-lang#158608) to all of these macros which successfully suppresses diagnostic notes of the form `` this error originates in the macro `SYNTAX` (…) ``. Well, it doesn't actually omit the expansion from the macro backtrace when `-Zmacro-backtrace` is passed which was surprising but seems intentional looking at the linked PR. Still, this is better than nothing. r? @mejrs
… r=clarfonthey implement `const_binary_search` tracking issue: rust-lang#159532 This makes unstably `const` the following public api: `core::slice::binary_search` `core::slice::binary_search_by` `core::slice::binary_search_by_key` `core::slice::partition_point` Happy to make a tracking issue if these are acceptable.
This comment has been minimized.
This comment has been minimized.
Rollup of 6 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-*
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: eff8269f79 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 eff8269 (parent) -> c904ba3 (this PR) Test differencesShow 311 test diffs311 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard c904ba32e22c9d6fd31140b4283c5cc6c6b2fb5c --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 |
|
Finished benchmarking commit (c904ba3): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (primary 2.3%, secondary 2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 489.126s -> 486.808s (-0.47%) |
Successful merges:
#[diagnostic::opaque]to macros expanding to built-in syntax #159522 (Apply#[diagnostic::opaque]to macros expanding to built-in syntax)const_binary_search#159528 (implementconst_binary_search)r? @ghost
Create a similar rollup