Skip to content

Conversation

@Qelxiros
Copy link
Contributor

@Qelxiros Qelxiros commented Oct 1, 2025

Tracking issue: #146975

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Oct 1, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 1, 2025

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@antonilol
Copy link
Contributor

Thanks for working on this!

@tgross35
Copy link
Contributor

Sorry I haven't had a chance to look at this, still behind on my reviews

r? libs

@rustbot rustbot assigned Mark-Simulacrum and unassigned tgross35 Oct 16, 2025
@bors
Copy link
Collaborator

bors commented Nov 1, 2025

☔ The latest upstream changes (presumably #148337) made this pull request unmergeable. Please resolve the merge conflicts.

// This will set drain.remaining to 0, so its drop won't try to read deallocated memory on
// drop.
self.drain.by_ref().for_each(drop);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need something like

self.drain.iter = (&[]).iter();
here to avoid problems with Drain::drop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, the for_each will ensure that remaining is set to 0, so Drain::drop won't drop anything. I intentionally use Drain::drop to put the elements together again properly.

unsafe fn move_tail(&mut self, additional: usize) {
let deque = unsafe { self.deque.as_mut() };
let tail_start = deque.len + self.drain_len;
deque.buf.reserve(tail_start + self.tail_len, additional);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have coverage for this reserve running? Normally growing VecDeque requires extra logic AFAICT, not just reserving the underlying buffer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should run anytime the new iterator (replace_with) has a different length than the removed elements, which is definitely tested. Do you have a more specific case in which this could cause issues?

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 8, 2025
@rustbot

This comment has been minimized.

@rustbot

This comment has been minimized.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 17, 2025
@Qelxiros
Copy link
Contributor Author

I'm not sure why the CI isn't running, but all the requested changes should be good
@rustbot ready

@Mark-Simulacrum
Copy link
Member

r=me with a rebase

@rustbot
Copy link
Collaborator

rustbot commented Dec 29, 2025

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

@Qelxiros
Copy link
Contributor Author

@Mark-Simulacrum should be good, but I don't have permission to r=you.

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Dec 30, 2025

📌 Commit 0763954 has been approved by Mark-Simulacrum

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 Dec 30, 2025
@bors
Copy link
Collaborator

bors commented Dec 30, 2025

⌛ Testing commit 0763954 with merge 0e89999...

@bors
Copy link
Collaborator

bors commented Dec 30, 2025

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 0e89999 to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 30, 2025
@bors bors merged commit 0e89999 into rust-lang:main Dec 30, 2025
12 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Dec 30, 2025
@github-actions
Copy link
Contributor

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 f0864c8 (parent) -> 0e89999 (this PR)

Test differences

Show 322 test diffs

Stage 1

  • vec_deque::test_splice: [missing] -> pass (J0)
  • vec_deque::test_splice_forget: [missing] -> pass (J0)
  • vec_deque::test_splice_inclusive_out_of_bounds: [missing] -> pass (J0)
  • vec_deque::test_splice_inclusive_range: [missing] -> pass (J0)
  • vec_deque::test_splice_inclusive_range2: [missing] -> pass (J0)
  • vec_deque::test_splice_items_zero_sized: [missing] -> pass (J0)
  • vec_deque::test_splice_out_of_bounds: [missing] -> pass (J0)
  • vec_deque::test_splice_unbounded: [missing] -> pass (J0)

Stage 2

  • vec_deque::test_splice: [missing] -> pass (J1)
  • vec_deque::test_splice_forget: [missing] -> pass (J1)
  • vec_deque::test_splice_inclusive_out_of_bounds: [missing] -> pass (J1)
  • vec_deque::test_splice_inclusive_range: [missing] -> pass (J1)
  • vec_deque::test_splice_inclusive_range2: [missing] -> pass (J1)
  • vec_deque::test_splice_items_zero_sized: [missing] -> pass (J1)
  • vec_deque::test_splice_out_of_bounds: [missing] -> pass (J1)
  • vec_deque::test_splice_unbounded: [missing] -> pass (J1)

Additionally, 306 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 0e8999942552691afc20495af6227eca8ab0af05 --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-aarch64-linux: 8820.3s -> 6358.7s (-27.9%)
  2. dist-aarch64-apple: 5676.9s -> 6825.5s (+20.2%)
  3. dist-ohos-armv7: 4115.0s -> 4568.8s (+11.0%)
  4. dist-powerpc64le-linux-musl: 5227.4s -> 5798.1s (+10.9%)
  5. aarch64-msvc-2: 6349.0s -> 5658.2s (-10.9%)
  6. dist-loongarch64-linux: 5321.4s -> 5889.0s (+10.7%)
  7. dist-x86_64-apple: 8164.4s -> 7396.3s (-9.4%)
  8. dist-loongarch64-musl: 5221.9s -> 5703.9s (+9.2%)
  9. dist-apple-various: 4641.9s -> 4246.5s (-8.5%)
  10. x86_64-gnu-llvm-20-1: 4002.2s -> 4324.5s (+8.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 (0e89999): 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)

Results (primary 4.8%)

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

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

Cycles

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

Binary size

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

Bootstrap: 481.996s -> 480.336s (-0.34%)
Artifact size: 390.85 MiB -> 390.83 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

7 participants