Skip to content

Rollup of 6 pull requests #142234

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 13 commits into from
Jun 9, 2025
Merged

Rollup of 6 pull requests #142234

merged 13 commits into from
Jun 9, 2025

Conversation

matthiaskrgr
Copy link
Member

@matthiaskrgr matthiaskrgr commented Jun 9, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

jieyouxu and others added 13 commits May 31, 2025 23:03
- Map compiler sources (corresponding to `rustc-dev` dist component)
  with `/rustc-dev/{hash}`.
- Map non-compiler sources (corresponding to `rust-src` dist component
  or other non-compiler sources) with `/rustc/{hash}`.

This allows the compiler to have the possibility of opportunistically
reverse the mapping. This is because

- `rust-src` unpacks sources to a path like
  `$sysroot/lib/rustlib/src/rust`, whereas
- `rustc-dev` unpacks sources to a path like
  `$sysroot/lib/rustlib/rustc-src/rust`

(Notice the `src` vs `rustc-src` difference.)
Remove the comment on top as well, since that issue is now fixed in this
new tag.

Signed-off-by: Miguel Ojeda <[email protected]>
`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites,
is a stress test of the `recv_timeout` function. This test processes and
ignores timeouts, and just ensures that every sent value gets received.
As such, the exact length of the timeouts is not critical, only that
the timeout and sleep durations ensure that at least one timeout
occurred.

The current tests have 100 iterations, half of which sleep for 200ms,
causing the test to take 10s. This represents around 2/3rds of the
*total* runtime of the `library/std` testsuite.

Reduce this to 50 iterations where half of them sleep for 10ms, causing
the test to take 0.25s.

Add a check that at least one timeout occurred.
Remap compiler vs non-compiler sources differently (bootstrap side)

See [#t-compiler/help > Span pointing to wrong file location (&rust-lang#96;rustc-dev&rust-lang#96; component)](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Span.20pointing.20to.20wrong.20file.20location.20.28.60rustc-dev.60.20component.29/with/521087083).

The path remapping and unremapping for compiler sources (distributed via `rustc-dev` dist component) is broken because bootstrap currently remaps all sources unconditionally (if remapping is enabled) to the `/rustc/{hash}` form. However, the `rustc-dev` dist component (compiler sources) and `rust-src` dist component (library sources) unpacks differently:

- `rust-src` unpacks sources to a path like `$sysroot/lib/rustlib/src/rust`, whereas
- `rustc-dev` unpacks sources to a path like `$sysroot/lib/rustlib/rustc-src/rust`[^note],

meaning that the compiler need to unremap them differently. But the same remapping means that the compiler has no way to distinguish between compiler and non-compiler (esp. standard library) sources. To remedy this, this PR adopts the approach of:

- remapping compiler sources (corresponding to `rustc-dev` dist component) with `/rustc-dev/{hash}` (this is `RemapScheme::Compiler`), and
- remapping non-compiler sources (corresponding to `rust-src` dist component or other non-compiler sources) with `/rustc/{hash}` (this is `RemapScheme::NonCompiler`).

A different remapping allows the compiler to reverse the remapping differently.

This PR implements the bootstrap side. A follow-up compiler-side change is needed to implement the unremapping change to address the reported issue completely.

This PR introduces another env var `CFG_VIRTUAL_RUSTC_DEV_SOURCE_BASE_DIR` that is made available to the compiler when building compiler sources to know what the remap scheme for `rustc-dev` (`RemapScheme::Compiler`) is. Compiler sources are built with the compiler remapping scheme.

As far as I know, this change should not introduce new regressions, because the compiler source unremapping (through `rustc-dev`) is already broken.

[^note]: (Notice the `src` vs `rustc-src` difference.)
…tc, r=Kobzol

Only allow `bootstrap` cfg in rustc & related

Fixes rust-lang#142150
r? bootstrap
…rrors

early return in trait detection for non-trait item

Fixes rust-lang#135863
…, r=Mark-Simulacrum

Do not checkout GCC submodule for the tidy job

This is not a fully general solution, but the GCC submodule checkout is so slow that I think it's worth it to special-case it. This brings down the time required to checkout submodules from ~1.5 minute to ~0.5 minute.
CI: rfl: move job forward to Linux v6.16-rc1

Another hopefully routine upgrade to Linux v6.16-rc1, just released.

r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
…t-in-stress-test, r=workingjubilee

Avoid a gratuitous 10s wait in a stress test

`stress_recv_timeout_two_threads`, in the mpmc and mpsc testsuites, is a stress test of the `recv_timeout` function. This test processes and ignores timeouts, and just ensures that every sent value gets received. As such, the exact length of the timeouts is not critical, only that the timeout and sleep durations ensure that at least one timeout occurred.

The current tests have 100 iterations, half of which sleep for 200ms, causing the test to take 10s. This represents around 2/3rds of the *total* runtime of the `library/std` testsuite, and is the only standard library test that takes more than a second.

Reduce this to 50 iterations where half of them sleep for 10ms, causing the test to take 0.25s.

Add a check that at least one timeout occurred.
@rustbot rustbot added A-testsuite Area: The testsuite used to check the correctness of rustc 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-infra Relevant to the infrastructure 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 Jun 9, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jun 9, 2025

📌 Commit bf17f13 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 Jun 9, 2025
@bors
Copy link
Collaborator

bors commented Jun 9, 2025

⌛ Testing commit bf17f13 with merge 7c10378...

@bors
Copy link
Collaborator

bors commented Jun 9, 2025

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 9, 2025
@bors bors merged commit 7c10378 into rust-lang:master Jun 9, 2025
11 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 9, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#141751 Remap compiler vs non-compiler sources differently (bootstr… a831673c3e18ce0c4c71a41c4163a5d13ba39138 (link)
#142160 Only allow bootstrap cfg in rustc & related 449d777b98862acdb8c9a9da61508b7c3d32c6df (link)
#142191 early return in trait detection for non-trait item be1ab9d01630365a387c433fa78868be1dec5ae8 (link)
#142211 Do not checkout GCC submodule for the tidy job 02aa220c915090989130ba654a8f69bee8e27375 (link)
#142218 CI: rfl: move job forward to Linux v6.16-rc1 d5166b7862dc706cdbf91be409c0e11dabc1706a (link)
#142224 Avoid a gratuitous 10s wait in a stress test aa774d477dc4bf272aba8a0ad029f22d62b4820d (link)

previous master: b6685d748f

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 Jun 9, 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 b6685d7 (parent) -> 7c10378 (this PR)

Test differences

Show 4 test diffs

Stage 1

  • [crashes] tests/crashes/135863.rs: pass -> [missing] (J0)
  • [ui] tests/ui/suggestions/double-reference-ty-in-self-ty.rs: [missing] -> pass (J0)

Stage 2

  • [crashes] tests/crashes/135863.rs: pass -> [missing] (J1)
  • [ui] tests/ui/suggestions/double-reference-ty-in-self-ty.rs: [missing] -> pass (J2)

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 7c10378e1fee5ddc6573b916aeb884ab10e0de17 --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. dist-x86_64-apple: 7742.6s -> 11984.8s (54.8%)
  2. dist-apple-various: 5843.0s -> 8411.5s (44.0%)
  3. mingw-check-tidy: 68.7s -> 95.9s (39.6%)
  4. x86_64-apple-2: 5720.4s -> 4084.1s (-28.6%)
  5. dist-arm-linux-musl: 5203.6s -> 6348.0s (22.0%)
  6. dist-aarch64-apple: 4564.9s -> 5542.8s (21.4%)
  7. dist-i686-mingw: 7820.1s -> 9316.6s (19.1%)
  8. mingw-check-1: 1982.6s -> 1656.5s (-16.5%)
  9. x86_64-rust-for-linux: 2999.4s -> 2622.4s (-12.6%)
  10. aarch64-apple: 4721.9s -> 5294.8s (12.1%)
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 (7c10378): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (secondary -5.0%)

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

Binary size

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

Bootstrap: 753.257s -> 754.656s (0.19%)
Artifact size: 372.34 MiB -> 372.30 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc 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-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-infra Relevant to the infrastructure 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.

10 participants