Rollup of 3 pull requests #135140

jhpratt · 2025-01-05T23:35:06Z

Successful merges:

cg_llvm: Use constants for DWARF opcodes, instead of FFI calls #135115 (cg_llvm: Use constants for DWARF opcodes, instead of FFI calls)
Clarified the documentation on core::iter::from_fn and core::iter::successors #135118 (Clarified the documentation on core::iter::from_fn and core::iter::successors)
Mark slice::reverse unstably const #135121 (Mark slice::reverse unstably const)

r? @ghost
@rustbot modify labels: rollup

…ccessors

The `gimli` crate is already a dependency of `thorin-dwp`, which is already a dependency of `rustc_codegen_ssa`.

…ilee cg_llvm: Use constants for DWARF opcodes, instead of FFI calls Split off from rust-lang#134009 to incorporate feedback from rust-lang#134009 (comment). Most of the constant values now come from gimli, which is already a compiler dependency. I noticed that `DW_OP_LLVM_fragment` is an LLVM detail that is not defined by DWARF and could hypothetically change, so I added a static assertion on the C++ side to detect that if it ever happens. r? workingjubilee

…s, r=jhpratt Clarified the documentation on `core::iter::from_fn` and `core::iter::successors` This PR clarifies the closure requirements for `core::iter::from_fn` and `core::iter::successors`. `std::iter::successors` in particular is a bit difficult to understand if you are not already familiar with the signature of [`checked_mul`](https://docs.rs/num/latest/num/trait.CheckedMul.html) used in the example. See rust-lang#135087

…ratt Mark `slice::reverse` unstably const Tracking issue rust-lang#135120 This is unblocked by the stabilization of `const_swap`

jhpratt · 2025-01-05T23:35:17Z

@bors r+ rollup=never p=3

bors · 2025-01-05T23:35:20Z

📌 Commit 0f9f91c has been approved by jhpratt

It is now in the queue for this repository.

bors · 2025-01-06T02:30:58Z

⌛ Testing commit 0f9f91c with merge 56f9e6f...

bors · 2025-01-06T05:18:46Z

☀️ Test successful - checks-actions
Approved by: jhpratt
Pushing 56f9e6f to master...

rust-timer · 2025-01-06T05:19:39Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#135115	cg_llvm: Use constants for DWARF opcodes, instead of FFI ca…	`92ac019c075af57b7c47e8acee07c886da648a5a` (link)
#135118	Clarified the documentation on `core::iter::from_fn` and `c…	`025cc4ae71b0cb3bff3986b14485474ba67bec77` (link)
#135121	Mark `slice::reverse` unstably const	`26938cc037337fa994d2915c41a0b67184bff350` (link)

previous master: feb32c6546

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 · 2025-01-06T06:34:41Z

Finished benchmarking commit (56f9e6f): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.5%, 0.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	2
All ❌✅ (primary)	-0.2%	[-1.7%, 0.6%]	3

Max RSS (memory usage)

Results (primary 2.3%, secondary 5.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.4%	[1.0%, 7.7%]	5
Regressions ❌ (secondary)	5.3%	[5.3%, 5.3%]	1
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.3%	[-2.8%, 7.7%]	6

Cycles

Results (secondary 2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.9%	[2.1%, 4.0%]	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.5%]	24
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.6%, -0.0%]	6
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.6%, 0.5%]	30

Bootstrap: 762.625s -> 763.028s (0.05%)
Artifact size: 325.60 MiB -> 325.70 MiB (0.03%)

Kobzol · 2025-01-07T09:55:58Z

Results are a wash, probably just a bit of codegen shuffling.

@rustbot label: +perf-regression-triaged

ranger-ross and others added 8 commits January 5, 2025 19:25

Clarified the documentation on core::iter::from_fn and core::iter::su…

6243c0f

…ccessors

Use gimli to get the values of DWARF constants needed by codegen

e267106

The `gimli` crate is already a dependency of `thorin-dwp`, which is already a dependency of `rustc_codegen_ssa`.

Use constants for DWARF opcodes, instead of FFI calls

1b62645

Explain why the DW_TAG_* constants remain as-is for now

f50721e

Mark slice::reverse unstably const

03c2ac2

Rollup merge of rust-lang#135121 - okaneco:const_slice_reverse, r=jhp…

0f9f91c

…ratt Mark `slice::reverse` unstably const Tracking issue rust-lang#135120 This is unblocked by the stabilization of `const_swap`

bors 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 Jan 5, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 6, 2025

bors merged commit 56f9e6f into rust-lang:master Jan 6, 2025
7 checks passed

rustbot added this to the 1.86.0 milestone Jan 6, 2025

rustbot added the perf-regression Performance regression. label Jan 6, 2025

rustbot added the perf-regression-triaged The performance regression has been triaged. label Jan 7, 2025

jhpratt deleted the rollup-pn2gi84 branch January 14, 2025 09:49

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Rollup of 3 pull requests #135140

Rollup of 3 pull requests #135140

Uh oh!

jhpratt commented Jan 5, 2025

Uh oh!

jhpratt commented Jan 5, 2025

Uh oh!

bors commented Jan 5, 2025

Uh oh!

bors commented Jan 6, 2025

Uh oh!

bors commented Jan 6, 2025

Uh oh!

Uh oh!

rust-timer commented Jan 6, 2025

Uh oh!

rust-timer commented Jan 6, 2025

Uh oh!

Kobzol commented Jan 7, 2025

Uh oh!

Uh oh!

Rollup of 3 pull requests #135140

Rollup of 3 pull requests #135140

Uh oh!

Conversation

jhpratt commented Jan 5, 2025

Uh oh!

jhpratt commented Jan 5, 2025

Uh oh!

bors commented Jan 5, 2025

Uh oh!

bors commented Jan 6, 2025

Uh oh!

bors commented Jan 6, 2025

Uh oh!

Uh oh!

rust-timer commented Jan 6, 2025

Uh oh!

rust-timer commented Jan 6, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Kobzol commented Jan 7, 2025

Uh oh!

Uh oh!