Rollup of 12 pull requests#157398
Conversation
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
|
@bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
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 differencesShow 4766 test diffsStage 1
Stage 2
Additionally, 4762 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard b354133fb126352871bea4b40795a45739adff2b --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 |
|
📌 Perf builds for each rolled up PR:
previous master: 9c963eecaa In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (b354133): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
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.
CyclesResults (primary -1.2%, secondary 1.5%)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: 519.257s -> 511.076s (-1.58%) |
Successful merges:
implrestrictions instd,core#157170 (Useimplrestrictions instd,core).into()calls #157217 ([tiny] remove unecessary.into()calls)#[sanitize]#157332 (Rewrite target checking for#[sanitize])r? @ghost
Create a similar rollup