Rollup of 7 pull requests #145236

Zalathar · 2025-08-11T02:21:11Z

Successful merges:

Constify remaining traits/impls for const_ops #143949 (Constify remaining traits/impls for const_ops)
document assumptions about Clone and Eq traits #144330 (document assumptions about Clone and Eq traits)
std: sys: io: io_slice: Add UEFI types #144350 (std: sys: io: io_slice: Add UEFI types)
Point at the Fn() or FnMut() bound that coerced a closure, which caused a move error #144558 (Point at the Fn() or FnMut() bound that coerced a closure, which caused a move error)
Make config method invoke inside parse use dwn_ctx #145149 (Make config method invoke inside parse use dwn_ctx)
Tweak spans providing type context on errors when involving macros #145227 (Tweak spans providing type context on errors when involving macros)
Remove unnecessary parentheses in assert!s #145228 (Remove unnecessary parentheses in assert!s)

r? @ghost
@rustbot modify labels: rollup

UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation. Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST. Signed-off-by: Ayush Singh <[email protected]>

…ibutes explicitly

…caused a move error When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error. ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:15:25 | 14 | fn do_stuff(foo: Option<Foo>) { | --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait | | | captured outer variable 15 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 16 | if foo.map_or(false, |f| f.foo()) { | --- variable moved due to use in coroutine | help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once --> f111.rs:12:53 | 12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {} | ^^^^^^^^^ help: consider cloning the value if the performance cost is acceptable | 16 | if foo.clone().map_or(false, |f| f.foo()) { | ++++++++ ```

Do not point at macro invocation which expands to an inference error. Avoid the following: ``` error[E0308]: mismatched types --> $DIR/does-not-have-iter-interpolated.rs:12:5 | LL | quote!($($nonrep)*); | ^^^^^^^^^^^^^^^^^^^ | | | expected `HasIterator`, found `ThereIsNoIteratorInRepetition` | expected due to this | here the type of `has_iter` is inferred to be `ThereIsNoIteratorInRepetition` ```

…nieu Constify remaining traits/impls for `const_ops` Tracking issue: rust-lang#143802 This is split into two commits for ease of reviewability: 1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before. 2. Actually constify the traits/impls. A few random other notes on the implementation specifically: * I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse. ---- As far as the actual changes go, this constifies the following additional traits: * `Neg` * `Not` * `BitAnd` * `BitOr` * `BitXor` * `Shl` * `Shr` * `AddAssign` * `SubAssign` * `MulAssign` * `DivAssign` * `RemAssign` * `BitAndAssign` * `BitOrAssign` * `BitXorAssign` * `ShlAssign` * `ShrAssign` In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives. Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead) There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives. * `Duration` (arithmetic operations) * `SystemTime` (arithmetic operations) * `Ipv4Addr` (bit operations) * `Ipv6Addr` (bit operations) Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang#144517. Stuff left out of this PR: * `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out) * `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful) * `SystemTime` (will submit separate PR) * SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467)   > [!NOTE] > # Concerns (0 active) > > - ~~[May break Clippy](rust-lang#143949 (comment) resolved in [this comment](rust-lang#143949 (comment)) > > *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*

…=Amanieu document assumptions about `Clone` and `Eq` traits Most standard library collections break if `Clone` has a non-standard implementation which violates `x.clone() == x`. [Here](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b7fc6dfa8410cbb673eb8d38393d81de) the resulting broken behaviour of different collections is shown. I originally created an issue at rust-lang/hashbrown#629, but the conclusion there was that `x.clone()` resulting in an object that compares equal to the original one is probably a very universal assumption. However, this assumption is (to my knowledge) not documented anywhere. I propose to make this assumption explicit in the `Clone` trait documentation. The property that seems the most reasonable to me is the following: When implementing both `Clone` and `PartialEq`, then ```text x == x -> x.clone() == x ``` is expected to hold. This way, when also implementing `Eq`, it automatically follows that `x.clone() == x` has to hold, which should be enough for the collections to not break. At the same time, the property also works for the "normal" elements of a type with `PartialEq`. For the wording, I tried to follow the [`Hash` and `Eq`](https://doc.rust-lang.org/std/hash/trait.Hash.html#hash-and-eq) documentation. As I am fairly new to Rust, it might well be that this property cannot be generally expected – it seems reasonable to me, but any counter-examples or critique, both content- and wording-wise, would be very welcome. If the property turns out to be too general, I would suggest to at least document the assumption of `x.clone() == x` for the collections somehow. An additional thought of mine: If it is indeed generally expected that `x == x -> x.clone() == x`, then, for the sake of completeness, one could also define that `x != x -> y != y for y = x.clone()` should hold, i.e., that an object that did not compare equal to itself before cloning, should also not compare equal to itself afterwards.

…olasbishop std: sys: io: io_slice: Add UEFI types UEFI networking APIs do support vectored read/write. While the types for UDP4, UDP6, TCP4 and TCP6 are defined separately, they are essentially the same C struct. So we can map IoSlice and IoSliceMut to have the same binary representation. Since all UEFI networking types for read/write are DSTs, `IoSlice` and `IoSliceMut` will need to be copied to the end of the transmit/receive structures. So having the same binary representation just allows us to do a single memcpy instead of having to loop and set the DST. cc ``@nicholasbishop``

Point at the `Fn()` or `FnMut()` bound that coerced a closure, which caused a move error When encountering a move error involving a closure because the captured value isn't `Copy`, and the obligation comes from a bound on a type parameter that requires `Fn` or `FnMut`, we point at it and explain that an `FnOnce` wouldn't cause the move error. ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:15:25 | 14 | fn do_stuff(foo: Option<Foo>) { | --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait | | | captured outer variable 15 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 16 | if foo.map_or(false, |f| f.foo()) { | --- variable moved due to use in coroutine | help: `Fn` and `FnMut` closures require captured values to be able to be consumed multiple times, but an `FnOnce` consume them only once --> f111.rs:12:53 | 12 | fn require_fn_trait<F: Future<Output = ()>>(_: impl Fn() -> F) {} | ^^^^^^^^^ help: consider cloning the value if the performance cost is acceptable | 16 | if foo.clone().map_or(false, |f| f.foo()) { | ++++++++ ``` Fix rust-lang#68119, by pointing at `Fn` and `FnMut` bounds involved in move errors.

…ig-method-invoke-inside-parse-functions, r=Kobzol Make config method invoke inside parse use dwn_ctx This PR is part of a series of config refactorings. It removes calls from config methods to solid functions defined in `config.rs`. After this, we will remove the default dependencies in the config. r? ```@Kobzol```

…oshtriplett Tweak spans providing type context on errors when involving macros Do not point at macro invocation multiple times when we try to add span labels mentioning what type each expression has, which is unnecessary when the error is at a macro invocation.

Zalathar · 2025-08-11T02:21:27Z

@bors r+ rollup=never p=5

bors · 2025-08-11T02:21:29Z

📌 Commit fd7d724 has been approved by Zalathar

It is now in the queue for this repository.

bors · 2025-08-11T02:59:17Z

⌛ Testing commit fd7d724 with merge 53af067...

bors · 2025-08-11T05:59:45Z

☀️ Test successful - checks-actions
Approved by: Zalathar
Pushing 53af067 to master...

rust-timer · 2025-08-11T06:01:46Z

📌 Perf builds for each rolled up PR:

PR#	Message	Perf Build Sha
#143949	Constify remaining traits/impls for `const_ops`	`69636ab081fb341a1b8bee97692b63f372d83a0f` (link)
#144330	document assumptions about `Clone` and `Eq` traits	`b979905d2fa66bd0a594dcc97e5bee8fe05d3f1f` (link)
#144350	std: sys: io: io_slice: Add UEFI types	`2e93a2500091793609ed372a6a2facec8b09e7ed` (link)
#144558	Point at the `Fn()` or `FnMut()` bound that coerced a closu…	`d5ad7be8327933c8b51f3fc934617164aeb1e9b4` (link)
#145149	Make config method invoke inside parse use dwn_ctx	`d76b3478ad30463ffcc209b8ce0f84b92dd39d6e` (link)
#145227	Tweak spans providing type context on errors when involving…	`00d3ae0eabf560bde34e6ae3f3374c8f0e51b193` (link)
#145228	Remove unnecessary parentheses in `assert!`s	`40c96e5a6a21fe5109c7c36ced13b3908dfcd19c` (link)

previous master: 21a19c297d

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

github-actions · 2025-08-11T06:02:55Z

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 21a19c2 (parent) -> 53af067 (this PR)

Test differences

Show 2112 test diffs

Stage 1

[ui] tests/ui/proc-macro/match-expander.rs: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/proc-macro/match-expander.rs: [missing] -> pass (J0)

Additionally, 2110 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 53af067bb0b4edf9b5394e5f9b60942974b9fbc2 --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

aarch64-apple: 5819.7s -> 8935.9s (53.5%)
x86_64-apple-1: 7800.9s -> 9952.6s (27.6%)
x86_64-apple-2: 6252.0s -> 5299.8s (-15.2%)
x86_64-rust-for-linux: 2898.4s -> 2558.7s (-11.7%)
aarch64-msvc-1: 6263.6s -> 6885.0s (9.9%)
x86_64-msvc-ext3: 6760.5s -> 6215.3s (-8.1%)
aarch64-msvc-2: 5122.5s -> 4780.6s (-6.7%)
dist-aarch64-linux: 5898.1s -> 5532.0s (-6.2%)
x86_64-gnu-nopt: 7307.5s -> 7713.8s (5.6%)
x86_64-gnu-llvm-20-1: 3721.1s -> 3515.7s (-5.5%)

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 · 2025-08-11T07:09:56Z

Finished benchmarking commit (53af067): comparison URL.

Overall result: ❌ regressions - 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

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

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.5%]	6
Regressions ❌ (secondary)	0.4%	[0.1%, 0.5%]	17
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.2%, 0.5%]	6

Max RSS (memory usage)

Results (primary -1.4%, secondary 1.4%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[2.0%, 3.0%]	4
Improvements ✅ (primary)	-1.4%	[-1.4%, -1.4%]	1
Improvements ✅ (secondary)	-3.2%	[-3.2%, -3.2%]	1
All ❌✅ (primary)	-1.4%	[-1.4%, -1.4%]	1

Cycles

Results (primary 2.1%, secondary 5.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.1%	[2.1%, 2.1%]	1
Regressions ❌ (secondary)	5.9%	[5.9%, 5.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.1%	[2.1%, 2.1%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.264s -> 463.403s (-0.19%)
Artifact size: 377.36 MiB -> 377.34 MiB (-0.00%)

Zalathar · 2025-08-11T07:28:48Z

@rust-timer build 69636ab
@rust-timer build d5ad7be
@rust-timer build 00d3ae0

Zalathar · 2025-08-11T08:12:45Z

@rust-timer build d5ad7be

Zalathar · 2025-08-11T08:13:57Z

@rust-timer ping

Kobzol · 2025-08-11T08:31:07Z

@rust-timer build d5ad7be

Kobzol · 2025-08-11T08:31:34Z

Oh, you actually queued multiple commits on one PR. That's not really supported 😆 You have to do it on separate PRs, there's always max. one concurrent try build per PR.

rust-timer · 2025-08-11T09:24:26Z

Finished benchmarking commit (69636ab): comparison URL.

Overall result: ❌ regressions - please read the text below

Instruction count

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

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.2%, 0.6%]	7
Regressions ❌ (secondary)	0.4%	[0.2%, 0.6%]	17
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.2%, 0.6%]	7

Max RSS (memory usage)

Results (primary -1.4%, secondary 1.1%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.5%	[2.0%, 2.8%]	3
Improvements ✅ (primary)	-1.4%	[-1.4%, -1.4%]	1
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	-1.4%	[-1.4%, -1.4%]	1

Cycles

Results (primary 2.4%, secondary 6.0%)

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

	mean	range	count
Regressions ❌ (primary)	2.4%	[2.2%, 2.7%]	2
Regressions ❌ (secondary)	6.0%	[6.0%, 6.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[2.2%, 2.7%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 464.264s -> 466.204s (0.42%)
Artifact size: 377.36 MiB -> 377.35 MiB (-0.00%)

Zalathar · 2025-08-11T09:46:36Z

Looks like perf regressions are from #143949.

Kobzol · 2025-08-12T06:34:13Z

Regression caused by #143949. It's a tiny doc-only regression though, and since that PR did a lot of changes to built-in traits, I don't think there's much to be done here.

@rustbot label: +perf-regression-triaged

gewitternacht and others added 30 commits July 22, 2025 23:16

document assumptions about Clone and Eq traits

30033b4

remove trailing whitespace

cdbcd72

add links to collections

623317e

clearer wording for unsafe code

c72bb70

add download_ci_rustc_commit function and invoke from parse_inner

b4675dc

add parse_download_ci_llvm function and invoke from parse_inner

111a0e8

add is_system_llvm function and invoke from parse_inner

7eb8f60

add git_info function and invoke from parse_inner

134fcc8

add ci_llvm_root function and invoke from parse_inner

2213b7a

add read_file_by_commit function and invoke from parse_inner

621af4a

invoke functions from methods

aad54a8

extend download context and change functions to directly use that

8612db2

add review comments

bfa6b56

Let forward_ref_* macros accept multiple attributes, and require attr…

f604dd1

…ibutes explicitly

Constify remaining operators

bb32e31

Add support for method calls

2484e18

review comments

74496bc

Add test showing innecessary inference span

d9bd24d

Do not point at macro invocation when providing inference context

48816e7

Remove unnecessary parentheses in assert!s

74c3727

mention Hash and Ord; refine description of derive

fadc961

rustbot 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. rollup A PR which is a rollup labels Aug 11, 2025

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 Aug 11, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 11, 2025

bors merged commit 53af067 into rust-lang:master Aug 11, 2025
11 checks passed

rustbot added this to the 1.91.0 milestone Aug 11, 2025

bors mentioned this pull request Aug 11, 2025

std: sys: pal: uefi: Overhaul Time #139806

Merged

rustbot added the perf-regression Performance regression. label Aug 11, 2025

Zalathar deleted the rollup-1ggbztv branch August 11, 2025 07:21

This comment has been minimized.

Sign in to view

Zalathar mentioned this pull request Aug 12, 2025

Constify remaining traits/impls for const_ops #143949

Merged

clarfonthey mentioned this pull request Aug 12, 2025

Tracking Issue for const_ops #143802

Open

3 tasks

rustbot added the perf-regression-triaged The performance regression has been triaged. label Aug 12, 2025

Rollup of 7 pull requests #145236

Rollup of 7 pull requests #145236

Conversation

Zalathar commented Aug 11, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zalathar commented Aug 11, 2025

Uh oh!

bors commented Aug 11, 2025

Uh oh!

bors commented Aug 11, 2025

Uh oh!

bors commented Aug 11, 2025

Uh oh!

Uh oh!

rust-timer commented Aug 11, 2025

Uh oh!

github-actions bot commented Aug 11, 2025

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Aug 11, 2025

Overall result: ❌ regressions - please read the text below

Uh oh!

Zalathar commented Aug 11, 2025

Uh oh!

This comment has been minimized.

Zalathar commented Aug 11, 2025

Uh oh!

Zalathar commented Aug 11, 2025

Uh oh!

Kobzol commented Aug 11, 2025

Uh oh!

Kobzol commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-timer commented Aug 11, 2025

Overall result: ❌ regressions - please read the text below

Uh oh!

Zalathar commented Aug 11, 2025

Uh oh!

Kobzol commented Aug 12, 2025

Uh oh!

Uh oh!

Zalathar commented Aug 11, 2025 •

edited by rustbot

Loading

Kobzol commented Aug 11, 2025 •

edited

Loading