Rollup of 6 pull requests #142234
Merged
Rollup of 6 pull requests #142234
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 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
added
A-testsuite
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: b6685d748f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 differencesShow 4 test diffsStage 1
Stage 2
Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 7c10378e1fee5ddc6573b916aeb884ab10e0de17 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (7c10378): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis 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. CyclesResults (secondary -5.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 753.257s -> 754.656s (0.19%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
bootstrapcfg in rustc & related #142160 (Only allowbootstrapcfg in rustc & related)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup