Skip to content

Rollup of 12 pull requests#157398

Open
jhpratt wants to merge 32 commits into
rust-lang:mainfrom
jhpratt:rollup-qXar4uR
Open

Rollup of 12 pull requests#157398
jhpratt wants to merge 32 commits into
rust-lang:mainfrom
jhpratt:rollup-qXar4uR

Conversation

@jhpratt
Copy link
Copy Markdown
Member

@jhpratt jhpratt commented Jun 3, 2026

Successful merges:

r? @ghost

Create a similar rollup

RalfJung and 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

Fixes rust-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 fixes rust-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
jhpratt added 2 commits June 3, 2026 15:16
…arn, r=petrochenkov

Avoid leaking the query-job collection warning into the panic query stack

Part of rust-lang#154314.

When the compiler panics it prints the active query stack. That collection runs with `CollectActiveJobsKind::PartialAllowed`, which deliberately skips any query state shard whose lock it cannot take without waiting, since a complete job map is not needed just to print a stack.

Under the parallel front-end another thread can still hold a shard lock while the panic is being reported, so a shard is skipped nondeterministically and a `warn!("Failed to collect active jobs ...")` was printed. Because warnings are shown by default (the default `RUSTC_LOG` filter is `WARN`), this leaked an extra line into the diagnostics of panicking compilations and made their output differ run to run. The panicking thread's own query chain is always collectible (a query does not hold its shard lock while it runs), so the printed stack itself is unaffected; only the spurious warning varied.

A skipped shard is expected and tolerated on this path, so `warn!` was the wrong level for it to begin with. This lowers the message to `debug!` so it stays available with `RUSTC_LOG` but no longer pollutes the default output, and re-enables the one ui test that was disabled because of it.
@rust-bors rust-bors Bot added the rollup A PR which is a rollup label Jun 3, 2026
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-rustdoc-js Area: Rustdoc's JS front-end O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) O-linux Operating system: Linux O-netbsd Operating system: NetBSD O-solaris Operating system: Solaris O-solid Operating System: SOLID O-unix Operating system: Unix-like O-windows Operating system: Windows S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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
Member Author

jhpratt commented Jun 3, 2026

@bors r+ rollup=never p=5

@rust-bors
Copy link
Copy Markdown
Contributor

rust-bors Bot commented Jun 3, 2026

📌 Commit c4f09d5 has been approved by jhpratt

It is now in the queue for this repository.

@rust-bors rust-bors Bot 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
Copy link
Copy Markdown
Contributor

rust-bors Bot commented Jun 3, 2026

⌛ Testing commit c4f09d5 with merge b354133...

Workflow: https://github.com/rust-lang/rust/actions/runs/26909100941

rust-bors Bot pushed a commit that referenced this pull request Jun 3, 2026
Rollup of 12 pull requests

Successful merges:

 - #157085 (powerpc: warn against incorrect values for ABI-relevant target features)
 - #157170 (Use `impl` restrictions in `std`, `core`)
 - #157217 ([tiny] remove unecessary `.into()` calls)
 - #157262 (rustdoc: IXCRE: Preserve sizedness bounds on type params belonging to the parent item)
 - #157379 (Some more simple per-owner resolver changes)
 - #157381 (librustdoc: fix CSS border issue to support Firefox high contrast mode)
 - #155512 (interpreter: improve comments and error message in mir_assign_valid_types)
 - #157254 (Correct description of panic.rs)
 - #157290 (interpret: fix mir::UnOp layout computation)
 - #157332 (Rewrite target checking for `#[sanitize]`)
 - #157351 (Avoid leaking the query-job collection warning into the panic query stack)
 - #157389 (Add @clarfonthey to libs review rotation)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-attributes Area: Attributes (`#[…]`, `#![…]`) A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-rustdoc-js Area: Rustdoc's JS front-end O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) O-linux Operating system: Linux O-netbsd Operating system: NetBSD O-solaris Operating system: Solaris O-solid Operating System: SOLID O-unix Operating system: Unix-like O-windows Operating system: Windows rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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)

Projects

None yet

Development

Successfully merging this pull request may close these issues.