Skip to content

Rollup of 9 pull requests #139336

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 26 commits into from
Apr 4, 2025
Merged

Rollup of 9 pull requests #139336

merged 26 commits into from
Apr 4, 2025

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ShE3py and others added 26 commits March 13, 2025 18:03
My review queue has gotten a bit out of hand. I'll work on reviewing those PRs before taking up new ones.
First, move the `lang_item_for_op` call from the top of
`lookup_op_method`'s body to its callsites. It makes those callsites a
little more verbose, but also means `lookup_op_method` no longer cares
whether it's handling a binop or unop. This lets us remove `Op` and
split `lang_item_for_op` into `lang_item_for_{bin,un}op`, which is a
little simpler.

This change is a prerequisite for adding the `ast::AssignOpKind` type in
a subsequent commit.
Because it's nice to avoid passing in unnecessary data.
In the AST, currently we use `BinOpKind` within `ExprKind::AssignOp` and
`AssocOp::AssignOp`, even though this allows some nonsensical
combinations. E.g. there is no `&&=` operator. Likewise for HIR and
THIR.

This commit introduces `AssignOpKind` which only includes the ten
assignable operators, and uses it in `ExprKind::AssignOp` and
`AssocOp::AssignOp`. (And does similar things for `hir::ExprKind` and
`thir::ExprKind`.) This avoids the possibility of nonsensical
combinations, as seen by the removal of the `bug!` case in
`lang_item_for_binop`.

The commit is mostly plumbing, including:
- Adds an `impl From<AssignOpKind> for BinOpKind` (AST) and `impl
  From<AssignOp> for BinOp` (MIR/THIR).
- `BinOpCategory` can now be created from both `BinOpKind` and
  `AssignOpKind`.
- Replaces the `IsAssign` type with `Op`, which has more information and
  a few methods.
- `suggest_swapping_lhs_and_rhs`: moves the condition to the call site,
  it's easier that way.
- `check_expr_inner`: had to factor out some code into a separate
  method.

I'm on the fence about whether avoiding the nonsensical combinations is
worth the extra code.
… r=spastorino

Tighten up assignment operator representations.

This is step 3 of [MCP 831](rust-lang/compiler-team#831).

r? `@spastorino`
Dedup `&mut *` reborrow suggestion in loops

rust-lang#73534 added a reborrow suggestion in loops; rust-lang#127579 generalized this to generic parameters, making the suggestion triggers twice:
```rs
use std::io::Read;

fn decode_scalar(_reader: impl Read) {}
fn decode_array(reader: &mut impl Read) {
    for _ in 0.. {
        decode_scalar(reader);
    }
}
```
```
error[E0382]: use of moved value: `reader`
 --> src/lib.rs:6:23
  |
4 | fn decode_array(reader: &mut impl Read) {
  |                 ------ move occurs because `reader` has type `&mut impl Read`, which does not implement the `Copy` trait
5 |     for _ in 0.. {
  |     ------------ inside of this loop
6 |         decode_scalar(reader);
  |                       ^^^^^^ value moved here, in previous iteration of loop
  |
help: consider creating a fresh reborrow of `reader` here
  |
6 |         decode_scalar(&mut *reader);
  |                       ++++++
help: consider creating a fresh reborrow of `reader` here
  |
6 |         decode_scalar(&mut *reader);
  |                       ++++++
```
This PR removes the suggestion in loops, as it requires generic parameters anyway (i.e., the reborrow is automatic if there is no generic params).

`@rustbot` label +A-borrow-checker +A-diagnostics +A-suggestion-diagnostics +D-papercut
…r-errors

impl !PartialOrd for HirId

revive of rust-lang#92233

Another checkbox of rust-lang#90317, another small step in making incremental less likely to die in horrible ways
Allow boolean literals in `check-cfg`

rust-lang#138632 (comment)
This makes it consistent with `--cfg`

We could alternatively add a forward-compatible lint against `--cfg true/false`
r? `@Urgau`
io: Avoid marking some bytes as uninit

These bytes were marked as uninit, which would cause them to be initialized multiple times even though it was not necessary.
…octest, r=fmease

Remove unused variables generated in merged doctests

The variable is unused so no need to keep it around.

cc `@notriddle`
r? `@camelid`
Add a mailmap entry for myself

Turns out I have not been at all consistent. Oops.
…atrieb

Put Noratrieb on vacation

My review queue has gotten a bit out of hand. I'll work on reviewing those PRs before taking up new ones.
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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. labels Apr 3, 2025
@rustbot rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Apr 3, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Apr 3, 2025

📌 Commit 4cf6c21 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors 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 Apr 3, 2025
@bors
Copy link
Collaborator

bors commented Apr 3, 2025

⌛ Testing commit 4cf6c21 with merge 4fd8c04...

@bors
Copy link
Collaborator

bors commented Apr 4, 2025

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 4fd8c04 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 4, 2025
@bors bors merged commit 4fd8c04 into rust-lang:master Apr 4, 2025
7 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 4, 2025
Copy link
Contributor

github-actions bot commented Apr 4, 2025

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 00095b3 (parent) -> 4fd8c04 (this PR)

Test differences

Show 118 test diffs

Stage 1

  • [ui] tests/ui/cfg/raw-true-false.rs: pass -> [missing] (J0)
  • [ui] tests/ui/cfg/raw-true-false.rs#r0x0: [missing] -> pass (J0)
  • [ui] tests/ui/cfg/raw-true-false.rs#r0x1: [missing] -> pass (J0)
  • [ui] tests/ui/cfg/raw-true-false.rs#r1x0: [missing] -> pass (J0)
  • [ui] tests/ui/cfg/raw-true-false.rs#r1x1: [missing] -> pass (J0)
  • [ui] tests/ui/check-cfg/invalid-arguments.rs#boolean: pass -> [missing] (J0)
  • [ui] tests/ui/check-cfg/invalid-arguments.rs#boolean_after_values: [missing] -> pass (J0)

Stage 2

  • [ui] tests/ui/cfg/raw-true-false.rs: pass -> [missing] (J1)
  • [ui] tests/ui/cfg/raw-true-false.rs#r0x0: [missing] -> pass (J1)
  • [ui] tests/ui/cfg/raw-true-false.rs#r0x1: [missing] -> pass (J1)
  • [ui] tests/ui/cfg/raw-true-false.rs#r1x0: [missing] -> pass (J1)
  • [ui] tests/ui/cfg/raw-true-false.rs#r1x1: [missing] -> pass (J1)
  • [ui] tests/ui/check-cfg/invalid-arguments.rs#boolean: pass -> [missing] (J1)
  • [ui] tests/ui/check-cfg/invalid-arguments.rs#boolean_after_values: [missing] -> pass (J1)

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

Job group index

  • J0: x86_64-gnu-llvm-18-3, x86_64-gnu-llvm-19-3
  • J1: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-18-1, x86_64-gnu-llvm-18-2, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Job duration changes

  1. x86_64-apple-2: 5090.9s -> 6824.4s (34.1%)
  2. dist-x86_64-linux-alt: 6903.9s -> 7197.4s (4.3%)
  3. dist-various-2: 3252.8s -> 3365.9s (3.5%)
  4. dist-i686-msvc: 6938.1s -> 7154.3s (3.1%)
  5. aarch64-gnu-debug: 4344.6s -> 4478.8s (3.1%)
  6. x86_64-gnu-debug: 6148.2s -> 6318.0s (2.8%)
  7. dist-armv7-linux: 5250.3s -> 5384.4s (2.6%)
  8. dist-powerpc64le-linux: 9471.8s -> 9704.8s (2.5%)
  9. i686-msvc-1: 9274.3s -> 9489.8s (2.3%)
  10. dist-s390x-linux: 5222.9s -> 5338.6s (2.2%)
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
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#138017 Tighten up assignment operator representations. b78066de228520011177341787c48900106c1b62 (link)
#138462 Dedup &mut * reborrow suggestion in loops 9808270b17f2fe2a463f19975292c475f5ad7209 (link)
#138610 impl !PartialOrd for HirId 2c577c816ba5578e4873db592c13cc0124c4f79d (link)
#138767 Allow boolean literals in check-cfg 4049529ddeab3f8e28ef680408cc8d7b24cb4b57 (link)
#139068 io: Avoid marking some bytes as uninit e604a8b8138c85365ca30cdb8ba1333287099c3c (link)
#139255 Remove unused variables generated in merged doctests ff0c8cadebb8dd4eeb656330c38ec4123d5da750 (link)
#139270 Add a mailmap entry for myself 500097afbf3f71eccaee799162fb2e6f7a8edf98 (link)
#139303 Put Noratrieb on vacation a143e6686686792929acb6c3410f1665093ca96a (link)
#139312 add Marco Ieni to mailmap 63b2b10845272642082dbe4d57b89ed2240d16c9 (link)

previous master: 00095b3da4

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
Collaborator

Finished benchmarking commit (4fd8c04): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

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
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.3% [-0.3%, -0.2%] 6
Improvements ✅
(secondary)
-0.3% [-0.6%, -0.1%] 21
All ❌✅ (primary) -0.3% [-0.3%, -0.2%] 6

Max RSS (memory usage)

Results (primary 3.3%, secondary 4.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)
3.3% [3.3%, 3.3%] 1
Regressions ❌
(secondary)
4.0% [3.3%, 4.8%] 4
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 3.3% [3.3%, 3.3%] 1

Cycles

Results (secondary -2.5%)

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)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.5% [-2.5%, -2.5%] 1
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 774.699s -> 776.101s (0.18%)
Artifact size: 365.85 MiB -> 365.72 MiB (-0.03%)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself merged-by-bors This PR was explicitly merged by bors. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.