Skip to content

Rollup of 12 pull requests - #157398

Merged
rust-bors[bot] merged 32 commits into
rust-lang:mainfrom
jhpratt:rollup-qXar4uR
Jun 3, 2026
Merged

Rollup of 12 pull requests#157398
rust-bors[bot] merged 32 commits into
rust-lang:mainfrom
jhpratt:rollup-qXar4uR

Conversation

@jhpratt

Copy link
Copy Markdown
Member

Successful merges:

r? @ghost

Create a similar rollup

RalfJungand others added 30 commits April 20, 2026 08:53
The foremost description of this module was:
> Panic support in the standard library.
This commit changes that to:
> Panic support in core.
While working on rust-lang#129249, encountered these cases in the codebase of calling `.into()` unecessarily. Splitting them out so that they can land independently of the lint.
`collect_active_query_jobs` with `CollectActiveJobsKind::PartialAllowed`
is only used to print the query stack when the compiler panics. It
intentionally skips any query state shard whose lock it cannot take
without waiting, since a complete job map is not needed for that.
Under the parallel front-end another thread can still hold a shard lock
while the panic is being reported, so the skip happens nondeterministically
and the `warn!` was printed into the panic output. Because warnings are
shown by default, this leaked a "Failed to collect active jobs" line into
the diagnostics of panicking compilations and made their output unstable.
Lower the message to `debug!` so it stays available with `RUSTC_LOG` but
no longer pollutes the default output.
…nt-end
This test was marked ignore-parallel-frontend because the panic-time query
stack collection could nondeterministically print a "Failed to collect active
jobs" warning. With that warning lowered to debug! the ICE output is stable
across runs, so replace the directive with a blank line rather than deleting
it. The expected stderr is unchanged because the line numbers stay the same.
…etrochenkov
powerpc: warn against incorrect values for ABI-relevant target features
This fills in rust-lang#131799 for PowerPC. Based on [this comment](rust-lang#131799 (comment)) by @beetrees, the relevant target features are "hard-float" and "spe". I confirmed this by looking at the LLVM sources:
```
// Set up the register classes.
addRegisterClass(MVT::i32, &PPC::GPRCRegClass);
if (!useSoftFloat()) {
if (hasSPE()) {
addRegisterClass(MVT::f32, &PPC::GPRCRegClass);
// EFPU2 APU only supports f32
if (!Subtarget.hasEFPU2())
addRegisterClass(MVT::f64, &PPC::SPERCRegClass);
} else {
addRegisterClass(MVT::f32, &PPC::F4RCRegClass);
addRegisterClass(MVT::f64, &PPC::F8RCRegClass);
}
}
```
(this is in `llvm/lib/Target/PowerPC/PPCISelLowering.cpp`)
So, we make rustc emit a warning indicating the ABI compatibility issues if "spe" or hard-float" gets toggled. The plan is to eventually make this a hard error.
I also found this code there, in the handling for "altivec", that look like they are enabling more registers to be used for the ABI, but maybe I am missing a subtle difference in these `addRegisterClass` calls:
```
if (Subtarget.hasP8Vector())
addRegisterClass(MVT::f32, &PPC::VSSRCRegClass);
addRegisterClass(MVT::f64, &PPC::VSFRCRegClass);
addRegisterClass(MVT::v4i32, &PPC::VSRCRegClass);
addRegisterClass(MVT::v4f32, &PPC::VSRCRegClass);
addRegisterClass(MVT::v2f64, &PPC::VSRCRegClass);
```
Cc @nikic for help with interpreting this LLVM code.
Cc @Gelbpunkt@famfo@neuschaefer as maintainers of affected targets
Use `impl` restrictions in `std`, `core`
This should all be quite self-explanatory. I've used the tightest module permitted by current implementation, which is overwhelmingly `self` as I had expected.
r? @Urgau
…ochenkov
[tiny] remove unecessary `.into()` calls
While working on rust-lang#129249, encountered these cases in the codebase of calling `.into()` unecessarily. Splitting them out so that they can land independently of the lint.
…bounds-on-parent-params, r=notriddle
rustdoc: IXCRE: Preserve sizedness bounds on type params belonging to the parent item
Fixesrust-lang#144015.
…nkov
Some more simple per-owner resolver changes
Fairly straight forward ones. The remaining data structures are either more involved or blocked on other changes waiting to happen.
I especially like how the import res map stops being a map, as there can only be one import res per owner (each import is its own owner)
r? @petrochenkov
…rs, r=notriddle
librustdoc: fix CSS border issue to support Firefox high contrast mode
This fixesrust-lang#157378. The spacing and the clickable areas of the links are identical. The only difference is that there are no longer any unsightly thick borders.
Screenshot before the fix:
<img width="1180" height="676" alt="image" src="https://github.com/user-attachments/assets/f213561f-de90-4262-baba-2aa18c59d287" />
Screenshot after the fix:
<img width="1180" height="676" alt="image" src="https://github.com/user-attachments/assets/72504d0a-cca3-4b39-8d35-ecc5ac84e361" />
…dity, r=oli-obk
interpreter: improve comments and error message in mir_assign_valid_types
I looked at this while debugging rust-lang#155477, but this makes no progress on that issue.
Correct description of panic.rs
I was perusing the module documentation and stumbled upon the existing description, which confused me for a minute.
## Summary:
The foremost description of this module was:
> Panic support in the standard library.
This commit changes that to:
> Panic support in core.
interpret: fix mir::UnOp layout computation
"The operand always has the same type as the result" was correct when I wrote the comment, but more `UnOp`s have been added since, making this incorrect now. This hasn't caused issues yet because apparently the local variable layout cache means we hardly ever (never?) actually use the "known" layout.
r? @oli-obk
…=mejrs
Rewrite target checking for `#[sanitize]`
r? @mejrs
@rustbotrustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Jun 3, 2026
@jhpratt

Copy link
Copy Markdown
MemberAuthor

@bors r+ rollup=never p=5

@rust-bors

rust-borsBot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

📌 Commit c4f09d5 has been approved by jhpratt

It is now in the queue for this repository.

@rust-borsrust-borsBot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 3, 2026
@rust-bors

This comment has been minimized.

@rust-borsrust-borsBot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 3, 2026
@rust-bors

rust-borsBot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: jhpratt
Duration: 3h 23m 20s
Pushing b354133 to main...

@rust-bors
rust-borsBot merged commit b354133 into rust-lang:mainJun 3, 2026
13 checks passed
@rustbotrustbot added this to the 1.98.0 milestone Jun 3, 2026
@github-actions

Copy link
Copy Markdown
Contributor
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 9c963ee (parent) -> b354133 (this PR)

Test differences

Show 4766 test diffs

Stage 1

  • [rustdoc-html] tests/rustdoc-html/inline_cross/self-sized-bounds-24183.rs: pass -> [missing] (J1)
  • [rustdoc-html] tests/rustdoc-html/inline_cross/sized-bounds.rs: [missing] -> pass (J1)

Stage 2

  • [rustdoc-html] tests/rustdoc-html/inline_cross/self-sized-bounds-24183.rs: pass -> [missing] (J0)
  • [rustdoc-html] tests/rustdoc-html/inline_cross/sized-bounds.rs: [missing] -> pass (J0)

Additionally, 4762 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b354133fb126352871bea4b40795a45739adff2b --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-gnu-gcc-core-tests: 7m 58s -> 14m 12s (+78.2%)
  2. dist-aarch64-apple: 1h 27m -> 2h 12m (+51.7%)
  3. i686-gnu-2: 1h 13m -> 1h 43m (+41.1%)
  4. x86_64-gnu-tools: 45m 27s -> 1h 3m (+40.2%)
  5. x86_64-mingw-1: 2h 7m -> 2h 54m (+36.7%)
  6. dist-apple-various: 2h 11m -> 1h 25m (-34.5%)
  7. dist-aarch64-linux: 2h 40m -> 1h 47m (-33.0%)
  8. dist-i686-msvc: 1h 49m -> 2h 23m (+30.9%)
  9. pr-check-1: 26m 55s -> 35m 5s (+30.4%)
  10. dist-riscv64-linux: 1h 12m -> 1h 33m (+28.1%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer

Copy link
Copy Markdown
Collaborator

📌 Perf builds for each rolled up PR:

PR#MessagePerf Build Sha
#155512interpreter: improve comments and error message in mir_assi…388ac59aac741aae552329ad34c3daea5db49188 (link)
#157085powerpc: warn against incorrect values for ABI-relevant tar…4f9391aedc5a9088645f906130894bfd21552026 (link)
#157170Use impl restrictions in std, core0ca140248b841cfa276f03c24695ea0ccd6574bb (link)
#157217[tiny] remove unecessary .into() calls577e4e31f61462fbd3f7fc695c315fb7ed92ec7d (link)
#157254Correct description of panic.rs2efc7511b085efe343c7cc8cfde2c9bbb2ee25c1 (link)
#157262rustdoc: IXCRE: Preserve sizedness bounds on type params be…3b5acb24d08900d0be77eb05513e397857ceb870 (link)
#157290interpret: fix mir::UnOp layout computation735d8b9a9db71faa653ecb0a19fc413ebbf7f134 (link)
#157332Rewrite target checking for #[sanitize]e9b97908710c7953c9a169788fddc5a8da9da790 (link)
#157351Avoid leaking the query-job collection warning into the pan…857ce1f058bc7fc0d39389f12f0c7991f7d92fff (link)
#157379Some more simple per-owner resolver changesd7f461cb0bbe1feb57cdd0329c8bae02a89b30cb (link)
#157381librustdoc: fix CSS border issue to support Firefox high co…08da5da43e74dcabd1c26c94b7dad768f7fe2d39 (link)
#157389Add @clarfonthey to libs review rotationa0b91468c08aa33e75ac27d2f45719115cf6835d (link)

previous master: 9c963eecaa

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (b354133): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

meanrangecount
Regressions ❌
(primary)
0.2%[0.1%, 0.3%]7
Regressions ❌
(secondary)
0.3%[0.1%, 0.6%]41
Improvements ✅
(primary)
-0.2%[-0.4%, -0.2%]5
Improvements ✅
(secondary)
-0.3%[-0.6%, -0.0%]8
All ❌✅ (primary)-0.0%[-0.4%, 0.3%]12

Max RSS (memory usage)

Results (primary -1.9%, secondary -0.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

meanrangecount
Regressions ❌
(primary)
--0
Regressions ❌
(secondary)
3.1%[1.4%, 8.4%]5
Improvements ✅
(primary)
-1.9%[-3.0%, -0.7%]2
Improvements ✅
(secondary)
-3.1%[-4.3%, -1.1%]7
All ❌✅ (primary)-1.9%[-3.0%, -0.7%]2

Cycles

Results (primary -1.2%, secondary 1.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

meanrangecount
Regressions ❌
(primary)
--0
Regressions ❌
(secondary)
2.6%[2.0%, 3.0%]3
Improvements ✅
(primary)
-1.2%[-1.2%, -1.2%]1
Improvements ✅
(secondary)
-1.9%[-1.9%, -1.9%]1
All ❌✅ (primary)-1.2%[-1.2%, -1.2%]1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 519.257s -> 511.076s (-1.58%)
Artifact size: 400.68 MiB -> 400.68 MiB (-0.00%)

@Mark-Simulacrum

Copy link
Copy Markdown
Member

There's some noise, I think, but seems like most of the regressions are from #157262 (comment). Marking as triaged.

@Mark-SimulacrumMark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Jun 9, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributesArea: Attributes (`#[…]`, `#![…]`)A-metaArea: Issues & PRs about the rust-lang/rust repository itselfA-query-systemArea: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html)A-rustdoc-jsArea: Rustdoc's JS front-endmerged-by-borsThis PR was explicitly merged by bors.O-appleOperating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS)O-linuxOperating system: LinuxO-netbsdOperating system: NetBSDO-solarisOperating system: SolarisO-solidOperating System: SOLIDO-unixOperating system: Unix-likeO-windowsOperating system: Windowsperf-regressionPerformance regression.perf-regression-triagedThe performance regression has been triaged.rollupA PR which is a rollupT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.T-rustdoc-frontendRelevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output.WG-trait-system-refactorThe Rustc Trait System Refactor Initiative (-Znext-solver)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

13 participants

@jhpratt@rust-timer@Mark-Simulacrum@rustbot@RalfJung@felix91gr@fmease@estebank@oli-obk@xmakro@robbycbennett@JonathanBrouwer@clarfonthey