Skip to content

Rollup of 6 pull requests #143521

New issue

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

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

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
Jul 6, 2025
Merged

Rollup of 6 pull requests #143521

merged 18 commits into from
Jul 6, 2025

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jul 6, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Ayush1325 and others added 18 commits July 5, 2025 11:10
A blocking implementation of tcp4 read.

Signed-off-by: Ayush Singh <[email protected]>
Rather than a `bool` that's `true` for the LHS and `false` for the RHS,
use a self-documenting enum.
previous behavior was inconsistent with existing extra checks.
The parser repeatedly invokes the `parse` function, constructing a
one-entry vector, and assuming that the return value will be a one-entry
vector. Add a helper for that case. This will simplify adding additional
callers, and put all the logic in one place to allow potential future
simplification of the one-TT case.
…o rule

The MBE parser checks rules at initial parse time to see if their RHS
has `compile_error!` in it, and returns a list of rule indexes and LHS
spans that don't map to `compile_error!`, for use in unused macro rule
checking.

Instead, have the unused macro rule reporting ask the macro for the rule
to report, and let the macro check at that time. That avoids checking
rules unless they're unused.

In the process, refactor the data structure used to store macro rules,
to group the LHS and RHS (and LHS span) of each rule together, and
refactor the unused rule tracking to only track rule indexes.

This ends up being a net simplification, and reduction in code size.
…r=nnethercote

mbe: Defer checks for `compile_error!` until reporting an unused macro rule

The current MBE parser checks rules at initial parse time to see if their RHS has `compile_error!` in it, and returns a list of rule indexes and LHS spans that don't map to `compile_error!`, for use in unused macro rule checking.

Instead, have the unused macro rule reporting ask the macro for the rule to report, and let the macro check at that time. That avoids checking rules unless they're unused.

In the process, refactor the data structure used to store macro rules, to group the LHS and RHS (and LHS span) of each rule together, and refactor the unused rule tracking to only track rule indexes.

This builds atop a couple of minor MBE refactors. I would suggest reviewing commit-by-commit.

The overall result is a further simplification of the macro code.
…iplett

std: sys: net: uefi: tcp4: Implement read

- A blocking implementation of tcp4 read.
- Basically a copy of [write](rust-lang#141532)
…oshtriplett

use `is_multiple_of` and `div_ceil`

In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs:

- the manual `is_multiple_of` often does not handle division by zero
- manual `div_ceil` often does not consider overflow

The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
…rrors

distinguish the duplicate item of rpitit

Fixes rust-lang#140796

r? compiler

cc `@Zoxc`
…, r=Kobzol

tidy: use --bless for tidy spellcheck instead of spellcheck:fix

previous behavior was inconsistent with existing extra checks.

unsure if this needs a change tracker entry or a warning for people who try to use the old behavior.

unsure if we should call this `spellcheck:lint` for consistency.

making this consistent is a prerequisite for rust-lang#143398

cc `@nnethercote`

r? `@Kobzol`
compiletest: print slightly more information on fs::write failure

See [#t-infra > compiletest: panic in dump_output_file: No such file or dire @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/compiletest.3A.20panic.20in.20dump_output_file.3A.20No.20such.20file.20or.20dire/near/527294714)
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-testsuite Area: The testsuite used to check the correctness of rustc labels Jul 6, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@rustbot rustbot added A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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 Jul 6, 2025
@bors
Copy link
Collaborator

bors commented Jul 6, 2025

📌 Commit 097efc0 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 Jul 6, 2025
@bors
Copy link
Collaborator

bors commented Jul 6, 2025

⌛ Testing commit 097efc0 with merge c83e217...

@bors
Copy link
Collaborator

bors commented Jul 6, 2025

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 6, 2025
@bors bors merged commit c83e217 into rust-lang:master Jul 6, 2025
12 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 6, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#143416 mbe: Defer checks for compile_error! until reporting an u… 9d6629f75d3810ad94c1595475bd2aee9f0dcbc3 (link)
#143470 std: sys: net: uefi: tcp4: Implement read c9362649b63d6e69a4e4501e5dd2304155627366 (link)
#143477 use is_multiple_of and div_ceil edd4f48a3d282ca396754378b6628822f9163b9a (link)
#143484 distinguish the duplicate item of rpitit 58f771e6a773bc5ea09acfe446304204af955454 (link)
#143493 tidy: use --bless for tidy spellcheck instead of spellcheck… 6a3316f3b3c9a25faf2fa0289d42e052a27624e4 (link)
#143504 compiletest: print slightly more information on fs::write f… 9cf76edb9449a46e77e900e23e57509773131146 (link)

previous master: e804cd4a5f

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

Copy link
Contributor

github-actions bot commented Jul 6, 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 e804cd4 (parent) -> c83e217 (this PR)

Test differences

Show 5 test diffs

Stage 1

  • [ui] tests/ui/impl-trait/in-trait/rpitit-duplicate-associated-fn.rs: [missing] -> pass (J0)

Stage 2

  • [ui] tests/ui/impl-trait/in-trait/rpitit-duplicate-associated-fn.rs: [missing] -> pass (J1)

Additionally, 3 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 c83e217d268d25960a0c79c6941bcb3917a6a0af --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

  1. x86_64-apple-2: 3965.9s -> 5079.7s (28.1%)
  2. x86_64-gnu-llvm-19-1: 3236.2s -> 3801.8s (17.5%)
  3. dist-x86_64-apple: 9367.2s -> 7795.6s (-16.8%)
  4. i686-gnu-2: 5169.6s -> 6036.9s (16.8%)
  5. x86_64-rust-for-linux: 2594.5s -> 2947.9s (13.6%)
  6. arm-android: 5703.9s -> 6353.7s (11.4%)
  7. x86_64-gnu-debug: 5380.1s -> 5951.8s (10.6%)
  8. i686-gnu-nopt-1: 7058.9s -> 7789.3s (10.3%)
  9. armhf-gnu: 4815.1s -> 5310.6s (10.3%)
  10. x86_64-gnu-aux: 6048.3s -> 6640.6s (9.8%)
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

Finished benchmarking commit (c83e217): 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

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

mean range count
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 1
Regressions ❌
(secondary)
0.3% [0.2%, 0.3%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.2% [-1.9%, -0.0%] 9
All ❌✅ (primary) 0.2% [0.2%, 0.2%] 1

Max RSS (memory usage)

Results (primary 1.4%, secondary 2.8%)

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

mean range count
Regressions ❌
(primary)
4.4% [2.3%, 6.8%] 3
Regressions ❌
(secondary)
7.7% [7.7%, 7.7%] 1
Improvements ✅
(primary)
-3.1% [-5.0%, -1.3%] 2
Improvements ✅
(secondary)
-2.1% [-2.1%, -2.1%] 1
All ❌✅ (primary) 1.4% [-5.0%, 6.8%] 5

Cycles

Results (primary 2.2%)

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

mean range count
Regressions ❌
(primary)
2.2% [2.1%, 2.3%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.2% [2.1%, 2.3%] 2

Binary size

Results (primary 0.0%, secondary 0.0%)

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

mean range count
Regressions ❌
(primary)
0.1% [0.0%, 0.2%] 7
Regressions ❌
(secondary)
0.1% [0.1%, 0.1%] 1
Improvements ✅
(primary)
-0.0% [-0.1%, -0.0%] 2
Improvements ✅
(secondary)
-0.0% [-0.0%, -0.0%] 4
All ❌✅ (primary) 0.0% [-0.1%, 0.2%] 9

Bootstrap: 462.855s -> 461.809s (-0.23%)
Artifact size: 372.14 MiB -> 372.19 MiB (0.02%)

@rustbot rustbot added the perf-regression Performance regression. label Jul 6, 2025
@panstromek
Copy link
Contributor

perf triage:

coercions regressions seems to be noise, looks like a new bimodailty. Other changes are tiny, I don't think this is worth investigating.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Jul 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compiletest Area: The compiletest test runner A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) A-testsuite Area: The testsuite used to check the correctness of rustc A-tidy Area: The tidy tool merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.